Once I received the package I was amazed and dismayed at how small it is, brings back childhood memories of "It looked a lot bigger on TV!".
Even though it has 128 x 64 pixels, it's only a mere 1" wide x 9/16" high...about the size of a small-ish 7 segment display. The one advantage this OLED has is that it's white, and it's bright. Much brighter than an LED, green or red, outdoors.

 Well I've found my display. The diagram to the right shows how I plan to interface to it and the mainPIC bus. Unfortunately, the little board is 3.3 V so it's bus must be completely voltage shifted. Even so it'll update the display faster than with it's serial option (sw serial).

 The graphical data sent to be displayed will come from an 8 Mb EEPROM programmed via  RS-232 on the USART. This will likely come from files stored in a folder on the SD Card connected to the Arduino.

 Also some Panel LEDs will be driven from this board from PICs spare ports. It's pretty simple and straight forward, on purpose because the programming and layouts will be something more complex.

  Trying to work out a character vs. graphics vs. animation on any display is kinda tricky for me as I haven't done much (outside of the PC) so this'll be a real learning experience. Also the size of this display must be taken into consideration. For example, when selecting a song on stage, I don't want a 20 character long name of the song coming up as from standing distance, 5 feet for me, I won't be able to read it at all. On the other hand, when setting up a song, selecting filenames etc, it'd be nice to have a few characters to read...at least 12.
 Herein lays the dilemma, what size chars, and when to use them. 

After a while, I started to think that perhaps using "pre-designed" menu pages may be the best way to go. Large lettered menus for stuff that may need modifying on stage, or that doesn't need to be small, then smaller lettering / images for the inner setup menus. These 128 x 64's are just a conceptualization of that idea. I made lots.. but they're lacking pizzaz!

 Next I checked out some 2 frame animations, which would be good for choosing a channel ( rotary encoders are also buttons ) to modify EQ on, or when setting up a Preset, whatever.

            
 These I made using Flash. I tried using photo shop but the pixel smoothing and thresholds made a mess. These OLED pixels have no individual grey scale, they're on or off, which means any smoothing will be coming from the viewers interpretation (focus).  These Menus have no data element to modify, so are just display menus. I've devised a couple of methods to insert data into screen areas:
 

1) Use a matrix of pixels that will be replaced by the character(s) to be varied
2) Use x,y,ID positions embedded in the image file. This example might be x=24, y=32, ID=BeatsIn

 I'm still deciding, but I'm leaning towards embedding data in the end of the file because of a change in the way the files are created, below.
 

The OLED driver SSD1306 uses a bizarre (well to me it is) pixel layout that sorta doesn't make sense in a general sense, however in applications that require scrolling on one line, or two, and having a header that remains static, it does make sense. I think these were designed for exterior displays on cell phones.  The pixel configuration of the 128 x 64 display is vertical. This means that each byte represents a vertical set of 8 pixels, and 8 bytes make a vertical column of 64 pixels. There's 128 of these. If you are familiar with a display on a PC or most LCD displays, they generally raster horizontally and proceed from the top to bottom or bottom to top, same as a TV would.  Because I am setting up images in a computer, I had to write a Flash program that would scan these 8 pixels (on/off) vertically, shift them into a byte, and output the bytes as 128 x 8. This data can be fed directly into the OLED for an image.  Because of Flash's shared object limitations, I decided to have it create an ASCII HEX print out that can be copied and pasted to an appropriately named file inside a "Menus" folder. If you type the filename otest.swf into the little window, it'll show the image and display the text to be copied into a .txt file named "Channel5.txt".  This has been working well so far.  The reference to Chars. was accidentally left in as I've been using this to map characters of various fonts and sizes. Try entering ochar16eg.swf which will encode the first 32 characters on the 16 bit comic font. (You'll need to refresh the page first)

OLED Page Image Creator

The nice thing about fonts is some are wider, and some are narrower, so even if there's only 8 chars/line here, if the empty ends are truncated to 2 pixels, sometimes over 12 chars can fit.I managed to fit all on the capital letters and numbers and punctuation in 8x8 pixel format on 1 page, and they could be used, but they are tiny! ( As can be seen in the 128 x 64 image here)  They'd still be useful for those "intense" setup menus (secret life altering menus lol) but for me it'd be time to pull out the magnifier. Speaking of magnifiers, a friend found me a plastic lens finally. Yay! Now I don't have to make my own. I want it to put this display behind, just to get a bit of magnification!

 With this configuration, the mainPIC will be able to control this OLED PIC with a minimum amount of cycles. My present comm method on the parallel bus is the "if bit 7 is set, then it's a command" The byte following a command won't have bit 7 set, so there's the difference that will denote a new byte has been sent. The OLED scans the bus at every opportunity and compares with last byte read.  This of course means twice the amount of data if sending ascii data, but it can be sent in a timely manner with not many cycles off of mainPIC. Also, if the commands are a non-used ascii without bit 7 set, then bit 7 could be toggled on every 2nd byte after a "load ascii" command. A terminator (probably 0) would be needed though.

Loading the EEPROM:
 Getting data from the SD Card to the EEPROM can be done using the Arduino that controls the SD Card. I've already written a function into the Arduino that, upon receiving an "O" on it's 115,200 baud port, starts loading and sending data from each file in directory MENUS which includes CHARS files. It's cool to watch it go! I had to slow it down to allow for EEPROM program time, but still it'll be pretty quick! More on that later.

 Well that's about as far as I've gone thus far. It's starting to make a bit of sense as I plod along. I'll post the hardware fun next! Cheers

Last update April 27th 2014