Code 1: Firmware
This project will require two pieces of code that work together:
- Firmware running on Teensy, to chatter USB to the PC and handle the low-level DataFlash interfacing
- Software running on the PC side to send commands and transfer data between PC and Teensy.
In our case, neither one is very optimized. We unsealed the Design Runner at about 3pm, and by the middle of the night we had the first rev reading and writing. A little more work over the course of two days and we had something moderately reliable, with which we could read out all our cards and begin phase II – understanding the data format for the XDR. Our criteria for either software platform was just to function, so you’ll see no frills in either. Consider it a “proof of concept”, and if you’re interested and make some cool edits – we’d love to post them up, just let us know. Email us at XDR at open schemes dotcom.
To get acquainted with the firmware requirements, you may want to do some outside reading
- Atmel Dataflash Software SPI Master. A very high level overview, but worth a read nonetheless
- Arduino DataFlash Library. Non-functioning Arduino lib which is derived from Atmel code. There is still value in downloading it, and copying the routines for your own use as we have done.
- LUFA Dataflash Lib. Also a derivative of the Atmel code, but it actually works. However, it’s part of a larger LUFA framework which may be “too big” for your needs. The code is a little bit scattered, and you’ll be digging through many files to find simple answers – but it’s at least properly implemented, and provides a very generous suite of demos. You should strongly consider LUFA for your own usb projects, as it’s the best free unified framework out there.
Now back to our tasks at hand. The firmware is the more important of the two. It has to “suck and blow” data at a reasonable rate between the PC and the DF card. We also have to construct a way to let it know what the hell we want to do next!
To achieve these two tasks, the firmware consists of a simple command interpreter, and several routines to carry out tasks. The functions will be described herein:
- S – Status. Send a single ASCII ‘S’, and the firmware will go check the status register of the dataflash. This is used to make sure that a valid card is present in the socket, as well as to determine the capacity of the card. After receiving the ‘S’, Teensy will send back 4 bytes: 1) The raw value of the status register, 2) Number of bits in page address 3-4) The Low, High bytes of the page size. With this data the PC master can verify the validity of the card (and ensure it’s not hung), as well as parse out which card is inserted and it’s capacity.
- R PH PL – Read Page. Send an ASCII ‘R’, followed by 2 bytes designating the page to read. The reader executes a page read to buffer, then a buffer read and outputs the entire page directly to the PC. PC should expect n bytes, where n is the number of bytes we parsed out of the status code. In the case of the XDR, it’s 528 bytes.
- W PH PL – Write Page. Send an ASCII ‘W”, followed by 2 bytes designating the page to write to. The reader first starts a page erase (up to 10mS), then while the page is erasing it begins fetching data from the PC. It also expects n bytes (here, 528) and stores them in a local buffer. Once it has received 528 bytes, it goes to check if the erase is done. If not done, it keeps parsing the status until the erase completes. Once the erase is complete, it sends all 528 bytes to the DataFlash RAM buffer and executes a “Write Buffer to Page”. Then, it polls the status byte – waiting here until the write is complete before jumping back to the command interpreter.
All pretty simple stuff. You may be able to get some amount of speedup by NOT polling immediately after the page write command but rather going back to fetch more data from the PC. It’s a much more complicated routine, but there is probably room for improvement there.
Our low-level functions were copied from the Arduino DataFlash Library as listed above, with modifications to suit our application-specific usage. And plus, there were crazy errors trying to use it as-is. Due to the fact that it was an Arduino lib, we built the project in the Teensyduino addon for the standard Arduino compiler.
Maybe just an arduino problem. Much respect to Martin Thomas and Dirk Spaanderman for porting and tidying up the code. Also, Atmel Norway for releasing the code. Not sure what the licensing is, but all users should be sure to act in accordance with the terms and conditions stipulated in the conditions stipulated in the agreement/contract under which the document(s) have been supplied.
Huh? OK, no contract or agreement. Check! We’re calling this freeware until Atmel tells us otherwise – it’s code for their product to interface another one of their products. They should be thanking any users that download it!