AMOS–ComLink  service

ANSARI Micro Operating System's Communication & Linking Service

» Posted on 12. Jun 2013

Related links:  SW-toolAMOS | Overview 


 

Started with communication needs inside the firmware, over local inter-module communications, up to the point where data is exchanged with a database in the network, a new concept was needed to handle all these scenarios seamlessly. AMOS – ComLink is the answer to this need and realizes the best achievable system performance from communication point of view.

 

 

AMOS – ComLink Service

Many hardware modules in the field can be grouped into either sensors or actors. In a decentralized structure, the communication between these modules and their process-levels gets very important. From communication point of view, the communication between modules can be broken down even into the needs between the tasks inside a hardware module. As a result we can imagine a network of sensors and actors with their view of communication needs on one side, followed by the hardware modules itself with their internal process communication needs on the other side.

With this insight, internal and external communication has become one of the core elements of AMOS. A service called ComLink serves any communication and linking needs in an AMOS based environment and handles the two view points seamlessly: The internal communication between tasks inside the hardware and the external communication between different hardware modules.

 

Inter – Module Communications

Wired_Chain_ElementTo keep the nature of the communication system as simple as possible we consider networked modules limited only to a simple chain and prohibit mashed configurations. As a result each module needs at least two independent communication channels: one to its “left” or previous and one to its “right” or next neighbor module.

Each chaining element runs the same communication algorithm and  supports an additional third communication channel for interconnecting two different chains to each other, providing routing and gateway functionality, or giving an interface for servicing aspects.

As shown in figure below, we can now build a chain of modules, where each module acts as a chaining element and some times it additionally acts as a gateway or it provides a service interface to a servicing node. The two green and orange chains are interconnected over the green-chain-element #2 and the orange-chain-element #3. The ComLink algorithm in any hardware module is capable of routing data between chains, whenever the “third” channel is used. Module addressing is a system integrated automatic procedure. 

Chained_modules

 

The service node can interchange data to any of the hardware modules in both chains, due to routing capabilities of any single chain element. The ComLink logic is built in a way, that each chain element gets dynamically its own address in the network. Each module is capable to communicate with any other hardware module in a point to point manner. When one chain element receives a packet, it analyzes the destination address stored in the packet and routes the packet, if the packet is not desired for the chain element himself.

Wireless_Chain_Element

Comlink is independent of channel’s physical layer. The favorite physical layers are UART (RS-232) and Bluetooth links, but SPI, I2C, CAN and other type of communications are also supported.

Same as described for wired system, when Bluetooth is chosen as physical layer, three simultaneous wireless links to three remote nodes can be established in parallel. Two channels build the “left” and “right” links and one channel is basically for human interface connection like an iPhone to exchange data with the wireless chain.

A fourth wired channel is also available for linking to wired chains. Routing between different physical layers like wired to wireless and vice versa is fully supported and transparent to applications.

The data transmitted over any channel can be set to transparent (binary data) or verbose (readable strings). When a single module is connected to a PC, a user can use a terminal program like PuTTY to communicate with the hardware in verbose mode. AMOS accepts command strings from the user and replies with readable strings to the user. But when more devices are chained together, more complex data needs to be exchanged between the modules. Therefore the communication algorithm switches to transparent (binary) mode and the user needs to use the ANSARI – ComLink, a windows based software tool, to communicate with any of the modules in the chain.

AMOS detects automatically the environment, in which it is installed and switches between verbose and transparent mode automatically. Verbose communication is not protocol based, but transparent mode is protocol oriented and communication is packet based and structured.

A verbose packet starts always with an ASCII printable character. This means the first byte transmitted has a value greater than 31 (or in Hex 0x1F). A verbose command ends always with an ASCII carriage return or a line feed control code.

 

Transparent Packets

When the first received byte in a transmission is an ASCII control code (byte value is below 32 decimal or 20 hex), ComLink assumes receiving the first byte of a transparent packet. Transparent packets are fixed in their structure and have three different sections. The first section is always the Header Section. The header is built always by 4 bytes. The fourth byte is the check sum of the first three bytes.

The first byte of the header distinguishes between different types of transparent packets. ComLink algorithm first waits to receive all 4 Header Bytes: HB0 through HB3. Then it recalculates the check sum of the first three bytes (HB0, HB1 and HB2) and compares it with the received fourth header byte (HB3). If they match, then the validity of the Header Bytes received are checked and ComLink interprets the whole expecting transparent packet based on the first header byte (HB0) as following:

 
  • HB0=0x01:   Wired transparent packet
  • HB0=0x0E:   Wireless transparent packet
  • HB0=0x0F:   Routing Information of a transparent type 6 packet

 

Wired Transparent Packets

If HB0=0x01, then we have a transparent packet traveling in a wired system having following structure:

Wired_Transparent_Packet

The wired transparent packet is built by 3 sections. The Header Bytes are sent to remote first, followed by a check sum, so that the destination can match its receiving buffer to expected amount of bytes following and knows how to interpret the packet.

Routing Information bytes are the next section, which is sent to remote. A chain element knows from these bytes if this data packet is desired for himself or it has to be routed out to the neighbor module. The Payload area contains the desired data for the destination application followed by a check sum for the payload area.

 

Transparent Packet Types

The second header byte (HB1) defines different Types of a transparent packet. Following table gives a view of different existing transparent types:

Transparent_Packet_Types

The HB1 value allows ComLink protocol handler to analyze the received bytes correctly and allows the user to generate different types of communication packets as per system or application needs.

Two neighbor nodes can send each other Two-Byte commands. This is the shortest message, which two directly connected nodes can send to each other. This is helpful, when fast short system based commands needs to be sent. Following figures shows a two byte command:

Two_Byte_Command

A few number of command-Bytes are reserved for system proposes, rest can be defined if needed. Two-Byte commands can’t travel in the chain and they are only desired for two directly connected endpoints and not usable for application level. When two applications need to exchange data, then transparent packet type 5 has to be used. This type of data packets can travel only through the local chain. Such packets can’t travel through gateways to other remote chains.

When a data packet needs to be full route-able, even through gateways, then packet type 6 must be used. The ComLink algorithm sends a special transparent packet with HB0=0x0F separately, before each type 6 packet automatically in advance. This packet contains the routing information needed for the next expecting type 6 transparent packet. While the receiver is receiving the type 6 packet it can prepare the routing and channel selection, base on already received type 0x0F packet. Following figure shows these two packets:

Routing_followed_by_Typ6_Packet

 

 

Wireless Transparent Packets

Wireless transparent packets are embedded into lower level wireless protocols like Bluetooth. Only the payload of those protocols are the point of interest in a wireless based system. In case of Bluetooth physical link, the transparent packet needs to be extended with some wireless related data and the routing data is also appended to the packet itself, when transparent packet type 6 is selected.

Wireless_Transparent_Packet

 

Inter – Process Communications

AMOS is a powerful scheduler, which allows 96 single tasks to be executed independently and in parallel. There is often the need for tasks to exchange their data with each other. This is done based on a packet based messaging system within the firmware. The internal Process Communication (IPC) uses exactly the same structures as transparent packet structures. This results into a seamless interchange of data between the two internal and external communication domains. 

To keep the implementation feasible on a limited 16-bit µController platform, the rules below were fixed by ComLink design concept.

 

Basic Definitions

 
  • Communication between any two endpoints is always packet based and time independent
  • Endpoints may sit in same or different hardwares, interconnected by communication channels
  • Communication packets are based on a fixed Inter-Process-Communication (IPC) frame structure
  • IPC structure carries a transparent packet structure inside itself
  • Inside a system only pointers to an IPC packet is exchanged between tasks
  • One IPC packet can be defined to be sent out over several communication channels

 

IPC – Structure

Considering that the body of an IPC packet has to be equal to the transparent packet structure explained above, a header needs to be added to define the IPC structure. As shown in the figure below, the orange area is added to previously defined transparent packet structure, so the internal process communication can be handled within the local firmware.

IPC_packet

 

 

Submit a Comment