Driving an AdaFruit SSD1306 OLED display with a netduino

Driving an AdaFruit SSD1306 OLED display with a netduino… Fabien writes –

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.

Adafruit publishes a wide range of writing and video content, including interviews and reporting on the maker market and the wider technology world. Our standards page is intended as a guide to best practices that Adafruit uses, as well as an outline of the ethical standards Adafruit aspires to. While Adafruit is not an independent journalistic institution, Adafruit strives to be a fair, informative, and positive voice within the community – check it out here: adafruit.com/editorialstandards

Join Adafruit on Mastodon

Adafruit is on Mastodon, join in! adafruit.com/mastodon

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, TinyGO, or even use the Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for CircuitPython, MakeCode, 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.

Have an amazing project to share? The Electronics Show and Tell is every Wednesday at 7pm ET! To join, head over to YouTube and check out the show’s live chat – we’ll post the link there.

Join us every Wednesday night at 8pm ET for Ask an Engineer!

Join over 36,000+ makers on Adafruit’s Discord channels and be part of the community! http://adafru.it/discord

CircuitPython – The easiest way to program microcontrollers – CircuitPython.org

Maker Business — “Packaging” chips in the US

Wearables — Enclosures help fight body humidity in costumes

Electronics — Transformers: More than meets the eye!

Python for Microcontrollers — Python on Microcontrollers Newsletter: Silicon Labs introduces CircuitPython support, and more! #CircuitPython #Python #micropython @ThePSF @Raspberry_Pi

Adafruit IoT Monthly — Guardian Robot, Weather-wise Umbrella Stand, and more!

Microsoft MakeCode — MakeCode Thank You!

EYE on NPI — Maxim’s Himalaya uSLIC Step-Down Power Module #EyeOnNPI @maximintegrated @digikey

New Products – Adafruit Industries – Makers, hackers, artists, designers and engineers! — #NewProds 7/19/23 Feat. Adafruit Matrix Portal S3 CircuitPython Powered Internet Display!

Get the only spam-free daily newsletter about wearables, running a "maker business", electronic tips and more! Subscribe at AdafruitDaily.com !


  1. 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. 🙂


  2. 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


    and here


    Have fun,

  3. Hi Kevin,

    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.


  4. 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.

  5. Fabien:

    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.


  6. I finally got the chance to test the latency in toggling GPIO pins on a netduino and wrote this post: http://fabienroyer.wordpress.com/2011/01/22/netduino-gpio-speed-test/

    The short of it is that toggling a digital pin as fast as possible does not exceed 8.4kHz which equates to ~50 microseconds per pulse.

    I ran a bunch of tests trying to understand why SPI doesn’t work on the netduino with the SSD1306 and I’m at the point where I suspect a firmware issue with the alpha build I’m using (4.1.1.a5).

    Once I get hardware SPI working, I’ll work on software optimizations 😉



Sorry, the comment form is closed at this time.