View Full Version : Evaluating propellor - advice sought...

02-11-2007, 04:28 AM

The propeller looks like it might be what I am looking for, but would appreciate some advice:

1. Read data from an A/D converter using SPI at 8000 samples per second (4 bytes per read, so ~32Kbytes/s)

2. In fact there may be as many as 4 A/D channels, so as much as 120Kbytes/s.

3. These data come in a 30s long stream (~4Mbytes total data)

4. These data have to be transferred to a computer that has an SPI port, USB, and a serial port. Real time would be nice, but not critical.

Transferring data without buffering would require transfer speeds of ~120Kbytes/s, which is doable with SPI, may be doable with USB, not doable with serial.


Does the Propeller support USB transfer rates that high?

To buffer this volume of data would require more RAM than is standard - is it possible to add more memory so that 4Mbytes are stored, and then transferred slowly?

Any help/comments appreciated.


Mike Green
02-11-2007, 04:52 AM
1) Should not be a problem. You will probably need to do this in assembly language rather than in Spin which can handle maybe 1/2 that rate

2) If the channels are in separate devices, you can use one cog per channel. If not, assembly language can still handle the aggregate data rate.

3) That will have to be offloaded to some kind of external memory buffer.

4) SPI and serial are easy to do with existing code at speeds much faster than those you describe.

5) The Propeller doesn't handle the USB normally. There's an FTDI USB to serial converter that handles this for the Propeller chip. It's specified for serial data rates on the order of 3Mbit/s, but this is always dependent on the computer's ability to handle those rates. The Propeller can easily handle data rates in excess of 1Mbit/s using assembly language. The existing full duplex serial routines have been informally tested up to about 230Kbps and can handle a bidirectional channel at that speed. Better to write your own half duplex serial routines if you really need the speed.

6) You can add additional external memory, but it's treated as an I/O device. You'd have to provide some external logic to latch address bytes if you're going to use static RAM (because there's only 32 I/O pins). Most serial memories are flash based and can't handle the write speeds.

02-11-2007, 10:36 PM
Cheers, Mike...

The idea of the cogs running in parallel is attractive - adding the 2nd, 3rd, and 4th A/D read *seems* to be as simple as starting up the SPI read on a separate cog... so I have to just figure it out once for the first channel and then I can clone it for the other channels... or at least that is my understanding of spin and cogs and hubs... I have ordered a demo board to start playing with the language.

My (somewhat fuzzy) vision is to have an SD card mounted and write data to it using the code that otehrs have posted to the public area (there appear to be a few projects out there that have used the FAT16 filesystem object to write to SD). These data can then be sent to the computer at leisure...

The next question would be what the write speeds are for a good SD card? To keep up with the data streaming in at 120kbytes/s, the data will have to be written at rates of ~1/10ms per byte. Is that a reasonable write speed?


Mike Green
02-11-2007, 11:07 PM
I believe the write speeds of SD cards vary all over the place. You'd have to look at the datasheet for a particular card. The underlying flash memory takes around 5ms to write a block of data and different cards have differing amounts of buffering and parallel processing in the card's controller to achieve the documented write times. I suspect that you'll be able to manage with time to spare, but you'll need to be careful. You should use preallocated files (to avoid having to allocate more space while you're writing) and allow for several kilobytes of buffering. You will need a cog for each separate A/D device. Obviously, if there's only one device with multiple channels, there's no point in having multiple cogs trying to use the one device since the channels would be sampled in order, not simultaneously. One cog (probably the initial one) would handle writing the buffer contents to the SD card once it had initialized everything. You'd have another cog with the FullDuplexSerial driver running in it to handle the low level I/O for the link to the PC. That's 6. You'd want to use the TV driver (which takes a cog) to display debugging/status messages.