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.
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 - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope www.tdswieter.com
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. It looks very useful and only costs ~$1.18 in single quantities from Microchip Direct. It even comes in an 8pin PDIP package!
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.
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...
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 - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope www.tdswieter.com
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.
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 - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope www.tdswieter.com
>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)
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?
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.
Comments
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, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
Microchip does offer a 3.3V version of the 256kbit SPI SRAM (23K256): 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 - (doh!!!) you are right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
*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
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.
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 - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
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-
·
Mark
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com
>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.
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-
·