It’s a little early to mention this, since the code isn’t finished, but I can’t wait.
Take a look at this cool product that will make it very easy to let the robot control code talk to an SD memory module:
I have always been annoyed that you have to recompile the control program to implement changes to an autonomous program or script. Using this device, you can use short text strings to specify the steps of an autonomous script, and simply edit the file on the SD module connected to your PC, plug the SD back into the RC, and off you go.
I am going to use the SPI interface to talk to this thing, since in the RC environment a synchronous protocol is easier to deal with than async. In this case it can be done with bit-banging on 5 digital I/O pins.
Another thing, it runs on 3.3 VDC, so make sure and have a regulator on hand. Even though the power supply is 3.3 volts, it can interface with 5 volt control signals.
I haven’t even powered mine up yet, as I am waiting for the 3.3 volt regulator I ordered…
Originally, I tried to order the development board from ChipDos, but they quoted January delivery, so I changed the order to the plain module. That is why I bought from them instead of Spark Fun.
I would like to get it running from a terminal first because it should be easier to deal with, then I will move on to SPI.
I will continue with the ChipDos one, since I already have it, and it looks simpler to use. There are many complaints about it, but some people have been able to make it work. I think this will be a handy device to have on the robot…
Sorry for the delays, I finally got around to making this module work. It has some annoying qualities, but I think we will be able to use it for the upcoming 2007 season.
To talk to CF cards with FAT filesystems, you might be able to use code and designs from Minty MP3 (http://www.ladyada.net/make/minty/). There is code for a PIC18 under the firmware section (fat16.c and cf.c).
Interestingly enough, CF is pin-compatible with ATA, so you might also be able to use conventional ATA hard drives with that code and hardware. (Not that you’d ever need several gigabytes of code space…)
I will assume it works on the same protocol as SD, which is SPI. The SPI portions of the IFI controller’s PICs are being used for internal function. If so, that software wont be a direct fit for what you want it to do.
The good qualities in general are its low cost and basic ease to use. I think it is very cool that we can drop a file system on the RC to make autonomous ops better.
The annoying qualities are that it runs on 3.3 VDC instead of 5 VDC, and that the commands must be lower case and the file names must be upper case, etc. One catch using the SPI interface is that you have to send meaningless bytes to have it send data back to you, but that is the case with any SPI device.
Access to file data is very primitive, and I haven’t had time to write some higher level code for accessing the data, but considering the simple task we have of simply reading from a file, it should work OK.
My testing has been solely with the SPI port. I built an RS-232 to SPI bridge using an SX-48 microcontroller development board that echos input from the serial port out to the SPI port, and the reverse as well.
Doing this makes for some funky operation from the terminal, but it really boils down to typing an extra space character to get the DOS prompt back from the module. It ignores the extra spaces, so no harm done… I also wrote some testing code that talks SPI directly to the thing.
I have some more information and a link to the test program here, http://www.techranch.com/blog/, and will be posting more info soon…
One thing about SPI on the RC. There is a built-in SPI port on the PIC chip, but I think it is used to talk to the master processor. The test code I wrote just bit-twiddles some port pins to generate the clock signals. SPI can use as few as 3 pins, but this one uses 5; data out, data in, clock, chip select, and busy. There are 2 others available, data direction and reset. I am currently resetting the chip from a port pin, but I doubt that I really need to do this. The data direction signal would make communication with the module more predictable, but I probably won’t use it.
I will be posting some more sample code on the blog…
Hey guys, it sounds like you are trying to do exactly what we did last year with Chicken AID. The only difference is we used a USB thumb or an SD card. We used a development board that we created to prototype Chicken AID. The Board uses SPI to communicate to the SD and USB host. We use USART to communicate to the R/C the board has a built in RS232 converter.
Here is the link http://www.crosstheroadelectronics.com/uPICFAT.htm
The development system is around $150. But it is a complete, out of the box solution. It includes the board, the plug in with examples, it also comes with a power supply, LCD and serial cable.
