Short update: A SPI OLED is way faster compared to the I2C model. Nearly 290 fps with software SPI. And I got the local scrolling working.
The video is captured with just 50 fps - so I´m sorry that you see multiple frames at the same time. In reality it looks really sharp and snappy.
http://www.youtube.com/watch?v=hvbIZPFd3bk
Very nice! 
Very nice! I’ve been using I2C for so long I forgot how much faster an SPI implementation could be… I haven’t had any projects that needed that type of speed but your video spawned a couple of ideas… would you share your spectrum analyzer code?
The response looks great!
It’s nice the OLED only needs six wires for hook up. Where did you get that one?
That one I bought via Amazon in Europe. I saw it also at Aliexpress (search term “spi oled 0,96”). Make sure to get a single color one, no one needs a yellow bar on the display.
Which part of the code is interesting for you, @Jon_Bruno ?
The decoding and waveform mapping is interesting… I guess I could look at some o-scope samples but an your example of actual functioning waveform analysis and display writing would be more helpful. Your projects are always inspiring.
The analysis itself happens in hardware. I use 2 of them: https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf
The fastest way to read them I found so far ist this:
void read_audio_fast()
{
for (uint8_t band = 0; band < 7; band++)
{
FastPin<STROBE_PIN>::lo();
delayMicroseconds(27);
left[band] = analogRead(A1);
right[band] = analogRead(A2);
FastPin<STROBE_PIN>::hi();
}
}
Together with analogReadResolution(8); in setup.
That gives me 2*7 bytes representing the band values of 7 frequency bands. With these 8 bit values I can do whatever I like. I divide them until they fit into the desired range. Like here for the scrolling thing
// Delta Bass
display.drawLine(61, 32, 61, 62 , BLACK);
display.drawLine(61, 63 - (bands[0] / 8), 61, 63 - (bands[1] / 8), WHITE);
// copy to the left
for (uint8_t x = 2; x < 61; x++) {
for (uint8_t y = 32; y < 62; y++) {
if (display.getPixel(x + 1, y) == 1)
display.drawPixel(x, y, WHITE); else
display.drawPixel(x, y, BLACK);
}
}
ah… very good. I thought you were doing it in software…Very smooth solution. thanks!
Even though you’re updating the screen contents that fast, how can you confirm its actually refreshing that fast? Maybe it redraws at its own fixed slower rate for example? Is there a sync function you can query? Thanks
Hi, I found no “retrace” signal (refresh completed) so far as known from CRTs, but it´s simple to test it: draw one vertikal line and move this line every frame by one pixel. As fast as you can. If you see a really vertikal line the internal multiplexing is fast enough to output these update speed. If the line has discontinuities (step(s), showing parts of the old and parts of the new frame(s)) the update fps are too fast. A photo camera which allows very short shutter speeds also helps to “measure” the internal speed - especially with an OLED.
@Stefan_Petrick yah visual tearing. Inevitable without some syncing. I think some of the ssd drivers support some form but not sure which.
With the I2C interface I saw tearing happen. With SPI not (yet). Both SSD1306. It seems that the internal speed is influenced by the choosen interface. But basically a good question, why it not happened without syncing, no matter how fast the display is. I´ve no answer.
Thanks for the info. I’ve posted the question in a new post to see if
anyone has any more info. Cheers
I finally found where you got your getPixel() from: https://forums.adafruit.com/viewtopic.php?f=47&t=86860&p=447609&hilit=oled#p447609
Thanks for sharing your ideas!
Yesterday I got rid of this slow solution. Manipulating the screenbuffer directely now without any bitshifting. The trick for horizontal scrolling is: “Most of these chips are organised as 1 byte to 8 vertical pixels.” The hint was given here: http://forum.arduino.cc/index.php?topic=375853.0
And here is the great help I got how to access the screenbuffer from the main scetch: http://forum.arduino.cc/index.php?topic=375894.0
much more helpful. Thanks
Stefan, since you are on the teensy, have you tried the audio library for FFT?
No, not yet.
Got hardware SPI running. Arround 670 fps including audio reading and drawing stuff. Looks sick, especially the scrolling. Tearing.
@Stefan_Petrick wow 670 fps. thats very cool. do you have a scope? would be interesting to draw the screen white, then black, at that frequency, and measure light output on a photocell on a scope, to see if you get the expected ideal square wave @ 335 hz.