Communication between 3 Atmega controllers

avrcommunication

I am studying a bio chemistry analyzer, in which there are Main controller, printer board controller and detector board. To establish communication between these three, RxD pin of one controller is connected to same (RxD) of others and same with TxD (all ic's TxD is interconnected.

Is this type of communication possible (Normally we connect TxD to RxD and vice versa)? How they are communicating then? Which protocol is used (I2C,SPI or USART).

How will be master and slave configuration?

Best Answer

Hard to say. If these TXD and RXD pins are really dedicated to RS232 serial, then there would be a multi-driver conflict with the TXD pins. Also, they would not be able to talk to each other.

There are a couple of possibilities, though. I2C, CAN, and half duplex RS-485 are all shared busses that are connected in this way, though the pins are not TX and RX. In I2C you have clock and data. In CAN and RS-485, you have a single differential pair for the data. It's also possible they are using a UART, but they would have to have some method of crossing over TX and RX. Possibly they are disabling the UART on the transmitter end, turning the RX pin around, and bit-banging it. Or perhaps the microcontrollers can swap the TX and RX pins. Or perhaps what you said is not correct and the controller TXD is connected to RXD on the others, and vise-versa, with the TXD pins disabled when not transmitting to avoid conflicts.

Related Solutions

Electronic – MAX485 half duplex Atmega communication problem

In my [in]experience, 99% of serial communication errors are due to timing mismatches; the other* 99% is due to wiring hoopla.

It works for short wire but not a 30ft CAT-5 cable

It works for normal serial wire upto 10ft but not more than that.

CAT-5 cable is twisted pair (also, all of what I have used is also shielded, but apparently this is not common); I assume the "normal serial wire" is two loose wires. As wiring gets longer, your nice digital rise times stretch out, effectively shrinking the available window for sampling incoming data. Twisted pair helps this a bit. What this really means is that your UART clock must be prescaled more accurately to the baud rate being used. System clocks for perfect USART communications should be multiples of 1.8432MHz. Short-range communications can tolerate a few percentage error, but as your sampling window shrinks it must be more accurate. What your prescaler (int), and baud error?

prescaler = (int)(F_CPU / (USART_baudrate * 16) - 1)
actual_baudrate = F_CPU / (prescaler * 16)
baud_error = 100% * (1 - actual_baudrate / USART_baudrate)

It works for 6V battery but not for 12 volt battery or a 12V adapter.

This sounds fishy! This may be a completely different problem, perhaps causing your widget to reset due to a dirty supply or poor regulation. There are stability issues with LDO linear regulators and varying capacitive loads; there may be dissipation issues from a 12V supply; if one isn't using a LDO regulator, then a 6V battery will really be giving you 4.5V to 5V, and won't be well regulated. Power supply issues are in a class all their own, and must be rectified before peripherals can be effectively debugged.

Other than this, there is always the issue with environmental interference, or EMI. RS-485 is made for this, but should be used with twisted pair[, shielded wire,] like the CAT-5 cable you've used.

**(What, my math is wrong? Do you know who I am!? ;)*

How to test an atmega (arduino) i2c network

You can probe and monitor the bus using BusPirate. This way you can see what is happening on the bus and will help you debug the issues.

Here is a video demonstrating i2c bus scan.
It can also be used as a I2C analyzer as demonstrated in this video.

Best Answer

Related Solutions

Electronic – MAX485 half duplex Atmega communication problem

How to test an atmega (arduino) i2c network

Related Topic