+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 20 of 30

Thread: Propeller Loader

  1. #1

    Default Propeller Loader

    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
    Attached Files Attached Files
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  2. #2

    Default

    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?
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  3. #3

    Default

    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.
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  4. #4

    Default

    [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. )
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  5. #5

    Default

    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
    ·
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  6. #6

    Default

    could you use this to create self-developing programs?
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  7. #7

    Default

    You speak of AI (Artificial Intelegence), what a wonderful and terrifying idea.....
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  8. #8

    Default

    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!
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  9. #9

    Default

    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.
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  10. #10

    Default

    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
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  11. #11

    Default

    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
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  12. #12

    Default

    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
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  13. #13
    Cluso99's Avatar
    Location
    Sydney/Brisbane Australia or 'sailing on the high seas'
    Posts
    10,119

    Default

    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
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  14. #14

    Default

    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
    Last edited by ForumTools; 10-01-2010 at 03:28 AM. Reason: Forum Migration

  15. #15

    Default Re: Propeller Loader

    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/showthrea...-Perturbations.

  16. #16

    Default Re: Propeller Loader

    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.

  17. #17

    Default Re: Propeller Loader

    @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.

  18. #18

    Question Re: Propeller Loader

    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:
    Click image for larger version

Name:	Prop returning junk characters.jpg
Views:	92
Size:	43.6 KB
ID:	88052


    Image from PST:


    Master Loader.spin:
    (Calls loader sends bytes from slave to PC and PC to slave)
    -------------------------------------------------
    Code:
    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

    ------------------------------------------
    Code:
    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)
    Last edited by VG; 12-30-2011 at 02:13 AM. Reason: Added Code Tags

  19. #19

    Default Re: Propeller Loader

    Quote Originally Posted by VG View Post
    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 [code][/code] tags.

  20. #20

    Default Re: Propeller Loader

    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.

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts