fastes way to load identical code on to 16 props

mctrivia

I have 16 props with identical clock source. What is the fastest way to load the contents of an eeprom on to them?

Is it possible to tie sda all together and have 1 props scl connected to the eeprom? will resetting all at the same time result in all loading the data off the eeprom?

If that is not possible is it possible to have a small cheap micro controller trigger the reset and ignoring the TX from each prop send the data to all at the same time?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.

Phil Pilgrim (PhiPi)

The identical clock source will not help you, since the code is loaded from EEPROM while using the internal RC clocks. As a result, it will not be possible to tie SDA or SCL of the EEPROM to multiple Props. The best you can do is have one master Prop that reads the EEPROM and distributes the code to the others via a common bus. But for this to work, the slave Props will have to have their own EEPROMs with bootloader firmware.

As to your last question, have you looked at the native bootloader protocol to see if this is a reasonable approach?

-Phil

mctrivia

no space or money for eeprom for each. after i posted i thought that maybe having the first prop act as the cheap micro i mentioned would be a good way to go. saves buying 1 more part.

i do not have the props wired up at the moment to check. will have to look through the code to see if it expects a prop to respond.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.

BradC

mctrivia said...
no space or money for eeprom for each. after i posted i thought that maybe having the first prop act as the cheap micro i mentioned would be a good way to go. saves buying 1 more part.

i do not have the props wired up at the moment to check. will have to look through the code to see if it expects a prop to respond.

You can load a propeller without listening to it respond, but there is zero guarantee that it will actually load. Having said that, how many "Propeller Lost" responses do you see from the Propeller Tool? I think I've seen one or two a year really. It's a pretty robust protocol.

Reset Prop.
Clock out $F9 for sync
Clock out LFSR
Clock out $F9 bytes for LFSR response & chip version
Clock out command
Clock out size
Clock out program
Clock out $F9 bytes for load ok response

Done.

In theory, you should have no issues loading 16 in parallel, but without listening to the response you just won't know if it actually worked or not.
Given I can load a propeller over 10,000 times consecutively with no errors your chances are probably pretty good.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.

mctrivia

i can verify boot through serial coms so if once in 1000 boots i have to boot twice to get all booted up. is still faster to boot 16 in parallel twice and verify then to boot 16 in chain.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.

Michael O'Brien

mctrivia,
I like all your threads dealing with multiple propeller issues - they are all very interesting - I look forward to the discussions.

Loading multiple propellers from a single eeprom has been investigated in a previous thread below - however this is only of use if you don't wish to change the software on the grid propellers often and possibly use them as a PE or ALU grid from a host propeller with its' own separate eeprom.

I personally use the procedure perfected by Christian Godzinsky and Pems that loads each propeller in 1.1 second serial sequence.
In order for this to work, you must connect all scl and sda together on all props with a single 4.7k resistor from sda to 3.3v. Each propeller must include an instruction in the initial spin object that outputs a reset signal to the next prop (this will run after the current prop has been loaded and has released scl and sda). The sequence will·keep all other props off the eeprom except for the one that was just reset in sequence. For program loading verification you can assign a listener pin back to the host propeller from each grid prop or just route the last reset output of the last prop loaded back to the host. This procedure has been verified for applications that do not need clock synchronization (all props may not be on the same cycle).


2008 Oct: Multiple Propellers & one EEPROM
http://forums.parallax.com/showthread.php?p=758971
http://forums.parallax.com/attachment.php?attachmentid=56309

See also,
2007 May: PROPELLER SUPERCOMPUTING
http://forums.parallax.com/showthread.php?p=582511

If you wish to program in·parallel then the propeller loader is likely the way to go instead.
http://forums.parallax.com/showthread.php?p=591445
http://obex.parallax.com/objects/61/

thank you
/michael

Post Edited (Michael O'Brien) : 1/11/2010 2:05:27 AM GMT

mctrivia

sequential programing would be easiest from a software stand point but it has several majer draw backs that I can not handle.

1) If a prop has died in chain no other props after it can boot.
2) long boot time.

I could probably deal with the 2second boot time but what do I do if prop 5 of 16 dies? I can write code to handle failed nodes but only if most of the nodes do boot.

I plan to have an initial boot loader booted on to all 16. serial coms and other os related code is loaded into cogs then the entire 32k of each is reloaded from a Flash memory chip. in this way my OS takes up none of the props RAM only a few cogs. Flash is much cheaper then EEPROM so each node will have its own code for a fraction of the price.

If I wire it right the nearest neighbor of any failed prop could reset it to attempt a second boot before marking it as a bad device and routing around it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.