This module contains a description of the CHAILink Transport Interface between Transport and Transport Protocol.

Overview

In order to work properly, the CHAILink Client uses a transport to communicate with the server and the VNM. This transport only needs two channels (one in and one out), allowing to transport stream of bytes in both way. An important point about the transport is that both sides (client and server) can initiate a communication : The client can call a method from the server (client initiates communication) or the server sends a notification or an asynchronous return to the client (Server initiates communication); so, the Master/Slave model of transport does not fit well with the CHAI Link. As prerequisite for Transport being simplicity, the CHAILink Transport Interface is really lightweight and simple.

Transports already implemented:

UART and USART at various speeds up to 20Mhz. A turnkey CPVNM Chip uses this kind of transport. See the Wiki for more details. Note that a reference transport is provided for the CopperDuino platform.
USB : CHAI Link can be used over USB by using a specific USB Interface Descriptor containing a Bulk transport with two endpoints (one In and one Out).
Firewire : CHAI Link has been successfully tested over Firewire by using a control channel.
Dual SPI : Only the MOSI lines of both SPI are used.

Transport Protocol to Transport Interface

This interface only contains two callback functions that are provided to the Transport Protocol during CHAI Link initialization (see CLC_Init).

CLT_WRITE : The Transport write function. See CLT_Interface::pfnWrite
CLT_SETCB : The function is used by the Transport Protocol to set its callback functions. See CLT_Interface::pfnSetCallbacks

Transport to Transport Protocol Interface

This interface only contains two callback functions that are provided by the Transport Protocol during its initialization.

CLT_RECEIVE : The transport pushes the received data to Protocol by calling this function.
CLT_STATUSCHANGECB : The transport calls this function to notify Protocol that transport status has changed.

Transport Operation

1. First of all, the application is responsible for transport's initialization.
2. Then the application calls CLC_Init and provides a pointer to the CLT_Interface. The Transport can for instance provide a CLC_GetInterface function returning the Transport Interface to the application, but implementation is open.
3. The Transport Protocol calls the CLT_Interface::pfnSetCallbacks member of the provided CLT_Interface structure. See CLT_SETCB for prototype. During this call, the Transport Protocol gives its two handlers for data reception and for transport status change. The CLT_STATUSCHANGECB callback could be called during this step (See following step 4).
4. The Transport informs the Transport Protocol that the transport is connected. There are two cases:
- The transport is aware of hardware Connection/Disconnection (for instance with USB devices). In this case, the transport should call CLT_STATUSCHANGECB with TRUE, only when the device is plugged in.
- The transport not is aware of hardware Connection/Disconnection (for instance simple UART/USART). In this case, the transport should call CLT_STATUSCHANGECB with TRUE directly from the CLT_SETCB call (See previous step 3).
5 & 6. The Transport Protocol sends data to Transport when needed and Transport Pushes received data when available in no particular priority order.
7. If Transport is aware of hardware Connection/Disconnection (for instance with USB devices), The Transport notifies the Transport Protocol by calling CLT_STATUSCHANGECB with FALSE. Return to state 4.