Propeller OS, FemtoBasic, and SD Cards
Mike Green
Posts: 23,101
This is a "current working copy" of the Propeller OS that has experimental support for SD cards using Rokicki's SPIN driver. There's also an experimental version of FemtoBasic with OS and SD card support for saving programs to EEPROM pages or SD files. To use these properly requires a Hydra with an SD card connected to an expansion card: DO-exp0, Clk-exp1, DI-exp2, CS-exp3. You can also use this with a Demo Board with extra EEPROM connected to pins 4/5 or 6/7 (SCL/SDA) and the SD card connected: DO-pin0, Clk-pin1, DI-pin2, CS-pin3. It should work with the pending Protoboard with the keyboard and VGA adapters wired the same as the Demo Board since that already has an extra 32K of EEPROM. Note that you can't use the VGA version with the Hydra since the expansion bus uses the VGA signal lines.
As usual with the OS, you load the proper binary version of FemtoBasic into the boot EEPROM, then load the proper binary version of the OS into RAM. Once it's running, you do a "copy boot femtobasic" to copy the boot EEPROM with FemtoBasic into some other EEPROM area, then go back and reload the OS, this time into the boot EEPROM. You can copy EEPROM files to SD cards using a "test save <EEPROM file> <SD card file>" command. You can load them back into EEPROM using a "test load <SD card file> <EEPROM file>" command. A "test list" command will list the files in the root directory of the SD card. A "test delete <SD card file>" command will delete the specified file.
With FemtoBasic, the convention is that SD card file names are enclosed in double quotes while EEPROM files are not. To save a program to EEPROM file foobah, use 'save foobah'. To save the program to an SD card, use 'save "foobah"'. The same with loading a program. The "files" command lists both the EEPROM files and the SD card files. For now, "files" will complain if there's no SD card. Similarly, use 'delete foobah' to delete the EEPROM file and 'delete "foobah"' to delete the SD card file.
As in a previous posting, you can read and write data from/to an SD card file. Note that you can only read comma delimited numeric expressions from a file, but you can write anything that you can produce with a PRINT statement (using a WRITE statement for the file).
I expect that these will be buggy. I've done simple testing on a Hydra with a TV display and a Demo Board with both a TV and VGA display (with extra EEPROM attached to pins 6/7). The SD card I/O is slow and that will eventually be fixed. This is intended as a demonstration of what can be done with essentially a Protoboard with the accessory parts along with an SD card with some pullup resistors.
As usual with the OS, you load the proper binary version of FemtoBasic into the boot EEPROM, then load the proper binary version of the OS into RAM. Once it's running, you do a "copy boot femtobasic" to copy the boot EEPROM with FemtoBasic into some other EEPROM area, then go back and reload the OS, this time into the boot EEPROM. You can copy EEPROM files to SD cards using a "test save <EEPROM file> <SD card file>" command. You can load them back into EEPROM using a "test load <SD card file> <EEPROM file>" command. A "test list" command will list the files in the root directory of the SD card. A "test delete <SD card file>" command will delete the specified file.
With FemtoBasic, the convention is that SD card file names are enclosed in double quotes while EEPROM files are not. To save a program to EEPROM file foobah, use 'save foobah'. To save the program to an SD card, use 'save "foobah"'. The same with loading a program. The "files" command lists both the EEPROM files and the SD card files. For now, "files" will complain if there's no SD card. Similarly, use 'delete foobah' to delete the EEPROM file and 'delete "foobah"' to delete the SD card file.
As in a previous posting, you can read and write data from/to an SD card file. Note that you can only read comma delimited numeric expressions from a file, but you can write anything that you can produce with a PRINT statement (using a WRITE statement for the file).
I expect that these will be buggy. I've done simple testing on a Hydra with a TV display and a Demo Board with both a TV and VGA display (with extra EEPROM attached to pins 6/7). The SD card I/O is slow and that will eventually be fixed. This is intended as a demonstration of what can be done with essentially a Protoboard with the accessory parts along with an SD card with some pullup resistors.
Comments
why do you use extra pins for the second EEPROM?
I2C EEPROM can have different addresses, selectable
by the address pins A0-A2. So you can place the second
EEPROM in parallel to the first one, and just connect A0 to
VDD instead of VSS.
You'll have to change your routines to the new address, but
this should be easy.
cu
Karl
You're basically correct, but, on the Demo Board (which I'm using), there's not a good way to get physical access to the I2C pins for the boot EEPROM. You'd have to solder very fine wires to the SMD processor or EEPROM pins or perhaps piggyback another EEPROM on top of the first one. I may try that some day, but it's really fine work and I'm not up for it yet. The OS will automatically recognize additional EEPROM attached to pins 28/29 as it's written and works fine with the additional EEPROM on the Hydra. There's a command in the OS ("probe <pin>") to look on a specific pair of pins for more EEPROM and it remembers what it found (at least until something is downloaded to the boot EEPROM and that table is erased). If you have some other kind of Propeller board where pins 28/29 are accessible, the OS and FemtoBasic will work just fine without any changes if you add more EEPROM as you suggest.
Mike
Did you think about serial flash for program storage?
They are much faster because of the fast SPI interface, so
running code directly from external memory (with caching
in RAM) might be possible.
cu
Karl
The new eval board has double the EEPROM, so I am hanging out waiting for them to use as CNC controllers[noparse]:)[/noparse]
Would have been nice if there was access to P27, P28 for I2C expansion.
Going to need a text editor for G-code editing on the prop, hint, hint.
Gavin
·
I thought about using some of the nice serial flash memories, like the 16M devices from Atmel. I didn't put in support for several reasons:
1) I would need yet another unique file system to organize it. That's a lot of work and code
2) I wanted something on removable media that could be used to transfer files to and from a PC (a standard file system)
3) Removable media also means an open ended storage system. You can always buy another card and store the full one
4) Current removable media are huge. 2GB SD cards are now cheap and widely available
Gavin,
The new Proto-board does have access to all pins including 28/29 so you can add more EEPROM to the boot EEPROM buss.
I thought about using fixed slots of 32k for program storage, instead of using a file system.
A 32Mbit serial flash ( AT45DB321D) would give you 132 slots for complete programs or
modules, without wasting memory for a file system.
Perhaps the first slot should contain an index with filenames.
But you're right, it's not portable.
Post Edited (Kloss) : 1/18/2007 3:17:12 PM GMT
Of course, I don't think there is wear leveling on the EEPROMs. Do any of the EEPROM solutions support 512-byte
blocks, or are they all oriented around larger pages?
I don't think there's any wear leveling on the serial flash memories. The large memories (16MB) use a "funny" block size that's a bit bigger than 512 bytes (528?). Maybe the extra bytes are intended for wear leveling bookkeeping, but the device doesn't do the work for you.
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.