Propeller Loader

[cgracey]

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

[Cliff L. Biffle]

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?

[cgracey]

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. Biffle]

[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. )

[Kaos Kidd]

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
·

[Muncher]

could you use this to create self-developing programs?

[RinksCustoms]

You speak of AI (Artificial Intelegence), what a wonderful and terrifying idea.....

[IAI-Captain]

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. Biffle]

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'Brien]

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 Baker]

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

[Rumple]

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

[Cluso99]

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'Brien]

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 Loop]

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.

[Mike Green]

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.

[idbruce]

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

[VG]

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:



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)

[kuroneko]

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.

[VG]

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.