Please see all COVID-19 updates here as some shipments may be delayed due to CDC safety and staffing guidelines. If you have an order or shipping question please refer to our Customer Support page. For technical questions please check out our Forums. Thank you for your continued support.


Member Since: April 27, 2012

Country: United States

  • why is this seemingly always out of stock? =/

  • This board does not work with boards based on atmega32u4 (Leonardo, Yun, etc) or on the Megas. None of these support interrupts on pins 2/3, so SoftwareSerial won't work on those pins. I just found this out the hard way =(

  • My library should still work with this module, once it's converted to GSC using the firmware loader module.


  • would this show the communication involved in SD DRM operations? e.g. on symbian and windows phones, how they can encrypt the device so it can't be read on a PC. I've got an SD card from my windows phone that's currently bricked because no device other than WP7/symbian is capable of reformatting it, and i really don't want to have to buy a symbian phone just to get my SD card working again =(

  • Aw, I was hoping it'd be an interesting color like the dark blue one in the pictures. Mine are boring PCB green too =(

  • old post, but...

    The large heatshrink is great for very small self-contained circuits -- For instance, it's common to use on MOSFET control units in airsoft guns, to surround the whole unit (FET+diode+resistors+wires) and keep it from making contact with the metal chassis while inside the gun.

  • I've been working on a (hopefully) easy-to-use library for this display, known to work on Arduino 1.0.1 with the Uno/Mega2560/Leonardo. Might be a good alternative to displayshield4d, especially since it has support for alternative Serial/SoftwareSerial interfaces. https://github.com/planetarian/4Duino

  • I've found that the display speed just depends on the operations you're performing. You don't have access to a frame buffer (unless you count the SD card), so working with the display is mainly a matter of sending draw commands. The more pixels that have to be drawn, the slower the display will respond and be available for further commands.

    For example, the examples in my OLED library are quite smooth on this display, higher than my eyes can really discern, but those examples don't use screen blanking (the scope sketch blanks only a small area of the screen [two pixel columns]) and simply perform basic line draw operations. Another test sketch of mine which draws randomized objects to the screen doesn't seem to operate QUITE as smoothly, but is still at least 40-60FPS. A screen blank / background replace takes a fairly large fraction of a second by itself though, and you can visibly track its progress from top to bottom. So, if you need the display to be blanked after every 'frame' then it won't work for your application.

  • I've been working on a new Arduino library for this display (and presumedly other 4D Systems OLEDs). It supports hardware and software serial, along with almost the entire SGC API. There are a few functions I've yet to implement (mainly joystick/sound/direct-image-drawing stuff) but for most operations it's pretty much complete. I'm adding to the library as I find useful features to implement.

    Check it out on github: https://github.com/planetarian/4Duino

  • Old post, but in case anyone else is wondering, Hakko is a Japanese company.