Communicating between two or more microcontrollers

[praveen_khm]

Hi guys,

I need some help in interfacing two micro controllers. Suppose I have two atmega8 uc and I need to send a signal to another atmega 8, how do I proceed. I know the UART one, but it works for one to one I suppose. (Also read the uart tutorial). However, if I have 10 different atmega uc's and I need to make all of them slave's and controlled by one master, how do I proceed?

A step by step tutorial would be more helpful, or any links which can help me with it.

Thanks,
Praveen

[Razor Concepts]

Atmegas have built-in I2C modules that enable communication of 127 or more I2C devices. Google "avr i2c" and there should be a TON of examples, I2C is very very popular form of communication.

[madsci1016]

If the slaves never report back to the master, just take commands, then you can use the Uarts. Simple have all the slaves RX lines tied to the masters TX line. When you define the communication protocol, you can start out each packet with an address of a slave, and program your slaves to only listen to packets address to it.

[Pratheek]

You can use both USART and I2C for your requirement.

I would go with I2C, if I were you because it is better suited for your requirement.

[praveen_khm]

Thanks guys...

I am reading I2C. However the idea of madsci1016 sounded easy and interesting, using UART with one Tx connected to multiple Rx's of slaves.
Can someone post a sample code of the communication protocol(Using UART), or a link which can help me?

Cheers,
Praveen

[Pratheek]

There is a generic tutorial on USART on this site and another specifically for AVR.
Go through it and you should be able to write the code yourself.

[Loligo]

Do you mean this uart tutorial?

[madsci1016]

Can someone post a sample code of the communication protocol(Using UART), or a link which can help me?

The nice thing about serial communications using UARTS is that there is no set communication protocol. You can define your own.

Microcontroller libraries usually have some function similar to UartSendByte() and UArtGetByte(). Thats what you use to send and receive a single byte over serial.

So for you, you can send multiple bytes for each 'packet'. And you define what the bytes in your packet mean. You can have a start and stop byte to show were the packet begins and ends, and a address byte to show which slave the packet is for.

For example:

$ 12 [data] *   

could be your protocol. $ signifies the start of a packet, 12 is the slave number, data is the data to send, and * is the end of packet.

[HyperNerd]

The only problem with using a method such as that suggested by madsci is that if your data contains the same byte value of the start or end byte (for example if you are sending raw sensor readings as single bytes rather than as an ASCII number), your programs could get confused as to where the end of the data packet is.

As may already be clear by my post, the solution to this problem is to send all data as ASCII strings and numbers, rather then raw byte format, and revert them to byte format at the receiving end.

 -HyperNerd

[madsci1016]

http://www.billporter.info/?p=214

[praveen_khm]

Thanks guys... will try getting in more details and then maybe experiment with it. 

[madsci1016]

The problem Hyper mentions can also be beaten by having your third byte represent the length of the packet, so it won't confuse digital data for end/start flags.

[Razor Concepts]

I have a feeling I2C, or even SPI with chip selects would be much easier 

[GearMotion]

http://www.bdmicro.com/code/robin/