×

SparkFun will be closed Nov. 28th and Nov. 29th in observance of Thanksgiving. Any orders qualifying for same day shipping placed after 2:00 p.m. MST on Wednesday, Nov 27th will be processed on Monday, Dec 1st. Wishing you a safe and happy holiday weekend from all of us at SparkFun!

Shopping Cart 0 items
log in register
Today's Deals Forum Desktop Site
All Categories
Featured
Brands
Development
Sensors
Tools
Miscellaneous
Components
E-Textiles
Robotics
Wireless & IoT
Audio

Creative Commons images are CC BY 2.0

Favorited Favorite 3
Wish List

RGB OLED Breakout - 0.6"

We may have spoken too soon when we named the Micro OLED Breakout... This new display from WiseChip packs in more pixels (64 x 64), two more color channels and additional display RAM into an even smaller 0.6" screen. For all these features packed into such a small space it's practically a 'nano' display! The breakout PCB adds a 3.3V regulator for logic, a 12V boost converter to power the display, and level shifting circuits to allow direct connection to both 3.3V and 5V microcontrollers.

The 64x64 screen has a surprising amount of room for graphics, images, and anything else you could think to display. An Arduino Uno can refresh the entire display at up to 50 Hz. This means that whether you're displaying album art on a home-made MP3 player or making a pocket-sized game this display will be up to the task!

Complementing this amazing display is a flexible Arduino library that allows you to draw on the display, show photo-realistic images, and devise completely custom fonts - all in every color of the rainbow! Getting started is as easy as loading one of the example sketches on your microcontroller of choice and making the appropriate electrical connections.

Experimental Product: SparkX products are rapidly produced to bring you the most cutting edge technology as it becomes available. These products are tested but come with no guarantees. Live technical support is not available for SparkX products. Head on over to our forum for support or to ask a question.
  • 64x64 pixel resolution
  • 16 bit color depth for each pixel
  • 16k bytes display ram can be displayed (8k at once)
  • SPI interface, plus D/C and RST pins
  • Boost converter built-in
  • Supply voltage from 2.6 to 5.5V
  • 57mA draw @ 5V supply, full-white display
  • 50 Hz full-screen update rate
  • PCB dimensions: 1.2" x 0.9" x 0.2"
  • Display dimensions 0.9" x 0.8" x 0.2"
  • 0.8" spaced 4-40 mounting holes
  • OLED panel is detachable with FFC connector

Comments

Looking for answers to technical questions?

We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.

  • Member #1262119 / about 6 years ago * / 1

    Nice little screen, colors are sharp and bright.

    • Liquid Soulder / about 6 years ago / 1

      Glad to hear it! You got everything working alright since yesterday?

  • Member #83083 / about 6 years ago / 1

    Looks nice, But there are reasons to want the monochrome one for some projects. You don't always have the luxury of lots of data transfer or DMA.

  • robbok / about 6 years ago / 1

    Hi, just got these today-- they look fantastic. I need to create a setup to show video. I see the bitmap functions, but how would the code work to create what would essentially be a stream of consecutive bitmaps? I know I need an external SD card, so let's assume I have that. What next? How to convert a video to all the bitmaps needed, then how to pump them all through? I think this will be a core use case for many of your customers, so it would be helpful to have code to use. Thanks!

    • Liquid Soulder / about 6 years ago / 1

      Hmm, video streaming can be very resource intensive. Let's also assume that you are using something with a little more oomph like a Teensy3.6 or a SAMD21 board. My strategy would be this:

      • read up about the various video encoding methods that exist, particularly those that you have in mind for the project
      • keep only enough data in the controller's memory to handle one frame at a time
      • try to minimize the work done by the brains to update the frame by only modifying pixels that change
      • update the entire screen with that frame buffer at the rate you'd like.

      That's one of many ways to go about this, however there are many more!

      We're happy to help, but deciding on the specifics of your video protocol and writing code to convert other video formats is more than I can chew at the moment. Perhaps you could see if anyone else has written an open-source solution to this problem. If nobody has then its a great opportunity for you to do it! (If you do please share with me on GitHub and I'd probably take a peek)

      • robbok / about 6 years ago / 1

        Thanks. I understand the question was fairly general. I spent a lot of time today trying to make the display work with my SD card reader. Both work individually but I'm not having any luck getting them to work together. Here's what would be really helpful: if you could take the example sketch you include with the OLED that displays the bitmap (say, the Mona Lisa) and modify it to read the bytes from the SD card (assume it's just a text file on the SD card with the same content as the sample files you provided with the library) instead of from the serial input stream. It should be relatively easy (replace the serial.available with file.available, and process the streams) but I can't get anything working. Hopefully this wouldn't take up too much of your time and would be generally useful for others-- basically doing a port of your draw bitmap example to read the byte stream from a text file on the SD card instead. Is this doable?

        • Liquid Soulder / about 6 years ago / 1

          From your other comment looks like you got this working. Nice going! That's what I like to cal rubber-duck debugging. Hope you're enjoying it

  • joe57005 / about 6 years ago / 1

    When you say an Uno can refresh it at 50 Hz, do you mean 50 of the pixels changed per second, or do you mean all 64x64 pixels changed 50 times in one second?

    • Liquid Soulder / about 6 years ago / 1

      Hello - glad you asked to clarify. This means that all 64x64 pixels can be updated 50 times in one second, and that is what you can expect to see when using a 16 MHz Uno that is not doing too many other complicated processes.

      I got that result from a practical experiment on the Uno - the theoretical limit is just over 150 Hz assuming you could continually send data to the display at the maximum communication frequency of 10 MHz. Of course all the other things that usually need to happen (like generating the new data, sending commands, etc...) will keep anyone from ever actually making 150 Hz.

      Hope that helped answer your question, and if it didn't just gimme a shout.

      Have fun!

      • robbok / about 6 years ago / 1

        Hi, based on my results using a Pro Micro at 16MHz an an external SD card operating full-speed, loading optimized bitmap images, doing nothing else but updating the display, I'm getting about 2-3 frames/second. I can't imagine how anyone could refresh the display (with real image data, not lines/circles/etc in the GFX library) at anywhere near 50x/second. Each frame is 8,192 bytes of information, so that's 16,384 bytes you need to send up and down the SPI bus per second (SD --> Arduino --> display), and the SPI bus is capped by your library at 8MHz. Doing the math, I don't see how you could get more than maybe 4 frames/sec. That's still pretty good if you don't need real-time video-- the displays are so sweet in terms of size.

        • Liquid Soulder / about 6 years ago / 1

          Good observations - the 50 Hz number comes from testing with data already in RAM. When you add in another interface to the mix there is bound to be some additional overhead.

          Let's assume that you access the display and the SD card at 8 MHz and that you store ASCII data on the SD card to represent the bitmaps, in exactly the format that we had used in the serial port example. Let's keep track of how much data needs to travel across the SPI lines for a given pixel to update.

          • A single byte stored in that file looks like 0xZZ,_ because it is in human-readable ASCII form. To get the pixel data (two bytes worth) actually takes 12 bytes from the SD card including the leading 0x's, the commas, and the spaces before the next bytes.
          • Then you still need to send two bytes directly to the display

          So to update a single pixel from the SD card you need to transfer 14 bytes as opposed to just two bytes directly from memory. That 7x reduction in speed leaves you with about 7 Hz, not to mention the time that your program needs to take to parse the incoming ASCII data. Accounting for the fact that there is probably additional overhead I'm not surprised to hear about a 2-3 Hz refresh time - I apologize if that was misleading in the first comment.

          Let's talk about optimizations:

          1. Come up with your own file format that directly stores the bytes in binary, as opposed to encoding them as human-readable ASCII characters. This should get you to roughly 25 Hz (transmit 2 bytes from SD and 2 bytes to display for each pixel).
          2. Try reading from the SD card at the highest speed possible (approx 20-24 MHz) by switching the SPI settings each time (and back for the display of course)
          3. Try writing a compressed file format to transfer even fewer bytes from the SD card for each image. (This is only an improvement when the image is suitable for compression)

          Just as a curiosity pleaser for anyone reading this: you might wonder how real video monitors can refresh so quickly when this screen can't. There are a lot of technologies that support this but two big ones are parallel ports and direct memory access. With a parallel port 8, 16, or maybe even 24 bits can be transferred in every clock cycle - leading to speeds closer to 240 Mbps (or 10 megapixels per second for a 24-bit deep screen). Direct memory access can allow direct communication between an external flash memory and the display or enable data transfer to occur in the background while the microcontroller performs other tasks.

  • Member #403238 / about 6 years ago / 1

    All of those documents marked Confidential to Wisechip is bad form. Can you get versions without the watermark?

    • Liquid Soulder / about 6 years ago / 2

      Hi and thanks for the heads up about the datasheets - when we posted the product we had a short discussion about whether or not anyone would say anything. Now we know the answer to that one! The good news is that we have permission from WiseChip to share the information. The bad news is that they didn't provide an un-marked copy when I asked. In lieu of that I will update the product page to let everyone know they aren't reading contraband material ;) Again thanks and feel free to reach out with any more comments/concerns!

Customer Reviews

No reviews yet.