Hey peoples!!
Aren't you all having a good day?
We're not doing so good over here in project “motion capture system” world!
After purchasing the Atmel AT45DB642D, we realized it was pretty much unusable as its connections were too small to solder to.
So we went with the USB option?
http://www.vinculum.com/prd_vdrive1.html
We spoke with the technician at vinculum and he assured us the write speed should not be an issue. If anything the Arduino is where the system will bottleneck, as the USB device can write up to 3 million bauds (AFAICT the Arduino tops out at 9600 baud).
We adopted the code from the playground for use with the USB ftdi VDIP1 (thanks to Nick!). Both devices use the same host controller and use the same firmware.
After two days of constant code pounding, we're having some issues getting the ftdi, vdrive 2 to write.
So we're hoping some one can take a look at this and maybe advise us on what we've over looked. The following code is the full code for the project as it stands. You really can't test this unless you have a lot of miscellaneous parts laying around your workshop and considerable time. The project has 6 analog-in sensors, what should be obvious is that it starts reading the sensors and then saves them to a file when ever a digital button is on. As long as the button stays on it will keep reading and writing to a file using a loop (incremental numbers). When the button is turned off it resets the base variables so you can start over.
The problem we're having comes in several varieties (current posted code slightly changed). The first problem comes when we write just one value like 100 to the incremental files. In this case we can only write to a total of 17 files during that session, even though we are asking it to write many more times. After that it stops making new files? we have tried incrementing in all three ways we know with the ++ operator, the +='s operator and simply var = var + 1. All give the same issue? no more than 17 files are created. It's also worth noting that we are watching the serial commands in a terminal program, and visualy know that we have issued the commands for the unwritten files..
The second problem happens when we write the 6 analog values to the files. In this case we can only write (if we're lucky) one file, and the second file (such as f1.txt) is empty, and no other file are written, even if we let the program run for say 20 iterations. So we added a long delay to the loop (6 seconds), since this error seems similar to when we write info too fast (no delay). This is a great deal of time and the problem persists. Which implies it's something we're not thinking of.
So it's 2:30 am. and we can't think any more. We figured we'd send a call out for help. Here is the current code, its highly documented but don't take any random comments to seriously as its still in a WIP. Please note that some areas of the code are not being used at the moment and its not really post worthy code, but hell it's a WIP.
Please see next post...