Interfacing a Prop to a SparkFun Graphic OLED Color Display 128x128 - Carrier B
Mark Swann
Posts: 124
Over the Holidays I recieved SparkFun's Graphic OLED Color Display 128x128 (http://www.sparkfun.com/commerce/product_info.php?products_id=763). I was twitching with excitement at my new toy. So I went to work (play) carefully interfacing it to a Prop Proto Board.
I have it running now so I thought I would share some pictures of what I have done.
I will upload the pictures as soon as I reduce them to a reasonable size.
I have it running now so I thought I would share some pictures of what I have done.
I will upload the pictures as soon as I reduce them to a reasonable size.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I might do a youtube video if I knew how to do it.
Post Edited (Mark Swann) : 1/15/2009 6:14:01 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Thanks for the compliment.
I wanted to see some code or what objects you used. I am interested in getting one of these displays and seeing some code will defiantly get the credit card out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus
Post Edited (Praxis) : 1/15/2009 3:23:36 PM GMT
I will also attempt to create a video for youtube the way jazzed described.
Thanks
It should easy to cut and paste from the file.
Cheers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus
Never mind. I·figured it out.
Post Edited (Mark Swann) : 1/16/2009 3:09:08 AM GMT
The link below will transport you to a youtube video I made with my Logiteck QuickCam, demonstrating·the above·amazing little doohicky. (Did I spell that right?)
Brace yourself. Get ready to be ____-whelmed. (fill in the blank. choices are: "over", "under", or just make up something).
http://www.youtube.com/watch?v=PwdOpn-2W9w
Keep any comments to yourself. (just kidding)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Please explain why the special power down is necessary. What kind of damage happens if there is a sudden loss of power?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
I originally did my OLED experimenting with 4D Systems uOLED-96-Prop. 4D Systems has a note on their web site warning about improperly shutting down any of the OLED devices that they use.·The OLED device featured in this thread is manufactured by the same people, Solomon Systech,·that made the OLEDs that 4D Systems is using, so·I·think that I can safely assume that this device should be treated likewise.
The kind of damage, if·I can recall, I believe is damage to the organic light emitting diode elements. The damage is probably to effect a dimming or total loss of light emmission on the elements that are powered (lit) during the loss of power.
Mark
·
Nice job on the interface and the demo. I noticed that the demo on this unit isn't nearly as fast as on the uOLED-96-PROP that uses the graphics and display drivers that you have written. Is there a hardware limitation on the Sparkfun unit or do you have the demo throttled for demonstration purposes?
By the way, the option of being able to use a fillcolor when plotting characters that you did in the UOLED-96-Prop Graphics driver works beautifully.
Ed
Thanks for the complement.
The frame rate is slower, because the driver is needing to move a lot more data per frame. The frame period is 5.734 mSec whereas the uOLED-96-Prop was 2.608 mSec, on the 8Mhz model, and 2.150 mSec on the 10MHz model.
Some parts of the demo are slower, such as the lines, because I intentionally slowed·them down for esthetics.
Also, parts may be slower because I had to eliminate the back buffer,·since I did not have enough cog ram for it. Doing double buffered rendering disconnects you from the frame rate limitations of the front buffer, so you can render as fast as the processor allows. When using front buffer rendering, you need to wait for the buffer to be free from the previous frame before you can create a new frame. If I recall, the opening splash was originally rendered on the back buffer so it could go really fast, but that was not possible for this demo.
So, in conclusion, it is slower for several reasons.
Mark
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Go here-> http://obex.parallax.com/objects/404/
I took the advice of Praxis and added an 8x12 font, the source for which Praxis graciously provided. (Thanks Praxis.)
I also added a larger Propeller Logo to go with the larger font. The opening splash looks a lot better.
Enjoy,
Mark
Now, if only we could expand the ram to do double buffered animations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
Yes. Double buffered would be great. With 32768 bytes in the Prop-I and·the single·front buffer·being·16,384 bytes (128x128), a back buffer would not fit. I guess we'll just have to wait for the Prop-II.
Mark
·
Did you use the latest uOLED-96 driver I created?· I hadn't opened your source files yet.· I updated·the driver·just before Christmas and had a thread about it.· Basically I changed the driver structure around so that the commands could be sent to the display as well for changing the contrast and dimming and such.
I was reading an article or an app note recently about serial SRAM.· I know the discussion has been had before about adding external RAM and such, but I don't know that anyone has tried it.· What I would do is hook up a serial SRAM.· Write one cog as a graphics driver that does its calculations and shoves bits out into the SRAM.· When a buffer is ready for displaying an·update flag is set and the display driver in another cog·reads data out of SRAM and·on to the display.· Yeah, of course you may not get killer frame rates, but really what frame rates can be gotten?· There is probabaly some way to speed it up to ensure no or little idle time in writing and reading the SRAM.· Note that it is RAM and an EEPROM that I am talking about.· Of course, haven't ever worked with one and not actually running the numbers, then maybe I am too simplistic.· It is worth trying though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
I have not looked at your latest driver yet. It would be interresting to see how you implemented the additional commands.
SRAM? Hmm. Do you have a particular SRAM in mind? I would like to see a spec sheet.
Mark
As far at the serial SRAM goes I haven't picked any device out yet. I was going to do some Googling on this eventually.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
The more I think about your SRAM proposal, the more I likes it.
Short of Prop-II, that would be an excellant answer to the problem.
If you come up with device choices, signal me. I would like to play with this idea.
Mark
So two cogs are needed. Each cog has a similar set of routines for reading/writing over the serial (spi?) to the SRAM. The ideal choice is to write bytes into the SRAM in the same order they are needed for clocking out to the display. The display driver can just read in bytes and clock them out to the display. The two cogs will need a way to signal each other. Would it be another I/O pin or a variable? I think the I/O pin would be the fastest way.
Since the render cog and the display driver cog are in a "serial format", does there really need to be a dual buffer? I mean, the render cog can write to the same buffer that the display driver is reading from since the code is essentially linked through the access to the serial SRAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
The Prop has resource locking commands that could be used for controlling access to the SRAM. I tend to shy away from using I/O pins for inter-cog communications, though I would intertain any clever suggestions.
I did some thinking last night about how much time the Prop would take to read one bit from the SRAM. The steps are as follows:
(1) set clock low.
(2) shift in bit from previous cycle of this loop.
(3) set clock high.
(4) read bit. save it for shifting in step (2).
(5) repeat until done
With 50ns per step, that's 250ns per bit, 2 micro-sec per byte. For a 128x128 frame that would be a frame refresh time of 32.768 mili-sec. That is 30.5 frames per second. Slow, but not ugly, yet.
Post Edited (Mark Swann) : 1/20/2009 5:31:14 PM GMT
With a little bit of searching I haven't come upon a dual-port serial SRAM. It may not exist, but I didn't search deeply. However, at the prices and sizes of these chips, maybe just implement two chips to get a dual buffer going. Again the software will have to keep track of the ping-ponging of the buffer, but two chips would help cut down on the bottle neck of sharing one chip.
Thank you for the math Mark. Boy, when you write it out like that is shows why someone hasn't done it yet because they get discouraged at the frame rate. I think we should pursue it further though just to create an example though of what could be done.
Lets pick out a device to try. Maybe something that can be samples or purchase inexpensively. It doesn't have to be DIP of course, but something that could be hand soldered to a proto board perhaps. I see Microchip recently had a press release on their Serial SRAM (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2698&redirects=sram), but the device that has an operating voltage of 3.3V is too small. I imagine we would like a device with 32Kbytes and a 3.3V operating.
I see a couple devices at ON Semiconductor: http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207 perhaps the N25S830HA: 256 kb, 3 V Serial SRAM would work because it is in a SOIC package. Digikey doesn't have any in stock though and they are $3.72/piece in single quantities.
What parts are you finding?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com