CommsDSL Specification
  • Introduction
  • Version
  • Schema Definition
  • Multiple Files
  • Namespaces
  • Platforms
  • References
  • Properties
  • Numeric Values
  • Boolean Values
  • Names
  • Protocol Versioning
  • Schema
  • Fields
    • Common Properties of Fields
    • enum Field
    • int Field
    • set Field
    • bitfield Field
    • bundle Field
    • string Field
    • data Field
    • list Field
    • float Field
    • ref Field
    • optional Field
    • variant Field
    • Referencing Values of Other Fields
  • Messages
  • Interfaces
  • Aliases
  • Frames
    • Common Properties of Layers
    • payload Layer
    • id Layer
    • size Layer
    • sync Layer
    • checksum Layer
    • value Layer
    • custom Layer
  • Protocol Versioning Summary
  • Appendix
    • Properties of schema
    • Common Properties of Fields
    • Properties of enum Field
    • Properties of int Field
    • Properties of set Field
    • Properties of bitfield Field
    • Properties of bundle Field
    • Properties of string Field
    • Properties of data Field
    • Properties of list Field
    • Properties of float Field
    • Properties of ref Field
    • Properties of optional Field
    • Properties of variant Field
    • Units
    • Properties of message
    • Properties of interface
    • Properties of alias
    • Properties of frame
    • Common Properties of Layers
    • Properties of checksum Layer
    • Properties of value Layer
    • Properties of custom Layer
Powered by GitBook
On this page
  • Name
  • Description
  • Layers

Was this helpful?

Frames

PreviousAliasesNextCommon Properties of Layers

Last updated 5 years ago

Was this helpful?

Every communication protocol must ensure that the message is successfully delivered over the I/O link to the other side. The serialised message payload must be wrapped in some kind of transport information prior to being sent and unwrapped on the other side when received. The CommsDSL allows specification of such transport wraping using <frame> XML node.

<?xml version="1.0" encoding="UTF-8"?>
<schema ...>
    <frame ...>
        ...
    </frame>
</schema>

Name

Every frame definition must specify its using name .

<?xml version="1.0" encoding="UTF-8"?>
<schema ...>
    <frame name="ProtocolFrame">
        ...
    </frame>
</schema>

Description

It is possible to provide a description of the frame about what it is and how it is expected to be used. This description is only for documentation purposes and may find it's way into the generated code as a comment for the generated class. The is description.

<?xml version="1.0" encoding="UTF-8"?>
<schema ...>
    <frame name="ProtocolFrame">
        <description>
            Some long
            multiline
            description
        </description>
        ...
    </frame>
</schema>

Layers

<?xml version="1.0" encoding="UTF-8"?>
<schema ...>
    <fields>
        <enum name="MsgId" type="uint8" semanticType="messageId">
            <validValue name="Msg1" val=0x1" />
            <validValue name="Msg2" val=0x2" />
        </enum>
    </fields>

    <frame name="ProtocolFrame">
        <id name="Id" field="MsgId" />
        <payload name="Data" />
    </frame>
</schema>

The example above defines simple protocol framing where 1 byte of numeric message ID precedes the message payload.

ID (1 byte) | PAYLOAD

Available layers are:

<?xml version="1.0" encoding="UTF-8"?>
<schema ...>
    <frame>
        <name value="ProtocolFrame" />
        <layers>
            <id name="Id" field="MsgId" />
            <payload name="Data" />
        </layers>
    </frame>
</schema>

The protocol framing is defined using so called "layers", which are additional abstraction on top of , where every such layer has a specific purpose. For example:

- Message payload.

- Numeric message ID.

- Remaining size (length).

- Synchronization bytes.

- Checksum.

- Extra value, usually to be assigned to one of the

fields.

- Any other custom layer, not defined by CommsDSL.

If there is any other defined as XML child of the <frame>, then all the layers must be wrapped in <layers> XML element for separation.

All these layers have as well as their own specific set of properties.

Use for future references.

name
property
property
fields
<payload>
<id>
<size>
<sync>
<checksum>
<value>
<interface>
<custom>
property
common
properties table