Vinculum?
Graham Stabler
Posts: 2,510
Greetings gents, long time no type.
Has anyone produced a full object for the VDrive with error checking etc? A colleague needs to do a bit of data logging and I don't have time to help him much and he is just starting with the propeller otherwise I would try and write it myself.
Basically looking to write to a file as fast as possible nothing much else.
Cheers,
Graham
Has anyone produced a full object for the VDrive with error checking etc? A colleague needs to do a bit of data logging and I don't have time to help him much and he is just starting with the propeller otherwise I would try and write it myself.
Basically looking to write to a file as fast as possible nothing much else.
Cheers,
Graham
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
If it's not Parallax then don't even bother. :-)
·
I have changed my avatar so that I will no longer be confused with others who use genaric avatars.
Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order.
Cheap·shipping unless specified!··········150 left!!··
http://forums.parallax.com/forums/default.aspx?f=25&m=368563
I think this is the best available option at the moment.
It is a test release, though.
How fast is fast, for you?
Graham
The tricky thing to watch out for is jitter; occasionally writing a single block will take a substantial
fraction of a second.
The write behind code implemented in what we provide above can help, but if you want to sustain
250KB/sec and the card needs to momentarily pause for, say, 100ms (not outside the realm of
possibility), then that's 25KB you'll need to buffer somewhere. So even with raw, multiblock
writes on a super fast card, the propeller just can't buffer very much and there's a chance you'll
have to drop some data.
Attaching a large RAM chip to the prop might help with this.
There are also filesystem issues; depending on the state of your card, how many files there
are and how fragmented the FAT is, along with how big your cluster size is, the overhead
for a single block might be quite significant (worst case is probably in the minutes easily,
if the file system needs to scan a 32GB FAT32 with 512 byte clusters for a free block that
just happens to be far, far away, well, that's 256MB of FAT we need to scan). You may
want to use raw writes if you cannot tolerate any latency.
If you would like to, I'd be happy to discuss more specific details of what you are trying
to attain. But without a *significant* buffer, SD cards have difficulty with real-time high-rate
data capture.
But if you can tolerate the occasional jitter, you can easily get above 1MB/sec to an SD
card on the prop.
If the write fails it does not matter as long as we know this and can run it again.
If I added a ram chip then I would probably just store the data in that and then send to the PC via the usb link but I don't have time to develop anything so it would need to be off the shelf.
Graham
In all seriousness, A preallocated contiguous file in the card and writing raw to it may be the way to go. Then you avoid the filesystem overhead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU