Loading to/from the EEPROM
inaki
Posts: 262
In the basic board designs·that have been shown·here in the forum, before the demo board is available, there is an EEPROM. Is·the EEPROM·loaded with code ? I mean·is it·intended to store the code to be loaded by Propeller or is just there to store data ?
The code to be run in the Propeller is loaded from the USB2SER directly or is loaded from the EEPROM ? If it is the later, how is·the code loaded to the EEPROM itself·?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The code to be run in the Propeller is loaded from the USB2SER directly or is loaded from the EEPROM ? If it is the later, how is·the code loaded to the EEPROM itself·?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
So if I understand well there is code into the Propeller that is able to copy from the serial data to the EEPROM ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
What other features does the Propeller have in firmware ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When you have the Propeller connected to a computer, F10 puts the current project in propeller RAM and runs it (and does not do anything to the eeprom). F11 burns the program into the attached 32k eeprom and also into RAM and runs it. F12 loads the program into eeprom, without running it. The program is stored in the first 32k of a eeprom that follows the same protocol as the 24LC256, at I2C address 0.
The bootloader firmware, upon power up or reset, sets the clock to internal 12mhz, and first checks for a BREAK condition on the serial line on p31. If that is present, it expects to receive program data from the serial line p30/p31. If the BREAK condition is not present, it then looks for an eeprom on pins p28 and p29. It loads (mirror image) the bytes from that 32k eeprom into the 32k of main RAM. If no eeprom is present, it would just go to sleep. Note that it starts operation using the 12mhz internal RC clock, so it does not even need a crystal to operate the bootloader.
After the first stage of the boot up sequence, with code present in main RAM, it boots a copy of the interpreter (512 longs) from the ROM up into COG 0. That concludes the bootup sequence. The interpreter starts executing Spin code from the top.
The ROM is 32kbytes, but a relatively small part is devoted to images of the bootloader and the interpreter firmware. The rest is devoted to the character tables, the sine table, and the log and anitlog table.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I thought it was uploaded each time from the PC !
That would mean that even the minor change in the interpreter would require a new mask ROM ? :-(
Is not there a provision to replace the firmware interpreter with an 'external' updated version ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
(I don't think it is possible to write so compact and advanced code without at the same time doing it elegantly. Do just ONE 'shortcut' and you end up with a complete mess)
Yes, I'm going to read it out and study it.
Why?
Because it's possible...
(I imagine that it will be nearly impossible to fully understand, but then again... I also like big jigsaw puzzles)
A little question...
The Bootloader is 'executed' by the HUB itself, not a COG?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
While it is true that the byte code acted on by the interpreter(s) resides in main RAM, the interpreter(s) itself and other machine code routines run within COGs.
That includes the bootloader. I'm not sure if it runs from COG0 or from some other COG but it would not matter. It ends by booting up a copy of the interpreter into COG0. The COGINIT or COGNEW are low level instructions, that simply copy an entire COG's worth of longs from the main RAM into a selected COG, intitialize the COG registers, and start executing at COG location 0. That code can be either your own routine, or another instance of the SPIN interpreter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
1) Will the boot loader work with a 24LC512?
2) If it will use the 24LC512, can I use the upper 32k for data storage?
3) Is there a way to use the bootloader i2c to read/write that eeprom from spin?
Thanks,
MX
·
2. If yes to #1, yes
3. No, but anyone can write a generic I2C object that can use the program EEPROM SDA/SCL pins.· That's on my list of things to do soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax