The CA-821x platforms and Cascoda SDK all share the same, simple, binary message format which encapsulates data inside a packet comprising of a
Payload. This format is commonly known as a
TLV (Type, Length, Value). In the case of Cascoda messages, the
Length fields are each 1 octet. The
Payload is a field with a length in octets as specified by the
Length field. Many Cascoda message commands operate in a Request/Response manner, with both synchronous and asynchronous responses possible. The Request/Confirm/Indication/Response terminology is used from the IEEE 802.15.4 spec.
The term ‘Host’ refers to the higher level ‘controlling’ platform, and the term ‘Device’ refers to the device being controlled. For instance, when you plug a Chili2D dongle into a PC, the PC is the host of the M2351 microcontroller on the Chili2D, and the M2351 is the host of the CA-8211.
The use of the Cascoda message format is specified in more detail for the CA-821x platforms in the respective datasheets, available on the Cascoda website under the relevant product.
This information is only required for informational/analysis purposes, or if writing a custom driver. If using the Cascoda SDK, then the functions in
posix/ca821x-posix/include/ca821x-posix/ca821x-posix-evbme.h should be used instead of constructing messages directly.
The structure of a Cascoda TLV message is quite simple, and comprises of 3 fields.
Commandfield. It is one octet in length.
Lengthfield. It is one octet in length.
Payloadfield. It is
noctets in length, where
nis the value of the
Lengthfield. The contents and structure of the
Payloadfield depend on the value of the
|Field Length (octets)||1||1||(Length)|
Command field, sometimes called the
Command ID or
CmdId field, describes how the
Payload field should be interpreted. In addition, bit 6 (0x40) affects the message flow. If a
Command has bit 6 set, then the command should be treated as a ‘Synchronous’ command. If not, it is an ‘Asynchronous’ command. See the Asynchronous/Synchronous section for more info.
Command field also determines which layer shall process the command. For instance, some will be processed by the MAC on the CA-821x, whereas others will be processed by the Evaluation Board Management Entity (EVBME) on the host processor.
For example, in the situation where a Linux PC is communicating over USB to a Chili 2D dongle (which includes an M2351 host CPU and CA-8211 transceiver), the following exchange is possible:
The definitive list of commands that go to the EVBME can be found in
enum evbme_command_ids. The definitive list of commands that go to the MAC (CA-821x) can be found in
enum spi_command_ids. The CA-821x datasheets also contains a detailed list of the commands and the payload structures.
Length field describes the length of the
Payload field. It can have any value in the range 0-254 (inclusive).
Payload field is binary data. The structure, characteristics and semantics of the content is determined by the
Command field, and the length is determined by the
Length field. For the structure of the
Payload for CA-821x commands, consult the datasheet, available on the Cascoda website under the relevant product. The
ca821x-api/include/mac_messages.h header can also be used. For the structure of the
Payload for EVBME commands, consult the
For Request – Confirm primitive pairs there are 2 message types: synchronous and asynchronous messages. Although there is no distinction between the physical data exchange for a synchronous and asynchronous message packet, synchronous messages require an immediate confirm and are therefore treated with priority. Asynchronous messages do not require or cannot return an immediate confirm, such as a MCPS-DATA Request, where the confirm can only be issued once the data packet has been sent.
For this reason, when a synchronous request is sent, no further message should be sent until the corresponding confirm has been received. It is permissible to use a sensible timeout such as 500ms, but a failure here is extremely rare and potentially represents a fatal error that should not go unhandled.
Length field value ‘0xFF’ is reserved, and cannot be used. In the SPI protocol between the CA-821x, it is used as the ‘idle’ octet, signifying that there is no data to transmit. This is required due to the nature of SPI being always bidirectional.