Daisy-Chaining Parallax Microcontrollers???

Jorge P

Hi all, I am curious as to weather or not anyone has tried daisy-chaining any of the parallax microcontrollers?· I know paralax has already done it since that is how the cogs in the propeller chip are connected (I am assuming) but can multiple propellers be daisy chained or any of the other microcontrollers?

A schematic would be nice.

Here is·the link that made me curiouse http://www.best-microcontroller-projects.com/spi-interface.html

·

SRLM

Look on page 426 of the "Basic Stamp Syntax and Reference Manual" under the SEROUT command. It has all the needed information to connect several BS2s together.

LoopyByteloose

Weather is not whether.

The Propeller protoboards can be set up to stack verically with a common bus for mere pennies.

So instead of having one Propeller provide 8 parallel processors, you can have 8 [noparse][[/noparse]or many more] Propeller's stacked ina 8X8 grid of parallel processing.

I guess that is why they decided to call the IDE, 'Spin'.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's sunny and warm here. It is always sunny and warm here.... (unless a typhoon blows through).

Tropically, G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan

Javalin

Common bus's between microcontrollers would be something like CAN-bus, RS422, RS485, i2c etc. If you had ten propellers on the bus each with a cog running the communications protocol then you'd still have 70 cogs to play with....

Look in the Nuts&Volts series on the www.parallax.com website under "resources"

James

SRLM

70 cogs, 270 pins to do whatever you want... I don't think I'd have the coordination to make it all work!

Jorge P

Thanks for the input!

I would like to know if this can be done in hardware only, in the same manner that High end servers do?· When I was a kid (about 9yrs old) I had a Tandy Color Computer 3 with an OS9 LII OS.· In the OS9 manual it stated how NASA daisy chained 256 MC6809E's to controll the refueling arm for the shuttle launch pad.· This was all done in hardware!· I have seen one example of how it could be done by piggy backing the physical IC's of the MCU's directly ontop of eachother, back in the late 80's.

Is piggy-backing the same as daisy-chaining??

Has anyone piggy-backed any stamps??

Post Edited (Jorge P) : 8/16/2008 1:54:17 AM GMT

Mike Green

Piggy-backing usually refers to mechanically mounting one thing on top of another similar thing. This could be done with chips mounted on top of each other and connected together that way or printed circuit boards mounted that way. When it's designed into a system, there are connectors on the boards in the right positions so one board just plugs into another (also called stacking) and they're mounted with spacers or stand-offs to each other.

Daisy-chaining comes from the way you can make a necklace from a bunch of daisies twisting one into the next the same way so they make a chain. Usually one device's output is connected to the next device's input and that 2nd device's output is connected to a 3rd device's input and so on. Sometimes the last device's output is connected to the first device's input so you have a circle.

It's often easier to just form a network using one pair of wires strung between the devices (whether a Stamp or Propeller or a development board) as shown in the Stamp Manual under the SEROUT statement using half duplex open-collector/open-drain mode and a pullup resistor to +5V.

By the way, high end servers don't "do it all in hardware". There's a lot of hardware and a lot of software behind the connections between them.

You can't really "piggyback" Stamps. There are too many pins that really have to connected independently. Pretty much the only pins that would be connected from one Stamp to the other would be Vin or Vdd and Vss. The programming pins would have to be separate and most of the I/O pins would have to be separate. Even if you connected one or two I/O pins on each Stamp to the other, you really would want a 220 Ohm resistor between the Stamps to protect the I/O pins from a programming error that could cause a short circuit between them.

Post Edited (Mike Green) : 8/16/2008 5:16:10 AM GMT

waltc

Any micro can be daisy chained and Prop is no different. But some are better for it than others.

The question becomes with the Prop as with the Transputer or SeaForth processor farm, do you have a problem that say requires lots of parallelization and the question; what sort of processor configuration you want to employ and the messaging system to handle communication between them? maybe a 25 cog hypercube or just a simple 4x4 array.

Then there are the memory constraints to factor in.

Then the language in question: Interpreter or compiled.

Then there is the debugging of such a program.

Hardware is easy in this case. Software no.

As for using 256 6809's to run the refueling arm, sounds like bizarre fabrication on the part of Tandy. One cpu with a lot of sensors and with human monitoring. IMS they were'nt big on using COTS with mission critical stuff back then.

The AP101 by IBM was a case in point.

LoopyByteloose

Forgive me, I wasn't trying to equate parallell processing of stacked Propellers with daisy-chained devices. If you use Wikipedia for both terms, you will find clear and useful differences in meaning.

If you really want to network microprocessors, CANbus is quite useful. Also, CANbus is in a different league than basic RS-232 and RS-485 as it provides both buffering and error checking that RS-232 and RS-485 do not. So, there is a lot of loose talk in the above postings.

I have a CANbus interface board that can easily network dozens of CANbus nodes on one 4 wire telephone cord over 1000s of meters. It can mix microprocessor as the interface is SPI and 8 byte messages are held in buffers at each node. There are special pins to tell the microprocessor that a message is waiting.

So you can have a Propeller on one node, 28 on another, an AVR on another, a BasicStamp on another, an SX on yet another, and so on. It really could use every bit of hardware you own. Even you PC can be interfaced to one node via a BasicStamp.

And CANbus uses RS-485 drivers to handle the traffic. Without CANbus to handle communications you get collisions without any resolution of the damaged data. Messages get lost unless you have a very strict architecture of your network.

RS-232 and RS-485 alone is good for point-to-point or one broadcast master to many recievers, but CANbus is a party line that can have several masters and many slaves all working together.

SRLM,
You are way off in your count. The stacked Propellers i/o pin count is dependent on how many pins are used for a commonly shared bus between the Propellers.

With a 1 byte bus and 4 pins already occupied, you would have only 20 i/o pins per Propeller - so 8 devices would have 160 i/o pins

If you have a 16 bit / 2 byte bus and the other four pins, then there are merely 12 i/o pins left available, so 8 devices would have 96 i/o pins available.

In truth, how many i/o pins do you need? What is your purpose?

I would be more interested in what the computing power could do for real time video or audio. Most of the i/o would not be used in such cases, but you get more color and better animation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's sunny and warm here. It is always sunny and warm here.... (unless a typhoon blows through).

Tropically, G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan

Post Edited (Kramer) : 8/16/2008 6:29:21 PM GMT

crgwbr

Really, RS-232 and RS-485 are hardware specs, CANbus is a protocol. You can run any protocol you want over a hardware spec like RS-485, but Kramer is right, you do need something. Without something like CANbus, you'd get errors and data collisions like crazy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen

I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.

"Failure is not an option -- it comes bundled with Windows."

Use The Best...
Linux for Servers
Mac for Graphics
Android for Mobility
Windows for Blue Screens