Multiple Propellers & one EEPROM

godzich

Hi,

I might have an application where I need 8...16 propellers, all running the SAME program! All these MPU's are located within 15..20 cm on the same PC-board.

Therefore I wonder:

1. Would it be possible to use the same serial EEPROM for all the chips for bootloading?
2. If not - is there any other simple gimmick to ease the design (I would like to only have one serial port and only one eeprom, not a bunch of them)?
3. Im considering also using only one clock. I need complete sync between the propellers after the start (no drift). Distributing 5MHz about 20 cm is not probably too bad. Can one "master" propeller (with a xtal as the oscillator) feed the other 7 (maybe a buffer in between - or has the clk out enough power to drive clk_in on 7 other propellers)?

8 propellers booting the same code from the same EEPROM would be SO neat !!! Anyone that have been over this problem before???

I played with the idea that I delay the reset to the propellers, one by one, so that there is enougt time for the former one to load the contents from the eeprom, before the next propeller awakens. Would this work, and how long is the worst case delay I have to use between letting propellers out of the reset? Is the capacitive loading too much for 8 propellers to be parallelled this way to one eeprom? I did not find any data on what is the read bit rate during boot...

Christian

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!

Mike Green

1) One Propeller can bootload another. There's a Spin bootloader that Chip wrote that can do this. It would require 3 I/O pins for each Propeller (reset plus serial I/O). You can't really connect them in parallel because the bootload is interactive and the speeds will vary since the Propeller uses its internal clock during the bootload process.

3) You can't use the clock pins for a source of a clock signal. They're not intended for any kind of external load. You would have to use an external clock circuit and that could have enough drive capability to drive 8 Propeller chips.

It would be possible to have 8 Propellers share an EEPROM as long as only one is accessing the EEPROM at a time. If the Propellers are connected so that they're held in reset until the previous one lets them out of reset, this could work. See the Propeller datasheet for boot times. It would be about 2.5 seconds for each.

Leon

You could load one Propeller from the EEPROM, then load the others from it, via I2C. I'm not sure about syncing them, though

There are much better devices than the Propeller for that sort of application, BTW.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 10/20/2008 2:48:27 PM GMT

BradC

Mike Green said...
1) One Propeller can bootload another. There's a Spin bootloader that Chip wrote that can do this. It would require 3 I/O pins for each Propeller (reset plus serial I/O). You can't really connect them in parallel because the bootload is interactive and the speeds will vary since the Propeller uses its internal clock during the bootload process.

You could very easily use a single reset and transmit line, having an individual receive line back from each propeller. There is no specific delays or interactivity in the transmit side of a loader.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Ken Peterson

You can connect them in parallel to the EEPROM, and then cascade them together so each one controls the reset pin on the next one.· It would take an extra pin on each Propeller to bring the next out of reset.· The reset lines·would have pull-down resistors.· On the last Prop, the line nomally used to un-reset the next one could be tied back to an input on all of the Propellers to signal that all are booted - this could be used with waitcnt to sync all Props together.· It is virtually, if not really, impossible to sync the hubs on all of the Props however.

It may be possible to get the hubs "synced" with a small margin of error.· Have ALL cogs listen for the sync signal, and then set a lock.· The one closest to the HUB window will win the race and obtain the lock.· Use this cog as "COG 0" and the rest in order accordingly.· I have not tested this, it's just an idea.

Updating the·software would be simple with this scheme because only the first·Prop would be involved in communication with the PC.· The rest would be held in reset by the pull-down resistor.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

- Bjarne Stroustrup

Post Edited (Ken Peterson) : 10/20/2008 7:27:21 PM GMT

pems

for what it's worth, about a week ago i assembled a simple circuit with dip40 prop, crystal, power, etc. For a quick functionality test, i decided to use flying leds to connect 3.3v power and p28, 29 to the respective pins on a propeller proto board (to piggy-back on its eeprom). I had leds attached to both props (on my prototype and the prop proto board) to monitor activity.
As soon as i switched power on the prop proto board, none of the leds would come on - i guess this is because one prop was clobbering the other one's signal on the eeprom's i2c lines so none would load the code properly. But if i shorted the reset pin to ground on my circuit prop, it would load right up and the led would light up.

so if you can sacrifice 1 io pin per prop, the simpliest would be to daisy-chain all your props, such way that as soon as one of them loads up, it'll pull down and up (to reset) the reset pin on the prop next to it, to propagate the "reset chain reaction" and let the next prop load up over the i2c line (i.e token passing). While having all props connected to the i2c bus (but i don't know if doing this kind of thing is within-spec).

don't make a complete circle though

hope this helps

godzich

Hi,

That is EXACTLY what I did yesterday, without knowing about your post. I prepared a short application brief to explain in more detail the pros and cons of such a system, please find it attached here. It works wonderfully [noparse]:)[/noparse]

Christian

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!

Ken Peterson

Also worth noting: Even though all propellers in the chain run the same program image, they don't all have to do the same thing. You can use extra pins tied to different logic levels to allow the propellers to differentiate their roles.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

- Bjarne Stroustrup

godzich

Hi Ken,

That is exactly my intention. At least so that these "hardware coded" pins tells the propeller its position in the chain, not to necessarily selectively run alternative software (also possible), but to handle different data in some data streams throwed at them [noparse]:)[/noparse]

These propellers are actually connected via other pins as well, to form a chain or matrix of propellers, so that they can pass data within the array.

Additionally, you could use the already reserved ·EEPROM scl and sda lines for interchip communication (since all propellers are connected to them), based on the ID by the hardwired pins! As long as you do· not use sequences that trigger the EEPROM into life. Most ideally you could use the same·protocol as the EEPROM is using (but a different address), communicating with other propellers from one master·[noparse]:)[/noparse]

This above mentioned effort is unecessary if you have other pins to spare, but could be convenient in a tight pin budget design, such as mine.

Christian




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!

hippy

An extension to godzich's daisy-chained reset is to use a small micro which can monitor SDA and SCL and be daisy-chained from the previous micro so each is reset in turn. There's not a lot of advantage to that unless you do not want to dedicate a Propeller Chip I/O line to reset daisy-chaining.

One addition which may be useful is a wired-OR link or similar to the 'master Propeller' so it knows when they have all booted and can even determine how many have been booted.

The problem of sequential booting is that the boot time can become considerable. An alternative approach would be for the master to control resets and program each Propeller Chip's Eeprom in turn whenever a new program has been downloaded. That way boot time will be minimised but the master to slave interconnection will be more complicated. It would probably be best to have a separate bootload controller dedicated to the task rather than part of the running slave network.

Using a specially written PC Bootloader App it would be possible to implement this without having to have the bootload copying code downloaded into each slave.

For simplicity, godzich's daisy-chaiinng is the easiest approach.

godzich

Hi,

I was shocked to learn that the boot time for 10 propellers can be half a minute, using this daisy chain configuration!

This might be prohibitive in some applications. But that scheme IS simple, have to admit. And we all know that "Simple IS beautiful..." I use that mantra often, especially when meeting new people. I often continue that phrase with the words"..., just look at me".

Christian

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!

heater

Back in June 2006 in this thread http://forums.parallax.com/showthread.php?p=591663 Chip said

Chip said...
The PropellerLoader will get augmented a bit so that it could load the same program into a whole array of chips, instead of just one. Each Propeller would receive his own ID into BYTE 5 which is normally reserved for checksum during normal downloading. We'll hybridize the download process a bit by first loading an intercessor program which will then suck up and launch the final code with the ID insertion. We can bus them together however we want, so that some lines are common throughout, and others connect rows and columns.

I don't know if this ever happened.

It does suggest to me that you could give each Prop in an array it's own EEPROM, they are not so expensive and they can also hold the Prop identification info. Load the EEPROMs with a little boot loader program which would then load up code that is "broadcast" over a single serial bus from a home made loader program on your PC.

You could probably end up programming the entire array in parallel faster than the current Prop tool does a single Prop.

With a bit of work on the loader protocol one could also support different programs for each Prop loaded sequentially.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 10/21/2008 6:40:23 PM GMT

Michael O'Brien

Hi, Christian, Ken and Pems.
· Your design pattern for daisy chaining multiple propeller chips off of a single EEPROM is excellent.
· This procedure works very well.· I am currently linking 5 propeller chips into a 40 processor toroidal vector topology·and I am able to load the same spin code on all 40 processors.· This is an experimental work in progress where most of the work involves the software around the PC client and host propeller. I expect that it should scale to 64 processors using a single power supply.
· I get a load time of 7.5 seconds for 5 propeller chips ( 1.5 seconds / propeller) after a reset from the 6th host propeller.· However, depending on the load of support chips the 5th processor sometimes takes an extra 5 seconds to load - It is the furthest from the EEPROM and probably signal degraded due to my breadboard capacitance.· I will update the site in a month or two when I get all the software and design worked out.

· Here are a couple photos of a test circuit with load/save circuitry partially wired for a·40 propeller processor array·running in·SIMD mode.

· So I am grateful for this piece of work·on propeller cluster design from you guys.

· /michael

Andrew E Mileski

godzich said...
Hi,

I was shocked to learn that the boot time for 10 propellers can be half a minute, using this daisy chain configuration!

This might be prohibitive in some applications. But that scheme IS simple, have to admit. And we all know that "Simple IS beautiful..." I use that mantra often, especially when meeting new people. I often continue that phrase with the words"..., just look at me".

Christian

You should be able to reduce boot time by forcing an I2C boot. I believe tying the serial RX pin to a pull-down resistor will do it.

heater

Err...Wow!

What are you going to do with that?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

lonesock

Andrew E Mileski said...
You should be able to reduce boot time by forcing an I2C boot. I believe tying the serial RX pin to a pull-down resistor will do it.

According to the datasheet this should save you ~0.3 seconds per boot (~1.3s if P31 is held low, and ~1.6s if it floats).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

mctrivia

I beleive you could tie the prop plug pins to all the chips, use an eeprom for each chip, and use my id object to give each a uniqe id number. if you want a smaller number each chip could comunicate with each other figure out who had lowest and then number themselves.

If you want to load from a single eeprom and save pins by reusing 30, and 31 for i2c comunication. have 1 prop deactivate the eeproms enable pin then you don't need to worry about triggering the eeprom.

Peter Jakacki

Hmmm, daisy chained props sharing a the same EEPROM? I seem to remember we were talking about this "years" ago
http://forums.parallax.com/showthread.php?p=661998

Of course my idea of enumeration was to have each prop increment a location in the eeprom before passing on control to the next prop. The last prop had to know it was the last prop and set this location back to zero for the next time. The easy way in this case is to put a pullup on it's reset control port so that before it would try to make it an output it would see a high rather than a low (from the next prop's pulldown).

*Peter*

mctrivia

that would work but eeprom can not take infinit writes. They should be altered as seldome as possible.

Peter Jakacki

Someone always says that. Now to quantify it since we are not talking about infinite writes and BTW real-world uses do alter contents as necessary rather than as seldom as possible. Do you know that EEPROMs are guaranteed for at least 1,000,000 cycles? Even with eight props that means 125,000 resets. Even if the unit were reset 8 times a day (high abnormal and improbably and I would think impractical) that means over 15,000 days. I think I can live with that.

*Peter*

mctrivia

you got a good point.

Cluso99

If you have enough pins spare on the first prop, you could use the first prop to load the other props in parallel, Just tie all resets of the other props together and to an output of the first prop. This can be used to reset all other props after the first prop loads. All the other props use the pair of serial io pins (P30 & P31) connected seperately to the first prop. This way the first prop can load them in parallel (using seperate cogs if you like). I think code exists to download code to an other prop using this method. Once running these pins can be reused for comms to the respective props.

If you do not have enough pins, then tie all the other props serial pins together to a pair of io pins on the first prop. Use a latch (74hc573). Each output will be connected to each ot the other props reset pins. The inputs will be connected to the first props pins (which may be subsequently used by the first prop, so in parallel with). The LE pin will be connected to a dedicated pin on the first prop.

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

· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz

obrienm

See parallel loading design pattern for multiple propellers by Clock Loop for reference that superceeds this approach.

http://forums.parallax.com/showthread.php?p=956909#post956909

/Michael O'Brien