Shop OBEX P1 Docs P2 Docs Learn Events
Booting a P1 from Another Micro — Parallax Forums

Booting a P1 from Another Micro

Brian FairchildBrian Fairchild Posts: 549
in Propeller 1
Before I re-invent the wheel, has anyone written any software that runs on a small micro to load up a P1? Ideally in C and for an 8-bit micro.

I'm aware of Chip's Propeller Loader in the OBEX, and similar that run on desktop machines.

The cheat would be to load up an EEPROM over shared I2C lines and then reset the P1 and let it find the code in the EEPROM.

Comments

  • David BetzDavid Betz Posts: 14,516
    How about just having the small micro emulate an EEPROM?
  • Brian FairchildBrian Fairchild Posts: 549
    David Betz wrote: »
    How about just having the small micro emulate an EEPROM?

    Hmmm, that's an approach I hadn't thought of. Thanks.
  • Brian FairchildBrian Fairchild Posts: 549
    Brian Fairchild wrote: »
    David Betz wrote: »
    How about just having the small micro emulate an EEPROM?
    Hmmm, that's an approach I hadn't thought of. Thanks.

    Looks like it might not be so easy. A small micro will struggle to keep up with the P1 which appears to run the I2C at 400kHz. That's a sustained rate of 2.5us per byte and it doesn't look like the P1 supports clock stretching.
  • GenetixGenetix Posts: 1,754
    Brian,

    What is it that you are trying to do?
  • jmgjmg Posts: 15,173
    Brian Fairchild wrote: »
    Looks like it might not be so easy. A small micro will struggle to keep up with the P1 which appears to run the I2C at 400kHz. That's a sustained rate of 2.5us per byte and it doesn't look like the P1 supports clock stretching.

    You mean 2.5us per bit ? - a Small MCU might be able to keep up with 22.4us byte rate, especially one with HW i2c ?

    There may be useful links here - P1 uses a modest encryption scheme :

    https://forums.parallax.com/discussion/164279/parallax-supported-command-line-tool-to-load-the-p1-solved
  • Brian FairchildBrian Fairchild Posts: 549
    Genetix wrote: »
    What is it that you are trying to do?

    I want to load different code into the P1 under the control of another micro.

    The P1 is a slave IO processor to the other processor which is the master and control 'what' is happening.
  • Brian FairchildBrian Fairchild Posts: 549
    jmg wrote: »
    There may be useful links here...

    Thanks. PLoadLib.c looks like what I want.
  • GenetixGenetix Posts: 1,754
    Brian,

    Using the Propeller as an I/O slave is what it was designed for and others commonly have the Propeller load extra code from a large EEPROM.
    The Hydra for example grabs graphics data from the EEPROM.

    Are you forgetting that the Propeller has 8 Cogs that can be started and stopped at any time?
    I would think that you would want to offload as much work to the Propeller as possible so your uC has more processing rime.
  • Brian FairchildBrian Fairchild Posts: 549
    Genetix wrote: »
    Using the Propeller as an I/O slave is what it was designed for...


    Thanks. FYI, I have been using the P1 for over 10 years and have it in a few commercial applications.

    In this application the P1 will be connected to another chip with plenty of spare flash memory and I specifically want to frequently reconfigure it. Hence my need to have full control over what gets loaded.
  • GenetixGenetix Posts: 1,754
    Brian,

    I didn't mean to insinuate that you are ignorant of the Propeller but I can not understand why you want to treat it as 'dumb' device.

    Also, how do you plan to handle a situation where the Propeller re-programming should fail?
    You could have the Propeller reconfigure itself based on what commands or configuration instructions it receives.

    I think you would want to avoid doing any Propeller programming so why not have your uC control the Enable/Select pins of a group of EEPROMs with Prop code on them.
    Select the one that you want and Reset the Propeller and that code will be executed.
  • jmgjmg Posts: 15,173
    There are multiple approaches to this, and a UART pathway has some merits
    EEPROM boot always loads a full 32k image, and is not fast.
    ReProgramming is also finite, and has endurance limits.
    Of course, there is FRAM, but that costs quite a bit more, and with a MCU hosted serial boot, you do not actually need any EEPROM at all.

    Serial boot needs some P1 specific shuffles, but it sends a length then data, so that can be fast once it is working.

    This comment "and I specifically want to frequently reconfigure" sounds like endurance and speed both matter.
    With a MCU Host, you can also bump the baud rate, FWIR it can be close to doubled ~ 200kBd and even a 2 stage loader could be contemplated.
  • Cluso99Cluso99 Posts: 18,069
    But micros often have lower endurance flash!
  • jmgjmg Posts: 15,173
    Cluso99 wrote: »
    But micros often have lower endurance flash!

    Well, yes, but the assumption here was the OP has a selection of P1 code-images are sitting in that 'chip with plenty of spare flash memory', so the flash is not actually being 'frequently reconfigured', the P1 is.
    ie the P1 is being used as a reconfigurable peripheral.
  • Cluso99Cluso99 Posts: 18,069
    jmg wrote: »
    Cluso99 wrote: »
    But micros often have lower endurance flash!

    Well, yes, but the assumption here was the OP has a selection of P1 code-images are sitting in that 'chip with plenty of spare flash memory', so the flash is not actually being 'frequently reconfigured', the P1 is.
    ie the P1 is being used as a reconfigurable peripheral.
    So the P1 does not need an EEPROM because it can be loaded straight to hub RAM.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-01-22 02:25
    Sure, I get that you want to be able to download firmware to a Prop from another micro. I've done that with "other" micros but mostly with another Prop that has more resources and is more central and connected to a PC or Ethernet. If the Prop is close then you can use its serial boot protocol along with the reset line, or you program the EEPROM of the Prop easily along with persistent values and so the Prop can still run standalone if need be. I'd look after the reset line though and use an NPN on the Prop side so it takes a valid high signal to reset the Prop.

    As for endurance, I think we've been down this road a "million" times before. Reprogram your Prop 100 times a day? If you did then that's 36,500 times a year. The EEPROM is "guaranteed" for a "minimum" of a million erase/write cycles and believe me, there is no problem with this number. So 100 times a day, 36,500 times a year for 1 million cycles brings us to over 27 years. Is that a problem????
  • Brian FairchildBrian Fairchild Posts: 549
    Genetix wrote: »
    Brian,
    ...but I can not understand why you want to treat it as 'dumb' device.

    Not as a dumb device but letting it do what it is good at. IMHO the P1 makes a good 'bit banger', but is not so good as a general purpose processor. But that, as I say, is IMHO.

    jmg wrote: »
    ...a UART pathway has some merits... and with a MCU hosted serial boot, you do not actually need any EEPROM at all.

    Hadn't thought of that, something to look into.

    jmg wrote: »
    Cluso99 wrote: »
    But micros often have lower endurance flash!
    ...ie the P1 is being used as a reconfigurable peripheral.

    Exactly.

    Cluso99 wrote: »
    So the P1 does not need an EEPROM because it can be loaded straight to hub RAM.

    That's what I'm aiming for. Although...

    Peter Jakacki wrote: »
    ...can use its serial boot protocol along with the reset line, or you program the EEPROM of the Prop easily along with persistent values and so the Prop can still run standalone if need be.

    I can see some merit in a shared I2C approach where the P1 is held in reset while the other micro programs the EEPROM, releases its I2C lines and then lets the P1 run and load from the EEPROM.

    I've got another design to finish off and get boards made, and then I can get a prototype built.

    Thanks again for the ideas. Always appreciated.
Sign In or Register to comment.