Looking for an On Chip Source of Nondeterminism on the Propeller
Dennis Ferron
Posts: 480
Sometimes I have projects where I run out of cogs before I run out of pins. It would be nice if I could simply stack a second propeller chip on top of the first one. I mean, literally solder all 40 (or 44) of the pins together. Some of the pins would be left as inputs by the first Propeller and be driven by the second Propeller. I know about the dangers of 2 outputs being connected together and I know some here would wince at the thought of doing something like this but honestly I think it could work AND think how convenient it would be: you could take an existing Propeller protoboard circuit and, when you run out of cogs, simply stack another Propeller QFP package on top of the other one. No circuit design changes needed.
Both Propellers would receive the same program download, so you'd have to have some kind of protocol for determining which Propeller gets to be "#1" and which one takes "#2". Since they'll also be running from the same clock signal (hopefully no weird feedback effect comes of having the 2 props' PLLs connected to each other), they will essentially always want to do the same things at the same time. So if you have a protocol like "Whoever sets pin 1 high first is #1", that won't work because they will both check it at the same times and both set it at the same time.
So what I need is some way to make one Propeller come out with a different (random) answer then the other for the same calculation; it will have to depend on some hardware property that's unstable and independent of the crystal clock.
Both Propellers would receive the same program download, so you'd have to have some kind of protocol for determining which Propeller gets to be "#1" and which one takes "#2". Since they'll also be running from the same clock signal (hopefully no weird feedback effect comes of having the 2 props' PLLs connected to each other), they will essentially always want to do the same things at the same time. So if you have a protocol like "Whoever sets pin 1 high first is #1", that won't work because they will both check it at the same times and both set it at the same time.
So what I need is some way to make one Propeller come out with a different (random) answer then the other for the same calculation; it will have to depend on some hardware property that's unstable and independent of the crystal clock.
Comments
Then when it reads the pin·again if it is still a zero then set it to 1 and assume the number 1 position.
But you need a TRUE random generator since you don't want both to generate the same random delay.
Here is a true random number generator OBJECT that uses the PLL jitter to generate true random numbers
http://obex.parallax.com/objects/62/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Samuel
www.RobotBASIC.com
·
The dangers of connecting pins and then accidentally programming them both as outputs can be mitigated by using some resistors in series, but that makes the easy "up-down" soldering of pins a bit more tricky.
But won't you need to know which one is #1 and which one is #2 so as to make use of whatever unique resources they may each have?
How will you program them? Don't forget that during boot up and programming they are using the internal RC oscillators so I don't think you can just parallel the programming pins, the timing won't work out for both the same.
By the way that's an interesting question. If two Props are running off the same XTAL and RESET inputs it seems to me they still may not come up in "lock step" because during load from EEPROM they are running on highly variable internal RC oscillators. Surely you need some other way to synchronize them via a connected I/O pins. Assuming you actually need them to be synchronized.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
Dennis Ferron: "Sometimes I have projects where I run out of cogs before I run out of pins"
The corollary of that is that you will also find yourself running out of HUB RAM for program/data and will find yourself wishing you did not have the exact same binary loaded into each Prop. Doing so will result in each Prop wasting about half of its HUB space with code/data that only the other Prop uses.
All in all it's probably better to just link two Props via a high speed serial link or possibly an 8 bit bus. There have been many discussions of such systems on this forum. It's probably a bit hard to find those threads unless the participants pipe up now.
A fine example of this is Cluso's TriBlade board. Three Props on one board, one for user I/O with keyboard, mouse, video. Another for general I/O with many free pins and the third dedicated to "big" programs using 512K attached external RAM.
Of course you don't need a special board to do this. Just link up some Demo Boards or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
and randomly.
I think the whole design is fraught with problems....for instance you cannot solder ALL the pins together because
you are bound to get contention on I or O or even 0 and 1 unless you are EXTREMELY CAREFUL at what you do.
I think the best solution for running out of cogs is to use two props running independently and then just communicate
them serially.
Also I think you should revise your design if you are REALLY in need for all of this in the first place.
Maybe you can SHARE cogs or can do double tasking on cogs etc...... SUBSTANTIAL REDESIGN is what I advice.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Samuel
www.RobotBASIC.com
·
People seem to use up what they have regardless. For example before
the proliferation of GPSs people navigated quite nicely without them.
Now, it seems people just cannot go anywhere without having to consult
their GPS.....what gives???
This is the same situation. Before we had the propeller we wished for
something even close....and if it had 4 cogs we would have been VERY HAPPY.
But now that the propeller is here and we have 8 heavenly cogs....we use
them up and want more.....I question if a design REALLY needs more than
8 microprocessors.....maybe we are just·being tooooo slack with the design
process since we have 8.
I wonder what we would have done if we had to design the same project with
SEPARATE microprocessors....would we have been as slack and liberal with
using them as we seem to be doing with the propeller's cogs??????
It is I think this human condition that makes us want more and more INSATIABLY.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Samuel
www.RobotBASIC.com
·