Propeller Boot Loader
Mike Cook
Posts: 829
Any thoughts on doing a serial boot loader for the Propeller Chip to load the 32K EEPROM?
I realize that when the Propeller first starts up that it looks at P31 & P30 for a host and then at P29 & P28 for the eeprom. If none are found then it goes to low power mode. My thoughts is a small *.spin program to load the default 32k eeprom if no application exists in the 32k eeprom. However the boot loader would have to survive for future serial loading. One option, that I think might work, would be to use the addressing feature of the I2C EEPROM
History:
I·use a lot of the AVR Mega32 in most of my 'one-off' prototype work and love the ability to have a serial boot loader. This way when I write 'Smile for code' or the client wants different behavior, I can just send the client a new *.hex file to load via xmodem & Microsoft Windows Hyperterm.
Future:
I would like to standardize on uPs. The Propeller looks to be quite·promising despite it's 'Quantity 1' pricing. But to implement this a simple serial boot loader for the client would be necessary. Most of my 'one-off' prototypes or 'proof-of-concept' designs have at least a serial interface, even if it not used. A serial boot loader for the Propeller would be a definite plus!
<edit>
Comparing the AVR Mega32 to the Parallax Propeller is an "Apples to Oranges' comparison, they both have their appropriate uses. And per chip pricing is irrelevant.
</edit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Post Edited (Mike Cook) : 5/27/2006 12:47:09 AM GMT
I realize that when the Propeller first starts up that it looks at P31 & P30 for a host and then at P29 & P28 for the eeprom. If none are found then it goes to low power mode. My thoughts is a small *.spin program to load the default 32k eeprom if no application exists in the 32k eeprom. However the boot loader would have to survive for future serial loading. One option, that I think might work, would be to use the addressing feature of the I2C EEPROM
History:
I·use a lot of the AVR Mega32 in most of my 'one-off' prototype work and love the ability to have a serial boot loader. This way when I write 'Smile for code' or the client wants different behavior, I can just send the client a new *.hex file to load via xmodem & Microsoft Windows Hyperterm.
Future:
I would like to standardize on uPs. The Propeller looks to be quite·promising despite it's 'Quantity 1' pricing. But to implement this a simple serial boot loader for the client would be necessary. Most of my 'one-off' prototypes or 'proof-of-concept' designs have at least a serial interface, even if it not used. A serial boot loader for the Propeller would be a definite plus!
<edit>
Comparing the AVR Mega32 to the Parallax Propeller is an "Apples to Oranges' comparison, they both have their appropriate uses. And per chip pricing is irrelevant.
</edit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Post Edited (Mike Cook) : 5/27/2006 12:47:09 AM GMT
Comments
serial traffic you want. If it doesn't find activity, it just loads from the upper 32K of the EEPROM. This
will require using a 64K EEPROM, but I think these are not too outrageous. This way you can use whatever
detection method you want for external traffic.
Or if the boot loader is small, say 8K, then just use the lower 8K of a 32K EEPROM for this, and have your
"real" boot loader either reload from the remaining 24K, or just shift the memory contents that are
already loaded on down.
Doing a boot loader on the Propeller is probably pretty simple because each cog has its own 2K of memory
that does not depend on the 32K hub memory at all.
You feed it the address of a 32k eeprom, and it copies that eeprom over the existing eeprom when it's done, it resets the propeller. The code is simple enough, and it's an object that's callable in code. Only requirement is that the core loder code must exist between both eeproms, and all vars must be saved to eeprom to survive the reset. I'm waiting on hardware to finish debugging the code. I'm sure, with some programming, this could be used to fit your requirements.
I'm working on identifying how the compiler assigns var space, so I could directly save vars into the var space in eeprom.
Sort of like changing a constant by overwriting in in eeprom. My thoughs on this is a simple little object to presist vars between resets. But this is a nother topic...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·