Pages: [1]   Go Down
Author Topic: MaCaco Communication Protocol  (Read 995 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello Forum,

I would like to share a first draft of P2P protocol that allow multiple connection between Arduino devices. Suggestion, comments and tester are welcome.

The main idea is build an ISO/OSI Level4/5 protocol to allow data exchange between 8bits uC that use a Level2/3 protocol as starting point. At the end of the development it will work over Arduino Ethernet and Freakduino Chibi, but others can be added in future.

Up to now is fully working over standard (or extended) Chibiduino, in the next days I will work to move it over Ethernet and build bridge facilities.

I posted the original message in the FreakLabs forums, and now I'm reporting here to have more visibility. http://freaklabs.org/index.php/Forum/Chibi-General/3086-MaCaco-Communication-Protocol.html

Quote
Base concept,

The protocol is inspired to Modbus in some features, data are exchanged via a shared map (an array that has the same structure in all devices), for each type of action there is a functional code, data sent should not allow gaps.

Out of these, the protocol doesn't share other common points with Modbus. Mainly differencies are:
- Doesn't work as Master-Slave, is a P2P,
- Shared Map could contain different data between devices,
- Data could be polled, but also exchange only when data are changing their value.

Shared Map,

The shared memory map is just an array that has the same structure for all devices (is not a real constrain, but is suggested). Virtually is splitted in INPUT and OUTPUT areas, where OUTPUT are tipically shared with other devices. The INPUT are used to collect data from devices in the network.

An area of the memory map (tipically the output) is also assigned for subscription.


Subscription mode,

The protocol allow to subscribe an area (tipically the output) of the memory map of another device. Every time that data change, the source of data will communicate the new values to the device that was asking for the subscription.
The subscription save bandwith and CPU load, periodically the device asking for subscription renew it based on two parameters: channel healty and communication counts.

Polling mode,

Some data could be required on event-base and not at every cicly, in this case polling is the right option. In case of polling, for each request is sent an answer with the current values also if they aren't changed.

Using polling mode at every cycle will use bandwith and CPU also if not really required.


State-less protcol,

This protocol is quasi state-less, this because in the header of the frame is contained the address where data will be placed once it came back. So is not required to record the connection. This feature make impossible use this protocol within devices that use a different number of bits for addressing their internal registers, but lets less code.

Is not fully state-less because in subscription mode are stored healty and count for each communication channel.

When, Why, Who...

This protocol could be used to exchange data between multiple Freakduinos, and can work over standard chibiduino or chibiduino with routing. It allow easy data transfer for people intendend to build a distribuited system (like home automation system).

Next step are listed below:
  • Build a software layer that virtualize (partially) the Chibi stack over TCP/IP
  • Build a software layer that virtualize the communication media and allow bridging
  • Move MaCaco protocol over this virtual layer
  • Build an Android application able to communicate in MaCaco to get data from the devices

So, the result should be:
|MaCaco Protocol| -> |Virtual Communication Media Layer|
                                              |                            |
                 |Extended Chibi over Freakduino|  and/or   |Virtual Extended Chibi over Ethernet|

A modification on the virtual communication media layer allow additional devices that use different media, where a virtualized Chibi should be moved over.

The Extended Chibi is basically the Chibi relese 0.51 with routing functionalities http://freaklabs.org/index.php/Forum/Chibi-General/3017-chibiduino-v.0.51-with-Routing.html. Routing functionalities allow to extend the listening range of wireless devices, devices not in listening range can use one or more middle node. Furthermore, route message via a bridge allow communication with devices that use different media.

Basically, the Extended Chibi (also called Chibi with routing), is a Level 2 protocol with some Level 3 features. For example, the Level 2 addresses are merged with a subnet mask (like in IP) to define groups in listening range.

Then, to allow communication within devices that use different media there were two options:
1) Move Chibi over device that use TCP/IP, or
2) Move TCP/IP over device that use Chibi.

The second option is not feasibile, too code to write and too load for the AVR. The first option will add to the TCP/IP an additional layer that add functionalities yet into the TCP/IP. But is the only way to share addressing and routing between Freakduino and Arduino Ethernet.

In the links listed before there is the source code and some example for the Chibi with routing and MaCaco protocol, I've tryed them with no more than 3 Freakduinos but look working.
I hope to complete the development as soon to include also Arduino Ethernet (I get two boards and a shield few days ago).

In the mean time,everyone that would like to share suggestion or test the code is welcome.

Regards,
Dario.


Logged

Pages: [1]   Go Up
Jump to: