Networking microprosessors
noobydoob
Posts: 14
What is the preferred method for networking microprocessors? I'm building a robot with Stamps, Ardunio's, and Raspberry Pi processors, and need to network them. The Raspberry will server as a master. Should I go for async serial, or should I consider SPI, i2c or even other methods? One problem I'm facing is that the Raspberry only has one UART. Can I share the line between all the slaves? How?
Comments
If you mean connection to the internet, the Raspberry Pi is likely the least expensive internet portal. And it is small enough to be included in a robot. You might even find the means to have a wifi dongle make the internet connection wireless.
The Raspberry Pi can set up a serial port to link with a BS2, but you would have a lot more power and resources if a Propeller was your microprocessor. If you used Forth on the Propeller (PropForth, Tacyhon, or pfth); the serial interface could be an easy means of real time control and immediate reconfiguration. (Not sure of the status of Forth on an Arduino, but it might be done.)
Other software for microcontrollers is compile and load, not interactive. I actually prefer having an interpreted language as I can re-program and immediately observe the success or failure of what I have done.
+++++++++++
Network in the generic sense can mean a lot of alternatives.
CANbus is a very useful one for a microcontroller network that is independent of routers and internet portals and such. It just requires a twisted pair of wires that can easily go distances up to 1000 feet without noise problems. But CANbus is a big topic in its own right.
It uses RS422 async serial.
+++++++++++
A wireless small scale network might use asynch serial and XBee technology.
A wired small scale network (ideal for stations, not roaming robots) could use RS422 for asynch serial full duplex on its own, and avoid the complexity of CANbus packets.
This scheme should work pretty well for the Arduino because their UART can receive bytes while they're doing something else. The Stamp can either listen or do work due to its single threaded nature, so keep that in mind. The speed is probably something that you would need to use some trial and error to find, although 9600 is a good guess.
Martin_H: You imply that start byte and device ID are software implemented, right? This is not part of RS232?
I need to do logic level conversion from 5 to 3.3 volts also, but that's pretty easy with a chip.
Do I need to worry about using resistors and such when using RS232, or just connect the Rx/Tx lines directly?
What about flow control? I know BS2 supports hardware flow control, but I doubt Arduino and Raspberry does.
I am thinking of having a separate control pin pulled high/low for each slave to tell it to transmit data to the master.
The BS2 has a TX and RX pin that have an RS232 interface, but many other devices merely provide the TTL signals to be adapted by the user. I believe that is the situation with the Raspberry Pi. I don't know what the Arduino provides.. but I suspect the signals are TTL.
So you have to be aware of both contexts. The RS232 signals are inverted from what the TTL signals are. You cannot mix by wiring directly the TTL level signals with RS232 level signals as you will damage microprocessor i/o ports by the higher voltages. Even if there is no damage, the processors won't commlunicate as levels will be the opposite of what is expected.
++++++
You can also have TTL asynch serial on other BS2 io pins. There is a big advantage to this as you can use RS485 transceivers which have better noisy immunity and can run one twisted wire pair for everything over much longer distances.
Or you can go with all RS232 driver chips, such as the MAX3232 (3.3 volt powered) and the MAX232 (5 volt powered).
++++++++++
You will have to create an identity for each processor and have a good idea of which is the Master and all others are slaves. The slaves will listen and wait for an identifying call to take action or to give a reply, otherwise they will remain silent to avoid collisions from having more than one device trying to transmit at the same time.
It is not hard to do.
Flow control and parity are not necessary and should be avoided unless you have an obvious need for them. Since the slaves are just listening for an indentifying call, that is all the flow control you need.
I'm thinking about going TTL async, and using a separate pin on each slave that is pulled high to tell it to transmit to the master.Then I can share the lines between all the slaves.
If you wanted to use RS485, you need one at each end.
Here is one device that is available (these come in 3.3v and 5.00v chips depending on your power source.
The sn75179 chip requires two twisted pairs, but there are other transceiver chips in 8 pin dip that require only one twisted pair in a Master/Slave setup... a kind of two-wire party line.
http://www.omega.com/techref/das/rs-232-422-485.html
My guess is that logic level is all you need but I would also use a series resistor from the I/O line just for a little current limiting in case of a bus conflict and also so that 3.3V logic can handle 5V signals. On the software side you can keep it very simple by using async and transmitting "select codes" which is just another way of addressing slaves. That way you can transmit data normally to the slaves but you just select beforehand which ones should listen up. All slaves should always interpret these select codes which include deselect and broadcast codes etc. It really is quite simple as long as you keep it simple. This assumes that you are not trying to transmit 8-bit binary data but even if you were there are simple mechanisms such as character gaps etc to help validate select codes.
What is the purpose of deselect? After a slave is selected, it will transmit it's data, then start listening again (going into deselected mode automagically).
I had overlooked this as a 'flow control issue'. You can just code an i/o pin to default to recieve except when you desire to send. You do this select first whenever you want to send a message and release it when finished.
With RS422, you have NO select and two twisted pairs... full duplex.
" A proper TTL/CMOS Level shiffer' is either RS422 or RS485. RS232 is an archaic junk level shift that costs more in chip form, requires more to wire up, and doesn't work anywhere near as well. But the perception is that it is what one is supposed to use.
Proper TTL/CMOS level shifter???? IMO most of these "propers" and "just to be safe" measures are a load of nonsense. If you know what you are doing then very rarely would you ever need these shifters. Being paranoid is no excuse, the more parts you have, the more things that can wrong, so don't put parts in that don't need to be there, simple.
The Stamp has TTL level inputs which means it accepts anything that is 2V or more as a high so therefore a 3.3V from the Prop will do just fine whereas a 5V from a Stamp will go through the current limit resistor no problem, whereas the RPi's I/O is 3.3V too.
The deselect is if you are in multiple select mode where you can broadcast to a group all at once but just remember these codes are just a bit of a guide, your implementation depends upon your needs.
Sometimes if you need to make sure a message got through you can also use the simple "repeat n times always" format that does not need acks and naks but simply sends a code to indicate the start of a message, and a sequential message number, an optional data count and then the message and checksum/CRC. Any receiver that finds an error simply rejects the message and hopefully gets a good message after which it rejects any more messages if they have the same message number. This method works well for broadcasts to multiple slaves, it's one I used in high-rise lift displays many many years ago using RS485 over miles of non-twisted pair fire proof cable (ran it at 19.2k baud).
But try to keep it simple and funtional, at least first off, then you can see if you need to do more.
BTW, if you do use RS485 then make sure you add a pull-down resistor from TE/RE to ground as this will keep the transciever in receive mode even during power-up etc until you tell it to transmit. RS422 is not multidrop and not recommended whereas RS485 can disconnect it's transmitter from the bus etc.
I know the Prop can handle 5V with a series resistor but I don't think the RPi is 5V tolerant. I think a nonsensical level shifter might be in order.
BTW, No mention of a Prop in the original question (which of course is a shame).
In networking you separate the media from the protocol. RS232 is a media through which information is transmitted. The start byte and device ID are part of the software implemented protocol.
If you directly connect the pins together you definitely need to protect the 3.3 volt devices from 5 volts. You can buy a level shifter (SparkFun sells them), or build one from a voltage divider. 5 volt devices can usually handle 3.3 volt logic signals.
RS232 is a media type. You would use line drivers to boost the chips TTL levels to the RS232 voltages. As others have said I would probably use TTL rather than RS232.
Good question. The protocol I described has the master transmit while slaves listens, followed by master listening while the slave processes and then acknowledges. It has flow control built in. There are schemes such as I2C which use the pattern I described.