Evaluating propellor - advice sought...
sanandak
Posts: 18
All,
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.
Questions:
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.
Sincerely,
Sridhar.
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.
Questions:
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.
Sincerely,
Sridhar.
Comments
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.
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?
Thanks,
Sridhar.