PDA

View Full Version : Interfacing a Prop to a SparkFun Graphic OLED Color Display 128x128 - Carrier B



Mark Swann
01-15-2009, 01:23 PM
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.

http://www.sparkfun.com/commerce/images/products/OLED-Breakout-1.jpg
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.

Mark Swann
01-15-2009, 01:37 PM
Here are the pictures of a Prop Proto Board connected to a SparkFun Graphic OLED Color Display 128x128 - Carrier Board.

jazzed
01-15-2009, 01:45 PM
Cool :) Can you do animations on this? Will you produce a youtube video?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Mark Swann
01-15-2009, 02:06 PM
I would love to do an animation·for this. I did some EEG neurofeedback software years ago that·played an old FLI/FLC formatted animation at varying speeds depending on the state of the brainwaves. I created the animations as loops, such as repeated fly-throughs of the Grand Canyon. FLI and FLC is easy to decode so I·should easily be able to create animations for this.

I might do a youtube video if I knew how to do it.


jazzed said...
Cool :) Can you do animations on this? Will you produce a youtube video?


Post Edited (Mark Swann) : 1/15/2009 6:14:01 AM GMT

jazzed
01-15-2009, 02:53 PM
Pull out your web-cam, etc. Save video to file. Get a youtube account and upload video. Your still pics are very good.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Mark Swann
01-15-2009, 03:01 PM
jazzed said...
Pull out your web-cam, etc. Save video to file. Get a youtube account and upload video. Your still pics are very good.


I can do that. Thanks. Tomorrow. (I'm sleepy.)
Thanks for the compliment.

grasshopper
01-15-2009, 09:49 PM
Great job,

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.

Praxis
01-15-2009, 11:07 PM
Here is an 8x12 Font for anyone who finds it useful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus

Post Edited (Praxis) : 1/15/2009 3:23:36 PM GMT

Mark Swann
01-15-2009, 11:40 PM
grasshopper said...
Great job,

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.
I will attach the source this evening after work.
I will also attempt to create a video for youtube the way jazzed described.

Mark Swann
01-15-2009, 11:42 PM
Praxis said...
Here is an 8x12 Font for anyone who finds it useful.


8x12 is a good choice for this display. I will take a look at your file and see if I can integrate it into the code.

Thanks

Praxis
01-16-2009, 12:03 AM
An 8x8 font is a tad too small for this type of display that is why I created the 8x12.

It should easy to cut and paste from the file.

Cheers

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Adequatio Rei Et Intellectus

Mark Swann
01-16-2009, 10:36 AM
jazzed said...
Pull out your web-cam, etc. Save video to file. Get a youtube account and upload video. Your still pics are very good.


Okay. I give up. I have a· Logitech quickcam, but I cannot figure out how to record video. HELP!

Never mind. I·figured it out.

Post Edited (Mark Swann) : 1/16/2009 3:09:08 AM GMT

Mark Swann
01-16-2009, 12:10 PM
Okay, y'all. (I was born in Oklahoma so I have a right to say that.)
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)

jazzed
01-16-2009, 12:21 PM
I really enjoyed that Mark. You could demo for a living! Display looks great too. Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Mark Swann
01-17-2009, 10:43 AM
I have attached the source code for this.

Oldbitcollector (Jeff)
01-17-2009, 10:50 AM
Nice demo!

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 (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)

Mark Swann
01-17-2009, 11:02 AM
Oldbitcollector said...
Nice demo!

Please explain why the special power down is necessary. What kind of damage happens if there is a sudden loss of power?

OBC


Hello OBC,

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
·

Ed Parsons
01-17-2009, 08:45 PM
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

Mark Swann
01-18-2009, 01:29 AM
Ed Parsons said...
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
Hi 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
01-18-2009, 01:39 AM
Fantastic demo and project 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

Mark Swann
01-18-2009, 02:01 AM
Whit said...
Fantastic demo and project Mark!


Thank you for the kinds words.

Mark Swann
01-19-2009, 10:31 AM
I just posted the latest source code on the Object Exchange.

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

Timothy D. Swieter
01-19-2009, 01:12 PM
Nice work Mark. I am glad to see that you are have upgraded and adapted the work I originally did on the uOLED-96. It is always neat to see how others build upon others effort.

Now, if only we could expand the ram to do double buffered animations.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-19-2009, 02:08 PM
Timothy D. Swieter said...
Nice work Mark. I am glad to see that you are have upgraded and adapted the work I originally did on the uOLED-96. It is always neat to see how others build upon others effort.

Now, if only we could expand the ram to do double buffered animations.


... and I really want to thank you for your ground breaking work. You may notice in the source that I still give you credit in the comments at the top of each source file.

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.http://forums.parallax.com/images/smilies/cry.gif

Mark
·

Timothy D. Swieter
01-19-2009, 06:27 PM
I appreciate the reference to me and Brilldea.· Overall it was not too difficult to setup the ASM driver, but I do appreciate the mention since it was work that was performed and built upon.· I like the recognition http://forums.parallax.com/images/smilies/cool.gif

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 (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-20-2009, 12:51 AM
Timothy,

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

Timothy D. Swieter
01-20-2009, 07:36 AM
The latest uOLED Driver is restructured to be in a format of holding in a wait loop until a command is sent. The command could be in an internal command to adjust how code is executed or an actual command to send to the OLED screen or data to send to the OLED screen. I like the new structure better. With some modifications it can be made to always send data to a screen unless it receives some other directions like sending a command to adjust the screen's contrast or brightness.

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 (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-20-2009, 11:56 AM
Timothy,

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

Timothy D. Swieter
01-20-2009, 01:34 PM
I like the idea too, lets talk through it a little more. Right now, having not searched for devices, lets assume that the serial SRAM is a "single port", which I imagine is most common. In fact, I kind of doubt a dual port exists, maybe, but if it does then why hasn't someone already done this? So, if it is a single port then the rendering cog and the screen driver cog would have to share knowledge and IO with each other in such a way that the render cog writes data to the display, signals the display driver and then the display driver takes over and reads data out.

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 (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-21-2009, 12:47 AM
I looked at some serial SRAM devices last night. I did not see a dual port version, but I did not think to look for it, so I might try again tonight. The devices I saw had a mode of access called "Burst" where, once the read command was initiated, all the data in the SRAM could be sucked out in one long series of clock cycles. The Burst mode would be the most efficient for the screen driver cog. Dual port would only be useful if the device had two SPI interfaces, one for each port.

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

Timothy D. Swieter
01-21-2009, 07:58 AM
The burst mode sounds familiar to the app note I was reading too which made me think about the SRAM as an option. I need to read more, but I was also thinking a sequential mode (maybe that is the same as burst?) where you start reading at a location and just keep reading until finished.

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 (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-21-2009, 08:13 AM
Sequential mode is probably the same as burst mode,

I think we can forget about dual port, especially with your suggestion to use two SRAMs in a ping pong fashion.

I think the spec sheet I looked at was from the same place, ON Semiconductor.

I just had a crazy idea. Why can't you put, say, 8 of these SRAMS on the same SPI bus but connect the data pin on 8 separate Prop pins? You would read and write to to all 8 at the same time, and effectively multiply your data rate by 8. Surely someone has tried that.

Mark

Timothy D. Swieter
01-21-2009, 08:16 AM
The 8 SRAMs sounds like an option, but how would that differ from a parallel SRAM? I have not used parallel SRAM either, so I can't comment much on that.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Harrison.
01-21-2009, 08:20 AM
Timothy D. Swieter said...
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.


Microchip does offer a 3.3V version of the 256kbit SPI SRAM (23K256): www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039). It looks very useful and only costs ~$1.18 in single quantities from Microchip Direct. It even comes in an 8pin PDIP package!

Mark Swann
01-21-2009, 08:33 AM
Timothy D. Swieter said...
The 8 SRAMs sounds like an option, but how would that differ from a parallel SRAM? I have not used parallel SRAM either, so I can't comment much on that.


Well, if I understand what you mean by "parallel SRAM", a parallel SRAM would need to be addressed with a parallel address bus. That would consume too many Prop pins, and it would NOT have the fast burst (sequential) mode.

·

Timothy D. Swieter
01-21-2009, 08:34 AM
Harrison - excellent find. I am going to have to order up a couple.

Mark - (doh!!!) you are right.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Mark Swann
01-21-2009, 08:37 AM
Timothy D. Swieter said...
Harrison - excellent find. I am going to have to order up a couple.

Mark - (doh!!!) you are right.


I'd like to try it times eight,·the way I described above.

*EDIT* But perhaps ping/pong with two just to prove the principal, then I'll experiment with other ideas.

Post Edited (Mark Swann) : 1/21/2009 12:52:17 AM GMT

ianw
02-20-2009, 02:57 PM
Hi,

Thanks for the OLED objects Mark and Timothy, I've noticed OBC and others using these displays in projects posted to the forums. The projects I've seen thus far seem to only use the smaller 128x128 OLED's. Has anyone had success trying any of the larger modules too, such as the QVGA 240 x 320 pixel resolution 2.83" modules (w/ or wo/ touch)? e.g. http://www.4dsystems.com.au/prod.php?id=34

I was worried I might be constrained by the Prop with a screen this size...

The example code I've seen is using 8 bits (so 256 colors) which is fine since I am just displaying data, updating charts, etc. - eventhough the displays are capable of 256K colors per pixel, I should not need this much color information. So, by choosing such a large display, am I just limiting myself to 8bits and a slower refresh rate relative to the 128x128 display examples - is it not worth trying to interface these larger displays with a prop?

Thoughts? Any comments would be much appreciated since they are rather pricey...

Thanks.

Timothy D. Swieter
02-20-2009, 10:42 PM
ianw -

Of course you can use the larger displays. In fact I have been wanting to for a while, but you are limited in what you put on those displays because you can't use a bitmap buffer. If you have graphics from another source like an SD card or data coming in over USB/Serial you could turn it around and place it on the display without holding the full image in Propeller memory/buffers. What I mean is you can't render full screen graphics into the memory of the Propeller and then pump it out to a large display because there simply isn't enough memory inside the Propeller for the large resolution/bit-depths. Don't let this stop you from the other options though like an SD card.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

Joel Rosenzweig
02-21-2009, 04:18 AM
The larger displays work great with the Prop.· It depends on what you are trying to do, of course.

When this display is interfaced to the Prop with its limited storage, the display is best put to use either rendering images that you already have stored in the SD memory connected to the display, or, using the display controller's high level graphics programming language to describe the polygons that you want to display, rather than have the Prop figure out the value for each pixel.· What solution you choose really depends on what type of content you are trying to render.· For many applications, storing the graphics in the SD memory and manipulating where they go on screen is all you'll need.· And the Prop can easily manage this type of system without a lot of memory.

Joel-
·

J. A. Streich
02-21-2009, 05:21 AM
How many pins does it take? I mean, are you using the parallel 8or9 or the 4 wire interface in your driver?

Mark Swann
02-21-2009, 08:32 AM
J. A. Streich said...
How many pins does it take? I mean, are you using the parallel 8or9 or the 4 wire interface in your driver?
I have 9 pins wired, but in truth I am only using it in 8-bit mode. The ninth bit is impractical with the the PROP-I memory limitations.

Mark

Timothy D. Swieter
02-21-2009, 09:08 AM
The quantity of pins required depends on the display and its controller. Some displays you can talk to in SPI requiring only a limited amount of pins while other display are only parallel requiring 24+ pins because of 8-pins for each color. Again, it depends on the display and the controller and manufacturer. Some displays can have parallel or a serial mode. Other displays, especially larger displays are only parallel.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com (http://www.brilldea.com) - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com (http://www.tdswieter.com)

ianw
02-21-2009, 02:32 PM
>Timothy said:
>If you have graphics from another source like an SD card or data coming in over USB/Serial you could turn it around and place it on the display without holding the full image in Propeller memory/buffers. What I mean is you can't render full screen graphics into the memory of the Propeller and then pump it out to a large display because there simply isn't enough memory inside the Propeller for the large resolution/bit-depths.

>Joel Rosenzweig said:
>using the display controller's high level graphics programming language to describe the polygons that you want to display, rather than have the Prop figure out the value for each pixel
>storing the graphics in the SD memory and manipulating where they go on screen is all you'll need. And the Prop can easily manage this type of system without a lot of memory.

Thanks for the clarification - this seems to be the way to go then
I don't need animations or high resolution photos - just fast updates of a few numbers and 3-4 bargraphs displayed on the OLED - I'm tracking roughly 20 variables split between two screens, hopefully toggled by a finger tap on a menu item via the touchscreen - it's basically a fancy remote for a bot, with an XBee for tx/rx, two control sticks from a vex transmitter, and three toggle switches, and then the OLED for some basic data display

I wonder if I should altogether bypass the idea of a Propeller connected directly to the OLED...?
the data stream that is displayed on the OLED will actually be coming from another Propeller on the bot via the XBee link
since there seems to be a few extra I/O pins on the OLED board according to the datasheet - maybe I could just use these to interpret the values coming off the potentiometers from my deconstructed vex remote sticks (with an adc chip)

the remote, is similar to what this guy did here, but with two less sticks: http://www.kronosrobotics.com/Projects/remote.shtml
This is the vex transmitter, that I pulled the sticks from: http://www.allelectronics.com/make-a-store/item/JS-6/6-CHANNEL-TRANSMITTER-AND-RECEIVER/-/1.html

Has anyone that has worked with these OLED's know if the additional I/O lines and included mcu would be suitable for this task - or will I still likely need a propeller for the remote too?

Thanks.

Joel Rosenzweig
02-24-2009, 03:40 AM
Has anyone that has worked with these OLED's know if the additional I/O lines and included mcu would be suitable for this task - or will I still likely need a propeller for the remote too?



There are available 2 general purpose I/O pins on the OLED module (I'm using the μOLED-128-G1) for my project.··In addition, it has 2 more pins dedicated for serial RX and TX.· If you encoded your joystick information as a serial data stream, it would be trivial to read it from your program running on the display controller.· How you do this depends on a few design decisions you need to make.· There is certainly enough processing power and I/O onboard already to handle the processing needs you are describing.

Joel-

·