go away spammer

Author Topic: communication protocol between multiple MCUs.  (Read 4578 times)

0 Members and 1 Guest are viewing this topic.

Offline dunkTopic starter

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
communication protocol between multiple MCUs.
« on: May 07, 2007, 07:03:15 AM »
so i'm building a set of standard hardware modules at the moment.
the logic behind it is i'm always repeating the same tasks over and over for my robots and it would be far simpler if i just designed a module once, making it flexible enough that it would suit any application.

the hardware is going to be AVR based. atmega8 for most of the modules.
each module will perform a separate task. one for power management. one for servo controll. one for DC motor controll. one for controlling an LCD display. one for I/O....  you get the idea.
i want to be able to connect these modules together using any of the commonly found communication methods. I2c, rs232, CAN, etc.
(at the moment i'm using the i2c bus and UARTs connected as a point to point serial link.)

i want the software running on each module to be as standard as possible.
obviously there will need to be a section of the program that deals with the hardware specialisation of that module but the rest of the code should be reusable.

each module will have an address and will be able to communicate with one or more other modules using a variety of different communication methods.

so my current model works quite well so far for a bunch of modules sharing a multi master i2c bus. the module address just becomes the i2c bus address.

it is easy enough to have one node separated from that bus by the UARTs on 2 of the microcontrollers. i send the data for the remote microcontroller with the UART out on the i2c bus with the correct module address but the i2c address of the node that has the other UART on the i2c bus.
the node with both i2c and UART receives the data packet, recognises it has a different address form it's own and forwards it out of the UART.

what i would like to do however is be able to communicate between nodes separated by a variety of different communication methods.
for example, in the ASCI diagram below, imagine one i2c bus is onboard a robot and the 2nd is in it's base station/charger and controlls navigation beacons in the room. the 2 i2c buses are linked by a wireless serial connection connected to the UART on microcontrollers [nodeC] and [nodeF].


--------------------------------------------------                      <-  (i2c bus)
     |                |                 |
[nodeA]     [nodeB]     [nodeC]
                                        \                                <- (UART link)
                                        /
[nodeD]     [nodeE]     [nodeF]
     |                |                 |
--------------------------------------------------                      <-  (2nd i2c bus)


for [nodeA] to pass data to [nodeD] we are going to need some sort of network protocol.
in very general terms, i think as well as each device having an address, each network section is going to need an address.
when [nodeA] transmits it will need to transmit the address of [nodeD] as well as the address of the i2c bus [nodeD] is on.
a lookup table on each node will tell it to send the data bound for a different network section to a node that can pass it on to the right network section.

so in the case of a datagram being passed from [nodeA] to [nodeD],
[nodeA] will recognise the network address is not the same as it's current network address so it will consult it's lookup table for the node that can reach that network section and send the current datagram to [nodeC]'s i2c address.
[nodeC] will receive the datagram and recognise the network address is not the same as either of it's current network addresses, lookup it's lookup table and pass the datagram on to [nodeF].
[nodeF] receives the datagram, recognises the network address is that of it's i2c bus and sends it out on that bus to [nodeD]'s i2c address.

so, such a protocol should be as simple as possible as the more complicated it gets the more wastefull of bandwidth and processor power.
at the same time it should be as flexible as possible so it can be easily adapted or expanded to future use.

a sample packet might look like this:
[start][source.network.address][source.node.address][destination.network.address][destination.node.address][data.length][data1][data2]....[dataN][checksum][end]
most networking protocols would have some sort of flags bit for passing specific information along with the packet (for example whether an ACKnolage packet should be sent in return) but if it was up to me i'd pass these in the [dataX] section so the space allocated to this could be extended later if required without breaking existing code.

so, for anyone still reading, i've searched around on the internet a bit and can't really find what i'm looking for.
i toyed with using IP (Internet Protocol) but that seems like overkill.
has anyone seen anything like what i'm describing allready out there?

here's a list of requirements:
- addressable. any node should be able to talk to any other node.
- routable. any node not on a particular network section should be able to pass datagrams through any other node that is connected (directly or indirectly) to that network section.
- low fat. this has to run on microcontrollers with limited memory. also the smaller the packet size the higher the bandwidth.
- flexible. ideally it would be possible to change/modify any paremiter without breaking existing communication on the network.
- open source. i don't want my modules to be tied to anyone elses code.

dunk.

Offline hgordon

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 373
  • Helpful? 7
    • Surveyor Robotics Journal
Re: communication protocol between multiple MCUs.
« Reply #1 on: May 07, 2007, 07:49:12 AM »
You need a node that acts as a router or gateway, taking messages with addresses that aren't on the local bus forward that message via a remote link to the corresponding gateway node on the other network.  You might look at implementing just the IP (datagram) and ARP (address resolution protocol) portion of TCP/IP if you need to route between networks. 

Another thought would be to connect the components via a simple wireless network such as Zigbee (802.15.4) that supports a variety of addressing schemes.  The Zigbee radios are cheap ($16 or thereabouts), and would give your architecture a lot of flexibility without a lot of messy wires.
Surveyor Corporation
  www.surveyor.com

Offline nanob0t

  • Robot Overlord
  • ****
  • Posts: 145
  • Helpful? 0
  • Trust Your Technolust
Re: communication protocol between multiple MCUs.
« Reply #2 on: May 07, 2007, 09:14:18 AM »
http://forums.hak5.org/

These forums can help you with ANY computer issues.  Ask them and they'll have it answered by the end of the day.   ;D

I have a pretty good idea, but the bell is about to ring and I don't have much time to explain.  If you ask the question on this forum, they'll be quick to help you out.  They aren't very robotic based, but they can get this kind of thing hooked up quick.

Offline dunkTopic starter

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: communication protocol between multiple MCUs.
« Reply #3 on: May 07, 2007, 02:28:13 PM »
Quote
You need a node that acts as a router or gateway, taking messages with addresses that aren't on the local bus forward that message via a remote link to the corresponding gateway node on the other network.
yes. exactly.

Quote
You might look at implementing just the IP (datagram) and ARP (address resolution protocol) portion of TCP/IP if you need to route between networks.
the problem with implementing all of IP is the header alone is 20 bytes long. i'd like this to be a bit more light weight than that.
but yes, in essence, what i'm trying to do is implement a system similar to IP addressing and routing.
an simplified ARP equivalent would only be needed when using transport methods with built in addressing (like i2c). addressing would be handled by the network protocol for communication between UARTs and the likes. (like a UDP broadcast.)

Quote
Another thought would be to connect the components via a simple wireless network such as Zigbee (802.15.4) that supports a variety of addressing schemes.  The Zigbee radios are cheap ($16 or thereabouts), and would give your architecture a lot of flexibility without a lot of messy wires.
sure. the Zigbee modules look good for wireless communication.
i'm looking for a solution that is flexible enough for controll of multiple nodes on the same circuit board though. not always a need for wireless communication.

dunk.

 


Get Your Ad Here