uOLED-96-PROP - SD CARD to GRAPHICS DISPLAY - in 60mS !
Greg P
Posts: 58
I just succeeded in combining the SDFAT object (for accessing the uSD card) with a newly created COG-BASED uOLED-96-PROP object! It's still quite primitive, but using a PNY 2GB uSD and the cog-based PROP object I've observed a TOTAL read-from-SD/write-to-OLED time for a full-color image (12K bytes) to be less than 60mS !! Even at this early stage of development its clear that video capability should be readily achievable. My approach works by reading two 96-pixels rows of 16-bit image data at a time from the SD card into a 384-byte hub buffer. This is followed by a call to OLED cog. The cog is passed a pointer to the data buffer, the image start row#, and the # of rows to be written. In SPIN, a loop repeats this operation 32 times (64 rows / 2 rows-per-loop). Only graphics image display is currently supported. I will have to expand the # of parameters that the cog code can accept to perform operations like rectangle, line, etc. This should be straight forward however. Once I'm confident the code is stable and unlikely to damage the uOLED, I'll post my efforts. I've integrated within the object's STOP method the power-down sequence code, so that power off is more controlled and presumably less likely to damage the display.
I think two areas require targeting by the community: (1) Multiblock SPI read/write operations to/from the SD card, and (2) multidirectory access to the SD card.
I just discovered while copying some digital photos over from my PC to the uSD card (for transport to a photo kiosk at my local Walgreens) an apparent limit to the number of files at the root level under FAT16. Windows XP stopped copying at file #512. After reformatting the drive to FAT32 I was able to write all 900+ image files to the uSD card. For those who recall the FAT16 data structure, any idea how much work may be involved in extending the SDFAT code to multilevel directory operation ?
While multiblock read/writes my be fairly simple to implement at the SPI level, will this addition force a wholesale rewrite of the file system object code ?
Anyone ready to sniff out the serial protocol between the Xbox 360 ChatPad keyboard and the Xbox wireless remote ? I bought one tonight for $30. It includes a headset with mic plus miniature LED-backlit keyboard. If you disassemble it you'll find a seven-pin connector with exposed wiring between the keyboard circuit board and the interface plug to the Xbox remote. Three wires attach to a stereo audio plug while the remaining four wires for a pair of gold-plated contacts on either side of the audio plug. This is likely SPI, I2C, or simple Serial communication between the remote & keyboard. Capture the back & forth communication on these wires with a logic analyzer and you should discover all that's needed to adapt the Propeller to interface with the ChatPad !!
I think two areas require targeting by the community: (1) Multiblock SPI read/write operations to/from the SD card, and (2) multidirectory access to the SD card.
I just discovered while copying some digital photos over from my PC to the uSD card (for transport to a photo kiosk at my local Walgreens) an apparent limit to the number of files at the root level under FAT16. Windows XP stopped copying at file #512. After reformatting the drive to FAT32 I was able to write all 900+ image files to the uSD card. For those who recall the FAT16 data structure, any idea how much work may be involved in extending the SDFAT code to multilevel directory operation ?
While multiblock read/writes my be fairly simple to implement at the SPI level, will this addition force a wholesale rewrite of the file system object code ?
Anyone ready to sniff out the serial protocol between the Xbox 360 ChatPad keyboard and the Xbox wireless remote ? I bought one tonight for $30. It includes a headset with mic plus miniature LED-backlit keyboard. If you disassemble it you'll find a seven-pin connector with exposed wiring between the keyboard circuit board and the interface plug to the Xbox remote. Three wires attach to a stereo audio plug while the remaining four wires for a pair of gold-plated contacts on either side of the audio plug. This is likely SPI, I2C, or simple Serial communication between the remote & keyboard. Capture the back & forth communication on these wires with a logic analyzer and you should discover all that's needed to adapt the Propeller to interface with the ChatPad !!
Comments
If you use a pre-allocated file (so that the whole file occupies a contiguous area of the SD card), the existing SPI routines used in FemtoBasic will do multiblock reads and writes.
The root directory of a FAT16 filesystem is a fixed size, although you can change that size. I don't know if the
various formatting utilities available will let you do it, but the definition of the FAT16 file format appears to allow
virtually as many files as you want (by formatting with enough root directory entries).
For video, a single file is probably better. For a slideshow of lots of pictures, you may have to work around
the root directory limit that most formatters have by putting multiple pictures in a file.
Mike, you say the SPI routines in FemtoBasic will do multiblock reads and writes; is this accurate? You're
actually using *multiblock* reads and writes at the SPI/SD level? That's something that the existing fsrw code
I have does *not* do. It would be interesting to see if there are performance advantages to the multiblock
commands.
I just got the module to play 3 animations that I copied to the chip using 4D's Graphics Composer. I created a double buffer, reading an entire frame before display.
The video is Fast, Stable, and Smooth. I actually had to add a 30msec delay per frame. dissecting your code is also helping me learn prop assembler.
Thanks again for posting your code.
Post Edited (etherVision) : 11/22/2007 8:19:54 AM GMT