Loading to/from the EEPROM

inakiinaki Posts: 262
edited 2006-04-13 - 23:01:12 in Propeller 1
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·?






▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Comments

  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-04-10 - 17:00:44
    If you want the propeller to be stand alone, the EEPROM is nessesary. There is no onboard EEPROM, so when a serial connection is not present it loads the first 32K of the EEPROM into it's internal memory. The propeller has a heirarchy of Serial then EEPROM in determinining where it gets it's code from. The IDE has a the ability to load the program directly to the propeller's RAM (not stored in EEPROM), or store to EEPROM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    1+1=10
  • inakiinaki Posts: 262
    edited 2006-04-10 - 17:17:18
    >>The IDE has a the ability to load the program directly to the propeller's RAM (not stored in EEPROM), or store to EEPROM.

    So if I understand well there is code into the Propeller that is able to copy from the serial data to the EEPROM ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-04-10 - 17:20:34
    yes F11 will write the compiled program into the EEPROM attached to the propeller.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    1+1=10
  • inakiinaki Posts: 262
    edited 2006-04-10 - 17:28:21
    So. the propeller has some firmware in it, right ? So potentially then there might be several versions of Propellers with different firmware in the future. I did not realize of this possibility.

    What other features does the Propeller have in firmware ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Tracy AllenTracy Allen Posts: 6,545
    edited 2006-04-10 - 18:14:09
    The only firmware in the Propeller chip is the bootloader and the interpreter. Those are hard coded in masked ROM. I think part of the design goal was to avoid having multiple verions of the firmware, and, that in part explains how careful they have been with the design and testing, to get it right the first time.

    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
  • inakiinaki Posts: 262
    edited 2006-04-10 - 19:04:05
    Ooops! so the Spin interpreter itself is in mask ROM ?
    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 ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-04-10 - 19:12:26
    inaki said...

    Is not there a provision to replace the firmware interpreter with an 'external' updated version ?

    no

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    1+1=10
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-04-10 - 20:05:32
    In years to come computer students will groan when their teacher assigns them the task of examining and explaining just how that interpreter could be so compact and yet so elegant...
    (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...
  • Tracy AllenTracy Allen Posts: 6,545
    edited 2006-04-10 - 21:21:47
    Machine code never runs directly from main RAM or ROM.

    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
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-04-10 - 21:26:43
    I think I remember Chip stating that cog0 starts with the bootloader, then loads the spin interpretor over itself when it's done.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    1+1=10
  • GadgetmanGadgetman Posts: 2,436
    edited 2006-04-10 - 21:27:45
    Just wasn't certain whether the bootloader was in fact an assembler program, or if it was 'microcode' hardwired into the system.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • MX21MX21 Posts: 7
    edited 2006-04-13 - 22:56:55
    A couple more questions about the EEPROM:

    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
    ·
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-04-13 - 23:01:12
    1. I haven't looked, but if the protocol is compatible with the 24LC256, then yes.

    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
Sign In or Register to comment.