A Configurable Propeller Boot-loader
jazzed
Posts: 11,803
Hi. Sometime ago there was a discussion of having a runtime hardware configuration for Propeller programs. After going down various paths I decided that, for me at least, an SD card program·bootloader and utility programs would be an appropriate solution. Much of the reason for having a run-time configuration anyway would be for programs that are loaded and run from the SD card rather than being programmed by the Propeller tool.
So, here I present a working "Configurable Propeller Boot-loader" and friends. A summary·of the bootloader and friends is presented here. Three .spin applications, an API module, and documentation are included in the package.
The main drawback of using the bootloader is with·user application code and variable space·limitations. A user application is limited to about 25Kbytes since the bootloader uses 7Kbytes. The getconfig.spin API module which allows convenient access to the EEPROM info uses 1.3Kbytes (320 longs) without accessor methods (1.7Kbytes with). Of this 552 bytes (138 longs) are taken up by the EEPROM.spin code and 596 bytes (149 longs) are taken up by the CRC16.spin code and it's CCITT table (ya, a checksum would be much much cheaper, but data integrity verification would suffer) ... a non-table version of the CRC16 code might be worth considering if really squeezed for space.
As far as future directions go, the configuration data-structure has lots of space available for enhancements. A version field in the data-structure can allow for some type checking. The published version is $10001 where the most significant 1 is the header version and the least significant is the content version. These are provided for developer convenience, and if you make a change to the content datastructure, you should bump the content version number.
Any suggestions for improvements are of course welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So, here I present a working "Configurable Propeller Boot-loader" and friends. A summary·of the bootloader and friends is presented here. Three .spin applications, an API module, and documentation are included in the package.
- A boot-loader "bootloader.spin"·will be compiled/saved in Propeller EEPROM.
- A boot-config app "bootconf.spin" configures the system and should be saved on SD card exactly as·"bootconf.bin".
- An Xmodem app "sdxmodem.spin" allows for downloads to sd-card and should be saved as a .bin on SD card
- An API module "getconfig.spin" can be used by applications to get configuration information.
- A Word document that goes into much user detail is included with the zip package.
The main drawback of using the bootloader is with·user application code and variable space·limitations. A user application is limited to about 25Kbytes since the bootloader uses 7Kbytes. The getconfig.spin API module which allows convenient access to the EEPROM info uses 1.3Kbytes (320 longs) without accessor methods (1.7Kbytes with). Of this 552 bytes (138 longs) are taken up by the EEPROM.spin code and 596 bytes (149 longs) are taken up by the CRC16.spin code and it's CCITT table (ya, a checksum would be much much cheaper, but data integrity verification would suffer) ... a non-table version of the CRC16 code might be worth considering if really squeezed for space.
As far as future directions go, the configuration data-structure has lots of space available for enhancements. A version field in the data-structure can allow for some type checking. The published version is $10001 where the most significant 1 is the header version and the least significant is the content version. These are provided for developer convenience, and if you make a change to the content datastructure, you should bump the content version number.
Any suggestions for improvements are of course welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
zip
78K
Comments
If I could create a relocator running from a separate cog, most of the bootloader space can be saved for apps.
Currently, one could use the original boot-loader code space for buffer data after an application boots. This area can be determined by reading word[noparse][[/noparse]8] and word[noparse][[/noparse]10] word[noparse][[/noparse]12] of memory.
Also assuming one can preserve the first $200 bytes, the EEPROM.spin module would not be necessary to read the original config data for any application.
Thinking out loud
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 8/3/2008 9:29:31 PM GMT
Have you looked at the bootloader in FemtoBasic? In one cog you get an assembly driver for I2C, particularly EEPROM, for SPI, specifically for low level access to SD cards, and a loader that can load a complete Spin program from EEPROM or an SD card and start up a Spin interpreter to run it. The I/O pins to use are specified when the I/O operation is initiated. For SD card use, the FAT file system routines have to provided separately (although they can use the driver to do the I/O) and, for loading, have to furnish the absolute sector number of the start of the file plus the length of the file (and the file has to occupy a single extent).
The cog used for the loader communicates through a two long control block that's specified when the cog is started. It can be placed at the end of hub ram where it normally would not be overwritten during loading.
Post Edited (Mike Green) : 8/3/2008 9:37:33 PM GMT
It wouldn't take much work to add a configuration block design to your code. Then you could use a configuration app like I've provided to choose TV pins, etc ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔