Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Loader — Parallax Forums

Propeller Loader

cgraceycgracey Posts: 14,133
edited 2014-10-29 13:46 in Propeller 1
This object lets you load/program one Propeller from another·Propeller·(instead of a PC).

This function may be a little early for most users, but·the object·demonstrates how ABORTs are used - they can get you all the way out of deep mess in a snap.

I will augment this object later for loading an array of Propeller chips (ie. the old Propeller Supercomputing thread).
·

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


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 6/14/2006 6:35:34 AM GMT

Comments

  • Cliff L. BiffleCliff L. Biffle Posts: 206
    edited 2006-06-15 01:19
    Neat! I may have to take back some of my comments in the Operating System thread; this looks like most of what I'd need to program a binary onto the Propeller from $OS_HERE. (Not that the binary format is documented. One step at a time...)

    What's the deal with the 500-bit exchange from the LFSRs? Checking that you're talking to the right device and that the link is working?

    Is the bitrate here fixed, or derived from the initial synchronization pulse?
  • cgraceycgracey Posts: 14,133
    edited 2006-06-15 01:35
    Cliff L. Biffle said...
    Neat! I may have to take back some of my comments in the Operating System thread; this looks like most of what I'd need to program a binary onto the Propeller from $OS_HERE. (Not that the binary format is documented. One step at a time...)

    Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

    What's the deal with the 500-bit exchange from the LFSRs? Checking that you're talking to the right device and that the link is working?

    That's right. It makes sure that both parties are not false-triggering.

    Is the bitrate here fixed, or derived from the initial synchronization pulse?

    It's all derived from the initial two pulses. The whole time the Propeller is loading, it's running off its fast internal RC oscillator which might be from 8MHz to 20MHz, but nominally 12MHz. Whatever its frequency is, it's pretty stable. If your top-level Spin file calls for a crystal and PLL, those things get turned and allowed to stabilize for 20ms before they are switched over to and your app begins executing.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Chip Gracey
    Parallax, Inc.
  • Cliff L. BiffleCliff L. Biffle Posts: 206
    edited 2006-06-15 01:49
    [noparse][[/noparse]quote]Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

    Neat. Everything I'd want to program from (my workstations and my robot's central controller) have UARTs, so this should be straightforward.

    (You must have been very worried about false-triggering to use such a grandiose handshake. smile.gif )
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-06-15 13:27
    Chip:
    This is sweet!
    I guess it might be time for me to get the second propeller onto the breadboard and make-em co-work!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Just tossing my two bits worth into the bit bucket


    KK
    ·
  • MuncherMuncher Posts: 38
    edited 2006-06-18 04:21
    could you use this to create self-developing programs?
  • RinksCustomsRinksCustoms Posts: 531
    edited 2006-06-18 05:39
    You speak of AI (Artificial Intelegence), what a wonderful and terrifying idea.....
  • IAI-CaptainIAI-Captain Posts: 33
    edited 2006-06-18 08:40
    to RinksCustoms:
    Sorry to nag!
    But, Please consider:
    No form of Intelligence is Artificial! And that All forms of Intelligence·are Real!
    It's not the Intelligence that's Artificial!
    It's the thinking medium that's not biological in it's nature. (IE. Silicon·compared to biological Carbon based organisms.)
    One day, soon, machines and their Intelligence will be indistinguishable from human intelligence.
    The Turing test will be passed.
    Please consider the term, "Machine Intelligence", instead.
    Check out the book' "GROWING UP WITH LUCY: How To Build An Android In Twenty·Easy Steps", By STEVE GRAND
    and or the book,·"CREATION: Life and How·to Make It", ALSO BY STEVE GRAND

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    IAI (Indigenous Alien Intelligence),
    The New View on Machine Intelligence.
    Because There is nothing Artificial about it!
  • Cliff L. BiffleCliff L. Biffle Posts: 206
    edited 2006-06-18 23:43
    Muncher said...
    could you use this to create self-developing programs?

    Believe me, I'm already thinking about genetic programming on this beast. Being able to load a new image without hitting an EEPROM could make for some seriously fast generations.
  • Michael O'BrienMichael O'Brien Posts: 55
    edited 2009-01-07 03:33
    Hi,
    I would really like to get the PropellerLoader.spin code working but I am having trouble just before the chip version exchange section.
    I inserted some debugging code and cannot get past the following section without an abort ErrorConnect.

    'receive and verify LFSR pattern
    repeat 250
    if WaitBit(1) <> IterateLFSR

    So, calibration, LFSR send work, I fail at LFSR receive and don't get to the chip version exchange.

    I followed the hardware setup for BOEn and the VSS tied 1M resistor as well as different combinations of clock PLL speeds (this shouldn't matter as only the internal RC is used during bootup right?) including the default internal one.
    There seems to be no problem with either 40 pin dip, I set BOEn back to VSS and temporarily connect the 2nd propeller to its' own eeprom and prop plug and it works fine using two separate propeller tool IDE's. The PropellerLoader.spin in this configuration only resets prop2 which then boots normally from eeprom if p31/p32 serial comm fails as described in section 3.1 of the propeller datasheet.

    thank you
    /michael
  • Paul BakerPaul Baker Posts: 6,351
    edited 2009-01-08 19:52
    The Propeller chip will time out if it doesn't receive information in a set time frame, if you are adding debugging information in one of those critical windows, you run the potential of timing out the Propeller and breaking the downloading process.

    If you must add debugging information, create another thread to handle processing debugging information. The Propeller Tool has a dedicated thread which handles nothing but the downloading process so that system calls do not affect it's timing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker


    Post Edited (Paul Baker) : 1/8/2009 7:57:30 PM GMT
  • RumpleRumple Posts: 38
    edited 2009-11-18 16:32
    Chip Gracey (Parallax) said...


    I will augment this object later for loading an array of Propeller chips (ie. the old Propeller Supercomputing thread).
    ·
    Just wondering if this plan ever came to fruition.· If so, I can't seem to find it.

    Sounds very useful.

    Regards,
    Tim
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-11-18 16:50
    Yes there is a thread describing how to load a group of propeller chips but I cannot recall it's title or link. Maybe someone else can chime in.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Michael O'BrienMichael O'Brien Posts: 55
    edited 2009-11-19 03:45
    See the work by Christian, Ken and Pems in 2008
    http://forums.parallax.com/showthread.php?p=758971
    /michael

    Post Edited (Michael O'Brien) : 11/21/2009 2:00:18 AM GMT
  • Clock LoopClock Loop Posts: 2,069
    edited 2011-09-14 20:21
    The descriptions behind the various programming modes isn't clear.

    #0, Shutdown, LoadRun, ProgramShutdown, ProgramRun

    I figured ProgramRun would take the binary file you include and dump it onto the props eeprom.
    And then that prop would run its program.

    I can get LoadRun to work, but it will not program the props eeprom.

    I looked at the code in propeller loader, and it looks as if the code is incomplete for program modes "ProgramShutdown, ProgramRun"

    Can anyone confirm this?






    Oh, and about the wiring of props with proploader, I did it with 55 props that get parallel programmed when wired right.
    http://forums.parallax.com/showthread.php?127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.
  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-14 21:07
    These programming modes command the "slave" Propeller. Shutdown sends a program to the other Propeller, then forces it to halt ... doesn't accomplish much really. LoadRun sends a program to the other Propeller where it's stored in RAM, then executed. ProgramShutdown sends a program to the other Propeller, causes the other Propeller to copy the program to EEPROM, then halt without executing the program. ProgramRun is like LoadRun except the program is copied to EEPROM before executing. Essentially, if the high order bit of the mode is one, the program is copied from RAM to EEPROM. If the low order bit of the mode is one, the program is run from RAM.

    Remember that the loader is for the "master" Propeller. It only sends the program to the other Propeller (along with the programming mode value). The "slave" Propeller's bootloader (in ROM) does the rest of the work.
  • idbruceidbruce Posts: 6,197
    edited 2011-09-15 00:37
    @Mike

    That was a very nice answer! I truly believe that answer should be added to object within this thread and the OBEX to make it "GOLDEN" :) Or at least I think it is in the OBEX.

    It is already a very nice object, but that clarification should be made within the spin file.

    Bruce

    EDIT: I added that description to my copies of that file.
  • VGVG Posts: 32
    edited 2011-12-29 18:36
    Hi All,
    I am receiving non readable character from my set up.

    Connection: PC <-> Proto board (master) <---> Slave (Prop DIP on breadboard)

    The slave blinks LED and it seems to be working.
    But characters I type in PST are coming back strange.
    Image:
    Prop returning junk characters.jpg



    Image from PST:


    Master Loader.spin:
    (Calls loader sends bytes from slave to PC and PC to slave)
    CON
       _clkmode  = xtal1 + pll8x
       _xinfreq  = 5_000_000
    
      #1, ErrorConnect, ErrorVersion, ErrorChecksum, ErrorProgram, ErrorVerify
      #0, Shutdown, LoadRun, ProgramShutdown, ProgramRun
      
      ' Set pins and baud rate for PC comms 
      PC_Rx     = 31  
      PC_Tx     = 30
      PC_Baud   = 9600   
    
      ' Set pins and Baud rate for Slaveee comms  
      Slave_Rx     = 1    ' Slaveee DOUT
      Slave_Tx     = 5    ' Slaveee DIN                  
      Slave_Baud   = 9600
    
      LED_PIN   = 16
                                       
    
    DAT loadme file "Serial_Loopback.binary"
    
    OBJ
      PC  : "FullDuplexSerial"             
      Slave      : "FullDuplexSerial"
      loader  : "PropellerLoader"
    VAR
    
      long P31, P30, LFSR, Ver, Echo
      long stack[50]                ' stack space for second cog
     
    
    pub mainPrg |i
      dira[LED_PIN]   :=1
      outa[LED_PIN] := 1
    
      dira[15] := 1
      outa[15] := 1
      
      Delay(1000)
      i := loader.Connect( 3,5,1,1,ProgramRun,@loadme )           'Load
      PC.dec(i)
      PC.tx(13)
      PC.start(PC_Rx, PC_Tx, 0, PC_Baud)                   
      Delay(4000)
      outa[LED_PIN] := 0                                       
      outa[15] := 0
      StartComm                                                'Pass through
       
    
    Pub  StartComm |i
      Slave.start(Slave_Rx, Slave_Tx, 0, Slave_Baud) ' Initialize comms for Slaveee  
      cognew(Slave_to_PC,@stack)       ' Start cog for Slaveee--> PC comms
    
      PC.rxFlush                    ' Empty buffer for data from PC
      repeat
        Slave.tx(PC.rx)                ' Accept data from PC and send to Slaveee
           
    Pub Slave_to_PC  |i
    
      Slave.rxFlush                    ' Empty buffer for data from Slave
      repeat
        PC.tx(Slave.rx)
    
    
    {{ Clock Functions }}
    Pub Delay(mS)
    '' Delay ring
    '' Delay(1000)     ' pause 1 second
      waitcnt(clkfreq/1000 * mS + cnt)
    


    Code loaded into slave with eeprom (no xtal) :::: Serial_Loopback.spin

    CON
      _clkmode = RCFAST
    
    
      ' Set pins and baud rate for PC comms 
      Mastr_Rx     = 31  
      Mastr_Tx     = 30
      Mastr_Baud   = 9600      
       
    Var
      long stack[50]                ' stack space for second cog
                                                                           
    OBJ
      Master: "FullDuplexSerial"  
    
    Pub  Start   |i
      dira[15] := 1
      outa[15] := 1
      waitcnt(clkfreq * 4 + cnt)
      outa[15] := 0
      
      Master.start(Mastr_Rx, Mastr_Tx, 0, Mastr_Baud) ' Initialize comms
    
      Mastr.rxFlush                    ' Empty buffer 
    
      repeat
         Mastr.tx(Mastr.rx)
    
  • kuronekokuroneko Posts: 3,623
    edited 2011-12-29 19:00
    VG wrote: »
    I am receiving non readable character from my set up.
    Serial_Loopback runs with RCFAST. The FullDuplexSerial object relies on the clkfreq setting for its baud rate calculations. Most likely your RCFAST isn't close enough to 12MHz (built-in setting) for this to work. I know that my demobard runs at 13MHz so manually changing long[0] to 13M before starting FDS works for me. So either give your slave an XTAL or figure out the real RCFAST rate (monitor a slave square wave from your master).

    And if you post code please use [noparse]
    
    [/noparse] tags.                        
  • VGVG Posts: 32
    edited 2011-12-29 19:52
    Thank you kuoneko. I thought clkfreq will be set based on clkmode. I am not sure. I am googling more info about it.
    How can I monitor the slave sqwave? Is there an object??

    VG.
  • kuronekokuroneko Posts: 3,623
    edited 2011-12-30 01:14
    VG wrote: »
    Thank you kuoneko. I thought clkfreq will be set based on clkmode. I am not sure. I am googling more info about it.
    How can I monitor the slave sqwave? Is there an object??
    It is based on _clkmode but RCFAST can be anything from 8..20MHz. The value stored in clkfreq (long[0]) is 12MHz no matter what the actual frequency is (the compiler has to put something in there).

    For measuring the frequency simply generate a square wave on the slave side (use a counter or the Synth object which is part of the PropTool library) and you can use [thread=123170]Bean's frequency counter[/thread] on the master side.

    Update: or simply try all possible frequency values from 8..20MHz in say 500kHz steps and go from there. At some point the master should get it.
  • Cluso99Cluso99 Posts: 18,066
    edited 2011-12-30 11:01
    You could generate 5MHz on a master output pin and connect this to Xin on the slave, and then the slave will have a 5MHz clock to give 80MHz operation with PLLx16. Alternately you could output 80MHz to Xin and use PLLx1 (see _clockmode in the manual)

    Just in case you have not realised, the manual is available in the help section of PropTool (it's downloaded as part of the PropTool set of info, including some demo programs and tutorials)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-30 12:28
    Cluso99 wrote:
    Alternately you could output 80MHz to Xin and use PLLx1 (see _clockmode in the manual)
    No you can't. All the PLL modes specify a clock source between 4 and 8 MHz, although ~14 MHz seems to be the real maximum. 80 MHz is way over the horizon. You could probably use XINPUT by itself, though, without the PLLx1.

    -Phil
  • Cluso99Cluso99 Posts: 18,066
    edited 2011-12-30 14:28
    Of course you are correct Phil. I was thinking about the XIMPUT mode without PLL.
    Preference is of course not to route high frequency clock signals.

    Its amazing what old threads can dig up and remind you of. The download mechanism can be faster to boot than eeprom loading because the download is only for the length of the data whereas the eeprom is always 32KB, plus the fact that the download has to timeout.

    The other interesting bit to look at is the fixed locations at the beginning of the binary. The length is contained within this.

    BTW: Did you note Chip provided for revisions/versions of the Prop chip. Amazing we still have only 1 version - meaning no revisions due to bugs. Take a look at the AVRs etc to see the revisions, and these are only variations of families of chips and they often run to Rev E.
  • VGVG Posts: 32
    edited 2011-12-31 21:56
    Happy New year.
    I used the following code to sense the frequency:

    SLAVE on pin 26
    CON
    _clkmode = rcfast 
    
    PUB NCO_single_ended_mode
    ' mode PLL BPIN APIN
    ctra := %00100_000 << 23 + 1 << 9 + 26 'Establish mode and APIN (BPIN is ignored)
    frqa := $8000_0000 'Set FRQA so PHSA[31] toggles every clock
    dira[26] := 1 'Set APIN to output
    repeat 'infinite loop, so counter continues to run
    

    Master: Bean's "Freq Counter Simple.spin" code. Thank you Bean.
    My output is around
    3900 only.

    I was expecting in the range of 8Mhz to 12Mhz. This is way below. Did I miss something.



    VG
  • kuronekokuroneko Posts: 3,623
    edited 2011-12-31 22:22
    VG wrote: »
    My output is around 3900 only. I was expecting in the range of 8Mhz to 12Mhz. This is way below. Did I miss something.
    Interesting. That is indeed rather low. What unit is this? I just checked RCFAST/256 and I get 52.8kHz (external multimeter) which puts this particular board at 13.5MHz. Can the master measure say a 20MHz square wave from itself correctly (frqx := $40000000 @80MHz)?

    FWIW, with your NCO setup you should see clkfreq/2 so something around the 6M mark. Also, how do you have your setup wired (signal/GND)?
  • VGVG Posts: 32
    edited 2012-01-01 13:25
    Kuroneko thanks for that hint. Originally my slave was on a separate circuit sending ONLY the clock signal to the master. I had only around 3K (upto 9K sometimes). I got your hint to share GND. After powering slave from the protoboard (master) I am getting around 6.657MHZ (or at 13MHz). Thank you.
    VG.
  • RockyDRockyD Posts: 17
    edited 2012-08-27 09:31
    I have found that there is a problem with this object with RCFAST. This might have been mentioned in other threads. I have found a work around where the first 250 bits of IterateLFSR can be per-computed into an array. This lets it get past the first 150ms timeout inside of the boot loader until it gets refreshed. It seems a better solution would be to write this routine in PASM, since there is not much time to spare with RCFAST.

    With the propeller internal boot code, that first 150ms timeout, to get 250 bits, is the biggest speed hurdle to pass. The rest of the boot code will extend the timeout when the boot code sends bits and revives longs.

    I found a mention of the T1 and T2 pulses used:
    http://forums.parallax.com/archive/index.php/t-86311.html

    Chip mentioned in the thread:
    Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

    It looks like the pulses would need to be much faster than 10ms to get the first 250 bits to the propeller before it hits the 150ms timeout.

    Some code from the boot loader. Note that the timeout is reset after getting a long, but not a bit. The first 250 bits are received as bits not longs, so there is no time extension.

    booter.spin: http://forums.parallax.com/showthread.php?101483-Propeller-ROM-source-code-HERE
    ' Receive long
    '
    rx_long                 mov     time,time_load          'reset time limit
    
                            mov     bits,#32                'ready for 32 bits
    :loop                   call    #rx_bit                 'input bit
                            rcr     rxdata,#1               'shift into long
                            djnz    bits,#:loop             'loop until done
    
    rx_long_ret             ret
    '
    '
    ' Receive bit (c)
    '
    rx_bit                  test    mask_rx,ina     wc      'wait while rx high
            if_c            djnz    time,#rx_bit
            if_c            jmp     #boot                   'if timeout, boot from eeprom
    
                            mov     delta,time              'time while rx low
    
    :loop                   test    mask_rx,ina     wc      'h?h    2 instructions/loop
            if_nc           djnz    time,#:loop             '1      400ns @20MHz...1us @8MHz
            if_nc           jmp     #boot                   'if timeout, boot from eeprom
    
                            sub     delta,time              'delta = rx low time in loops
                            cmp     delta,threshold wc      'resolve bit into c
    
    rx_bit_ret              ret
    
    
    


    Rocky
  • Clock LoopClock Loop Posts: 2,069
    edited 2013-08-12 10:50
    Is it possible to provide an included object as the address for the binary file?
    I would like to do this so when I compile my objects do also. (my object i include is the program I want to run in spin form)
  • TexanTexan Posts: 1
    edited 2014-10-29 13:46
    Yes, PropellerLoader.spin doesn't work at RCFAST. But, since I'm only doing PASM in my project, and I need this functionality with RCFAST (no crystal), I have used booter.spin to guide development of this loader.spin. (Search as I have, I haven't found this in PASM. But it seems to be in almost every other language!)

    I developed this by connecting a QuickStart board target (J1 VSS(39), VDD(38), RESn(37), P31(35) and P30(33)) to a breadboard 40PIN DIP host (VSS, VDD and pins 0, 1 and 2) (using jumper wires). I didn't modify either BOEn or RESn on the QuickStart so it doesn't comply with Chip's recommendation. However, by continuing to control RESn, it seems to work as expected.

    I haven't really decided how I'll fit this with other things, but I know I'm not using EEPROMs (so LoadRun is hardcoded) and the pins are in variables (I'll probably pass them in through par at some point.)

    As my first post to this forum, excuse any errors in convention.
Sign In or Register to comment.