I'm developing a project where I want to link 4 IC's together. 1 master and 3 slaves for motor control. Can I just parallel the serial lines - 1 TX to three RX lines on the slave and link the TX lines of the slaves into the RX of the master.
I'm not worried about more than one slave trying to use the TX line at once.
or do I need to do impedance matching or use some form of transceiver?
Does RS485 come to mind at all?
I'm developing a project where I want to link 4 IC's together. 1 master and 3 slaves for motor control. Can I just parallel the serial lines - 1 TX to three RX lines on the slave and link the TX lines of the slaves into the RX of the master.I'm not worried about more than one slave trying to use the TX line at once.
You can have the master output transmit to three slave inputs, but you cannot connect two or more logic level outputs together, or you are in a situation where one device wants to drive the bus into other direction than the others. At least you should use logic gates to combine the signal so that if any one of the slaves pull low, the output to the master input is low.
or do I need to do impedance matching or use some form of transceiver?
Very different question from the above. You need a tranceiver if the ICs are far apart and connected with cables. Impedance matching, I would think that is least of your concerns if the devices are on same PC board.
ZAPrime,
The important issue emerging here is whether all of the 4 ICs you want to link together are on the same PCB, or physically separated in different "modules" (e.g. powered by different power sources, etc). If so, how many feet are they separated by?
What are the 4 ICs you refer to? Do they all have serial ports, SPI ports, etc? If so which?
SPI links multiple devices on a single "bus". So does I2C. Both will work nicely if there is no more than about a meter between the most widely separated devices.
If the distance is greater than a meter, then I would strongly suggest RS422 or RS485. RS422 is essentially single-master while RS-485 can be thought of as a multi-master system (this is a pretty gross simplification). The same interface chips can generally be used for either.
Jim
They are all on the same printed circuit board and powered by a 3.3V source.
The "master" is an atmega640 in all likelihood. The slaves are mega168s. Each 168 controls a L298 either as a dual motor driver or as a stepper motor controller (I want versatility which a L297 won't grant me.)
Clawson, I was thinking of using MCPM which is why I questioned if I can link 4 serial ports together.
JS, I believe the above answers your question about why I am not using RS485 between the nodes.
Being master/slave, your master txd can connect to the slaves rxd pins. The fun comes with combining the slave txd signals together. You need a 4 input AND gate or if you're really stingy, 4 schottky diodes. RS485 transceivers would also solve the problem.
Well then, with all devices on the same PCB and presumably within inches of each other you have a number of choices for inter-chip communication. The choice of one over others depends a bit on how much hardware burden you can tolerate (extra gates, discretes, etc.) and your immediate project goals. E.g which you are already familiar with and whether you want to spend the time & effort in this project to learn a new comm technique.
A few possiibilities:
1. I2C - probably the most elegant, but difficult if you are not experienced with it. Data rate in this close PCB environmnet can probably come close to 500k or greater BPS depending on your micro clock speeds.
2. SPI - 10 times simpler software-complexity-wise than I2C and maybe a little slower depending on what you are actually trying to accomplish.
3. Serial ports using async communications ("RS-232" at CMOS logic levels, no transceivers required). This is what you proabably had in mind in your original question. The Master transmits to all of the Slave receivers simultaneously . The Slaves transmit to the Master one at a time and usually only "when spoken to". More about this below.
4. Some sort of custom bit-bang routine. Perhaps where the Master has individual "transmit" lines to each Slave (one GPIO output per M-to-S xmit link. and vice-versa for the S-to-M receive links. Lots of possibilities here. Software burden could be high if your messages are complex.
Going back to #3 Serial Port-based scheme. As others have suggested the problem is in tieing the Slave transmit outputs together into the one Master receive input. There are a few ways to accomplish this using only CMOS level signals ( i,e. without RS-whatever transceivers) and within the close confines of a PCB:
A. Bring the 3 or 4 Slave xmit outputs into a hardware logic MUX like a 74AC153 and use two Master GPIO outputs as the address lines for the MUX to select which Slave the Master wants to listen to (as dictated by your protocol between Master and Slaves).
B. Wire-OR the the Slave xmits together by using 7407 gates with a common pull-up ressitor or 74125 tri-state drivers, or similar and let the associated Slave enable the 125, or simply define the protocol in such a way that only one Slave will talk at a given time via the 74x07s.
C. You could also accomplish the same wired-Or functionality of B above by switching the Slaves' transmit output GPIO pin between "output" when it is talking to the Master and "input" when it is not its turn to "talk".
There are lots of other inter-chip communication possibilities, but the above are my suggestions for "simple" solutions. Often the choice is dictated by your level of experience and associated "comfort zone".
1. I2C - probably the most elegant, but difficult if you are not experienced with it. Data rate in this close PCB environmnet can probably come close to 500k or greater BPS depending on your micro clock speeds.
AVR TWI is specified to go up to the 400kHz maximum speed, which is the limit of fast mode standard. And depending on the actual clock speed exactly 400kHz speed may not be reached. Going over 400kHz is as wise as overclocking anything. I2C is great because all devices need only the 2 wires, and the start and stop of a packet is defined by the bus start and stop events.
2. SPI - 10 times simpler software-complexity-wise than I2C and maybe a little slower depending on what you are actually trying to accomplish.
SPI slower than I2C? No SPI is much faster, I bet a 8MHz AVR can receive at least at 1MHz speed. But the protocol only defines how to transfer bytes, the SPI does not define where a data packet starts or ends, that has to be obvious from the data stream itself like in serial port communications. Or then the slave select pin or some extra wires need to be used to determine that. I hate to use AVR as SPI slave for some reason.
Regarding the sharing of serial ports, ANDing, MUXing or making it an open-collector bus is an option. Also good point about slave setting the pin as output only when it is transmitting, since only one slave is transmitting. Might be simplest, did not think about that at first. Only thing needed is a pull-up to keep master RXD high when all slaves have their outputs disabled.
