Shop OBEX P1 Docs P2 Docs Learn Events
Bootup serial protocol — Parallax Forums

Bootup serial protocol

HollyMinkowskiHollyMinkowski Posts: 1,398
edited 2009-06-16 06:10 in Propeller 1
Is there any documentation that describes precisely the protocol the Propeller
uses when it first powers on and attempts to communicate using pins 30,31 ?

It would be nice to make a portable device that you could hook to those pins and program the eeprom
connected to a propeller. I'm thinking of being able to easily reprogram devices in the field.

Comments

  • whickerwhicker Posts: 749
    edited 2009-06-14 23:35
    you need something to store the program anyways, right?
    so if you use a serial eeprom, it is just a matter of having a pluggable device with the eeprom.
  • BradCBradC Posts: 2,601
    edited 2009-06-14 23:48
    Yes there is plenty of "documentation" around in the form of source code. In the OBEX there is an object called Propellerloader that will allow you to program one propeller from another. Also in the forum archives are some snippets of Delphi code that Parallax posted to demonstrate loading the propeller from a PC. There are also a number of other projects people have posted source to from time to time in various languages (VB, Python, .Net).. It's not difficult to do, but the handshake can be a bit finicky with timing if you are doing it from a PC. From another micro it would be a doddle. You could quite easily create a little propeller based doohickey that you selected images with a little LCD and loaded them from SD card.

    I've attached a copy of bootsequence.spin which has a bit of documentation on the process.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Eccles : How do I open the door?
    Bluebottle : You turn the knob on your side
    Eccles : I haven't got a knob on my side!
    spin
    spin
    bootsequence.spin
    3K
  • HollyMinkowskiHollyMinkowski Posts: 1,398
    edited 2009-06-14 23:55
    @whicker

    Yes, of course you are right smile.gif

    I'm still living with the mindset of controllers that have flash/eeprom on board.
    It is simpler to just program the eeprom directly..doh.
    I could just use an AVR butterfly to do the programming..it has a nice lcd and
    lots of eeprom storage.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-06-15 07:00
    Does your portable device maybe have an SD Card for storing whatever?? You could add a piece of code that searches for an update on the SD card then. If a different version is found, then it copies that image to EEPROM. No need for an AVR. Just put the new image on the SD card and that's it.
  • HollyMinkowskiHollyMinkowski Posts: 1,398
    edited 2009-06-15 08:41
    @MagIO2

    The project does have an SD card for storing data. You are right, the updates could just be added to it.
    Now why didn't I think of that..it seems so obvious smile.gif
  • agodwinagodwin Posts: 72
    edited 2009-06-15 10:54
    The snag with using the SD card is that you're relying on the propeller running the update code. If you've bricked it, it won't do that.

    A method that uses the eeprom connection or the usual prop boot connection gives you better recovery options.

    Of course, you might find it useful to have both an easy-to-use SD method and a serial de-bricking method. Depends on your application.
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-06-15 12:04
    The update-tool itself can stay the same with each release of the SW. So, there is no need to overwrite that part of code if you write the update to the EEPROM. This ensures that the beginning of the program (check for new version) will always run. So, even if the updated code does not run you can still do updates.

    Tricky part of that is how to figure out where the updater starts and where it ends.

    Another solution:
    Have a second EEPROM which contains the updater. If you press a button during boot, it loads the updater, otherwise the program.
  • HollyMinkowskiHollyMinkowski Posts: 1,398
    edited 2009-06-15 12:26
    @MagIO2
    "Have a second EEPROM which contains the updater. If you press a button during boot, it loads the updater, otherwise the program."


    Hey, that's a really good idea...thanks smile.gif
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-06-15 13:23
    Ok ... let's go on with that idea:

    Hardware solution:

    · 
         _____ -> to Adress pin of EEPROM1 with pullup
____/
|    _____ -> to adress pin of EEPROM2 with pullup AND with capacitor to reset pin of Propeller
|
GND

    If you press the pushbutton short it's a reset only, but still loading from EEPROM1
    If you press the pushbutton until the prop went over the "Load from PC" waittime, it's loading from EEPROM2
    Drawback: the pushbutton can't be used for other things during runtime.

    Software solution:
    EEPROM adresses are fixed.
    You first load the Updater-code. The updater checks the pushbutton and if pressed starts EEPROM programming.
    Otherwise it loads the whole RAM with the code from EEPROM2 (like the FEMTO SD card driver) and restarts from beginning.
    The pushbutton can be used for other functions during runtime.
    Drawback: the EEPROM2 is not reachable through PC load to EEPROM-function.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-06-15 14:18
    The YBOX2 is a Prop box that can update itself over the Internet. It uses a 64K EEPROM and loads the received program into the 2nd half of the EEPROM, then executes it from there. The 1st 32K always contains the Internet bootloader. If you need to update the bootloader, there's a modified version of the new bootloader that gets downloaded like any other program to the 2nd 32K, then executed from there. I believe that it then downloads another copy of the new bootloader to the 1st 32K to replace the old one. Personally, I would embed the new bootloader in the update program downloaded to the 2nd 32K. The update program would do an additional CRC validation on the embedded bootloader before copying it to the 1st 32K of the EEPROM. You'd use the FILE directive to get the new bootloader as a data block into the update program.
  • AribaAriba Posts: 2,690
    edited 2009-06-15 20:44
    HollyMinkowski said...
    @MagIO2

    The project does have an SD card for storing data....

    In that case, you can just have a bootloader in the EEPROM, which starts an application-binary from SD card.
    For an update you can always overwrite this binray with the newest version (i.e. with a cardreader on the PC).

    Andy
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-06-15 20:52
    Holly,

    I'd go with Mike's suggestion of the Ybox2 - it's pretty useful, and there's a fair amount of discussion on it scattered throughoutt the forum. " FILE " makes it so much simplier to manage.
    Plus, it can be packaged in a client-friendly, mouth-watering, container: http://www.deepdarc.com/ybox2/

    - Howard

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Got Electrons?
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-06-16 06:10
    @Ariba
    Yep, and if you have no SD card inserted your system won't even boot properly. That's why I recently moved all my drivers to upper EEPROM. So, it depends on the application. If the SD card is mandatory anyway then you can keep the image on the SD cars.
    But it also adds boot-time, as you have to boot twice. First the propeller boots the whole 32k from EEPROM which only contains a <2k bootloader and then you load up to 32k again from SD to run the real program.
Sign In or Register to comment.