I ported the Arduino driver written by Limor Fried for the SSD1306 monochrome OLED display to the netduino last week. The Arduino driver bit-bangs the data to the display controller, which is relatively slow. I attempted to speed up data transfers by driving the display using hardware SPI on the neduino. Oddly enough, this approach did not work and I have not yet found the root cause. As a result, I resorted to the bit-bang method. Because the SSD1306 OLED display supports a variety of protocols, I’ll continue investigating the issue until I can find a data transfer method yielding better performance.
Stop breadboarding and soldering – start making immediately! Adafruit’s Circuit Playground is jam-packed with LEDs, sensors, buttons, alligator clip pads and more. Build projects with Circuit Playground in a few minutes with the drag-and-drop MakeCode programming site, learn computer science using the CS Discoveries class on code.org, jump into CircuitPython to learn Python and hardware together, or even use Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for MakeCode, CircuitPython, and Arduino. It has a powerful processor, 10 NeoPixels, mini speaker, InfraRed receive and transmit, two buttons, a switch, 14 alligator clip pads, and lots of sensors: capacitive touch, IR proximity, temperature, light, motion and sound. A whole wide world of electronics and coding is waiting for you, and it fits in the palm of your hand.
Python for Microcontrollers — Python snakes its way on the SparkFun SAMD21 Mini, Hackaday.io, 10k thanks, and Tim’s magazine #Python #Adafruit #CircuitPython @circuitpython @micropython @ThePSF @Adafruit
Get the only spam-free daily newsletter about wearables, running a "maker business", electronic tips and more! Subscribe at AdafruitDaily.com !
Good job on porting the code to the netduino.
That is awfully slow, though, and I kind of doubt it’s simply because you’re bitbanging the data since it’s only 128×64 monochrome pixels.
I got the code from Adafruit running on an LPC1114 (clocked at 36MHz) this week and I’m bitbanging the digital IO pins as well, and the screen updates are seemingly instant.
I haven’t played with the NETMF for almost two years (I ported it to the LPC2478 way back when the porting kit still cost like $1000 [sigh]), but I wonder if the overhead of passing through the NETMF firmware isn’t seriously slowing down toggling the GPIO pins??? If you have an oscilloscope or something like a “Logic” from Saleae, it might be interesting to toggle a GPIO pin on and off as fast as you can and see what the delay is between state changes.
You should be able to update that LCD more or less instantly even on low-end MCUs, though. There’s only 1KB of data per frame, and say with the commands you have to double or even triple that … it’s still only 3KB/s.
Check how quickly you can toggle GPIO pin (digital IO), though, and that might indicate what kind of speed you can expect.
Glad to see people using the NETMF, though. There’s actually some pretty useful functionality buried inside it, and it’s a great bridge for people coming from the SW world to HW (being a fan of C#/.Net myself).
These display are gorgeous as well. 1.5″ would be a bit easier on my only-getting-worse eyes, but the contrast and brightness helps. 🙂
I wrote a C-library for the OLED board from SeeedStudio (which uses the same driver chip) and using the HW-SPI pheripheral of a Teensy the screen is filled with new content in about 1 ms. You can see it in action here
I agree with you: there’s a definite overhead caused by the .Net Micro Framework and I didn’t expect screen updates to be so slow.
I haven’t yet quantified what the pin toggling latency is on the netduino, but it’s significant and some folks have attempted to work around it with a native generic ‘bit banger’ driver: http://bit.ly/fChu7S
From previous experience, I know that SPI would really help in this situation… If only I could get it working with the SSD1306 😛
I’ll update this thread when I have actual data on the latency issue.
I’m knee-deep in a trying to finish a color graphic LCD framework for the Arduino right now, initially targeting the knockoff Nokia 6610 LCD’s Epson and Phillips controllers and the 32044PA/ILI9327 LCD+controller combo (because that’s what I have access to right now), so this kind of problem is pretty fresh for me.
At least on the Arduino, if you bitbang by way of digitalWrite(), you leave a ton of performance on the table; direct register access is the only way to get (in my opinion) acceptable soft SPI performance for LCDs. If you have *anything* consuming CPU cycles between register manipulations (either via firmware that you interface with, or your own code), you’re wasting a significant amount of time (do the math; compare, for example, the hardware SPI clock rate to the number of cycles you burn between pin state changes).
Getting hardware SPI working on the Nokia screen helped (there was a visible improvement), but not nearly as much as I was hoping; once I eliminated the latency in my soft SPI implementation, I found performance acceptable (but I’m still using hardware). 😉
Finding ways to creatively reduce the amount of data transmitted in the first place has actually netted much bigger wins: ie. plotting filled objects as contiguous vertical/horizontal lines or rectangles whenever possible rather than pixel by pixel (which multiplies your SPI chatter significantly), streaming font characters/strings or bitmap data, that kind of thing.
Just out of curiousity, I moved the code over to the LPC1343 (since it’s what was on my desk) and bitbanging SPI I measured a single full screen update takes 25ms. I haven’t made any effort to optimise anything, but that’s still 40fps. That’s at 72MHz, so I imagine the identical code on the 1114 I had clocked at 36MHz will be ~50mS. I should probably work on improving that, though, since I seem to recall seeing that these displays can handle up to 100fps (not sure where?).
Must be the latency in the GPIO lines on your board, though. I imagine it must be passing through a couple layers of code to get to the lowly little register that toggles the pin. That native GPIO driver you mentionned is probably the right approach, and if it works should open up a lot of possibilities. I like the NETMF a lot … but I remember wishing that low-level access for certain things was a bit easier for end-users.