Multi-Prop ID Process - Make More Simple
Humanoido
Posts: 5,770
There are 50 props connected. No eeproms.
The SAME program is loaded into each prop.
To give each prop a unique ID, six pins on each prop are connected to its dip switch.
The dip switch is set to a unique binary number from 1 to 50.
The program in each prop reads the dip number and knows its prop ID.
Can you make this more simple?
(I do not want to use dip switches, more resistors, or so many pins)
Ideally in a pure fantasy world, the output pin wire of one prop would connect to the input pin of the next prop, and so on. The first prop could have one of its pins wired to 0 or 1 to know it's the first prop with ID = 1. Then the program would determine the remaining prop IDs. Is this impossible or how to do it?
Thank you sincerely for your reply.
The SAME program is loaded into each prop.
To give each prop a unique ID, six pins on each prop are connected to its dip switch.
The dip switch is set to a unique binary number from 1 to 50.
The program in each prop reads the dip number and knows its prop ID.
Can you make this more simple?
(I do not want to use dip switches, more resistors, or so many pins)
Ideally in a pure fantasy world, the output pin wire of one prop would connect to the input pin of the next prop, and so on. The first prop could have one of its pins wired to 0 or 1 to know it's the first prop with ID = 1. Then the program would determine the remaining prop IDs. Is this impossible or how to do it?
Thank you sincerely for your reply.
Comments
Something dynamic would be cool but that will take much more effort. How are the props connected?
Token ring?
-Phil
A node does not allow connections to the next node until it's node number is established.
The unassigned node waits for a message containing the node number.
Is this like the idea we talked about here?
The master Prop (it knows it is the master since its input pin is held high and the data line is quiet) could broadcast incrementing ID numbers with each Prop in turn hold its output line high. The Prop that just had it's input change to high would know the ID is intended for them.
There are many variations on this type of ID designation.
I think this would be pretty simple hardware wise. Just a wire from one Prop to the next. With a pull up resistor on the first Prop. Although as I think a bit more you'd want either a pull up (or down) on the input/output lines or to use a resistor in-line with the wires. You don't want the input lines floating. (As I think some more, I thin you could get by without the resistors as long as you were sure about your code.)
What kind of communication bus do you want to use with this?
I'll help with the code if you want. I don't think it would be very hard.
The IDs could be saved in EEPROM so you could use the input and output pins for other things once the IDs are assigned. (Oh, I don't think you are using an EEPROM with each Prop.) Then the ID assignment could be run with each start up.
Duane
Edit: I hadn't seen jazzed's post. I think there are similarities with what I'm suggesting.
Seeing the threshold input around 1.2 V the resistors need a different step. But in principle it seems to work.
This is a spice simulation in LTSpice. Each propeller is loaded and checks the same in put pin. The master now stimulates the pin as an output. Pin is simulated e.g. by S3. Voltage source V4 /V5 simulates a pulse train which tells the next propeller the ID. After the second propeller is identified, he stimulates his follower with the next number until the end of the chain is reached.
The graph shows from the lest: magenta is output of S3 pulled to ground. Blue, is toggled between 1.2 and 2V to identify S2. From 25 ms S2 is active and toggles S1 input (red) . From 50 ms S1 is active and toggles cyan S4. S4 is than active, but there is no further Prop and so the chain ends. The chain can have any expansion and could be coupled back to S3 (isolated by a diode) to see completion of init.
The resistors must be adjusted to have the threshold in the middle of the voltage swing. Attention: the last stage must be impedance matched. remove .bin to get the spice .asc
In this simple model the outputs are only used as single pole (active low, tri state high). The signaling pin can do totem pole output and stay in high or low after initializing the next one.
How are your 50 Props connected?
1) in a chain, the previous loads the own code to the next?
2) parallel all P31 receive the same program and only one P30 sends the ACKs?
In case 1) you have already a chain and it is very simple to manipulate the code a bit before sending to the next (increment a byte in memory and decrement the checksum at addr $0005). Then read this byte as ID.
In case 2) you can make a chain with 2 pins (one to the previous, one to the next) and send either a serial binary number which is incremented before sending to the next, or just a puls with an increasing pulswidth for every Prop.
Andy
Only tested 4 together so far, but I think it's going to work...
These 8 Prop pins are normally used as outputs to control switches, so I'm not wasting any pins this way...
Are the Propellers going to have crystals?
How is the master Propeller going to communicate with you to let you know if the process was successful or not?
Not using crystals will make the problem a little more difficult. At least to me. I haven't tried to use any of the serial objects without a crystal.
I suppose it should be possible for the Propeller to adapt to a baud rate set by a PC I mean Mac. If you repeatedly entered "U" (I think its ASCII code alternates between binary 0 and 1) you could have the Propeller adapt to match the baud of the Mac.
Without info on how your 50 props are connected, it is a little hard to say. But the easiest way is to propagate and address down the line via the connections you already have. So it depends on your connections as to how you will need to do this.
BTW, it is also possible to read 3 states from a pin... O/C, pulled up, pulled down. Also you can use a multiplexed grid (like reading a keyboard). Or you can use a time constant. You should be able to get quite a lot of combinations (delays) from 2 pins in sigma-delta mode.
Enumeration of independent units is a special on. There are techniques like CSMA/CD (Carrier Sense Multiple Access and Collision Detection), well known from ethernet.
What I showed above is a way to daisy chain propellers using on pin and 2 resistors per chip. I do not know, if parallel boot loading from one flash works, in this case the ack pin can make the daisy chain. This solution is sequential, deterministic and enumerates the chips in a fixed order, so the ID's are linked to specific chips. In how far the chain can be used for further syncs, I did not think about.
Andy, point 2, case 2.
Can you please give a more detailed example of how to make this type of chain and connect pins?
All Propellers can boot at once and have ID's serially assigned later. The one problem with a BLSR ring topology is that a boot/config failure of one unit can disable other good units. Some redundancy is built into a bidirectional ring, but not enough. One solution to the boot/config failure of one unit may be in allowing multiple configuration node paths on a timeout.
So, all the props power up and boot at once. Each of them picks a random number, then broadcasts it. Put a "wait" signal on the bus between them, that gets set when a prop broadcasts, if it's set, wait some random time, then try again, otherwise listen.
Each prop gets the numbers, and sorts them, putting it's own into order, thus providing the ID. If a matching number is found, both props pick again to resolve. Give a time out for new reports, and then proceed to higher level operations.
Didn't Clock_Loop do something like this? It's a fine idea if all devices share the same "bus" like in Ethernet in a small star topology. Of course routers could be used for inter-networking.
The idea of the code is: Every Propeller (exept the first) waits until he gets pulses from the previous. The number of pulses is the ID. Then he sends the number of pulses + 1 to the next Prop. This should work also without a crystal.
This code is absolutely untested (I don't have 50 Props connected together) !
VAR long id PUB main dira[1] := 1 'set all P1 to Low waitcnt(clkfreq/200 + cnt) if ina[0] == 1 'first Prop? id := 1 'first ID waitcnt(clkfreq/200 + cnt) else 'other Props: ctra := %01010<<26 + 0 'set counter A for pulse counting at P0 phsa := 0 frqa := 1 repeat until phsa > 0 'wait for first puls waitcnt(clkfreq/100 + cnt) 'wait while pulses are counted (10ms) id := phsa 'number in phsa ctra := 0 repeat id+1 'send ID+1 pulses via P1 to the next Prop outa[1] := 1 outa[1] := 0 ' now all Propellers should have enumerated itself in 50 * 10ms = 500ms dira[LEDpin] := 1 'a possible Test: repeat id 'blink a LED on each Prop id times outa[LEDpin] := 1 waitcnt(clkfreq/4 + cnt) outa[LEDpin] := 0 waitcnt(clkfreq/4 + cnt)Andy
Each one-wire "silicon serial number" provides a unique 48-bit ID via a single microcontroller pin.
-Phil
-Phil
That's pretty sweet
It has been a while since I messed with one-wire devices. Nice find.
Nothing new under the sun. I'm sure someone else thought of it before him.
Not concerned about originality as much as to why his approach is not being used.
That's very interesting. But I'm a bit baffled by how you actually implement it with the Prop. How does that chip get identified/associated with its mated Prop chip?
Here's a similar device that you can program with a number, or any other info, yourself:
-Phil
Thus they may not have eeproms until they are booted. Therefore, as I said, update a known location in hub or during programing the next in line prop. It is that simple.
IIRC Brad's bst (and mpark's homespun) both can reserve a block directly after the spin startup sequence at $10. Use this as the location to increment.
I guess I was/am baffled more by how the Prop is wired to this ID chip. I guess upon waking, Prop XYZ and only Prop XYZ can talk to its associated XYZ ID chip and thereby learn its identity, and then when the Master Prop queries Prop XYZ, Prop XYZ can report its ID with confidence? Is that the general idea? Or am I having an identity crisis?
thanks for posting these suggestions!
I understand it so that all 50 Props are in parallel and not in a sequence.
A sequence would be simpler, but just "update a known location in hub or during programing" will not work, because the checksum byte will be wrong then, so you need also to update that checksum.
Andy
If the EEPROM version of the ID chip were used, the ID could just be a sequential number from 1 to 50, so the master wouldn't need to keep an ID list.
-Phil
Okay. That makes sense. Thanks for the explanation. :-)