Skip to content

Instantly share code, notes, and snippets.

@johnhowe

johnhowe/gist:1371436

Created November 16, 2011 21:16
Show Gist options
  • Save johnhowe/1371436 to your computer and use it in GitHub Desktop.
Save johnhowe/1371436 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 2008 (1.71)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>FreeEMS-SerialProtocolCoreSpecification</TITLE>
<META NAME="description" CONTENT="FreeEMS-SerialProtocolCoreSpecification">
<META NAME="keywords" CONTENT="FreeEMS-SerialProtocolCoreSpecification">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="LaTeX2HTML v2008">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="FreeEMS-SerialProtocolCoreSpecification.css">
</HEAD>
<BODY >
<!--Navigation Panel-->
<IMG WIDTH="81" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next_inactive"
SRC="file:/usr/lib/latex2html/icons/nx_grp_g.png">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
SRC="file:/usr/lib/latex2html/icons/up_g.png">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
SRC="file:/usr/lib/latex2html/icons/prev_g.png">
<BR>
<BR>
<BR>
<!--End of Navigation Panel-->
<P>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER">
<BR>
<BR>
<BR>
</DIV>
<P>
<DIV ALIGN="CENTER">
<BR>
<BR>
<BR> <FONT SIZE="+3"><B>Serial Protocol - Core</B></FONT>
<BR>
<BR>
</DIV>
<P>
<DIV ALIGN="CENTER"><FONT SIZE="+2"><I>Author:</I>
<BR>
F<SMALL>RED </SMALL>C<SMALL>OOKE</SMALL>
</FONT></DIV>
<P>
<DIV ALIGN="CENTER"><FONT SIZE="+2"><FONT SIZE="+1">Version 0.7 -- 1st January 2011
<BR>(Working draft)</FONT>
</FONT></DIV>
<P>
<DIV ALIGN="CENTER"></DIV>
<P>
<BR>
<H2><A NAME="SECTION00010000000000000000">
Contents</A>
</H2>
<!--Table of Contents-->
<UL>
<LI><A NAME="tex2html35"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00020000000000000000">Foreword</A>
<LI><A NAME="tex2html36"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00030000000000000000">Main Attributes</A>
<LI><A NAME="tex2html37"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00040000000000000000">Packet Description</A>
<UL>
<LI><A NAME="tex2html38"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00041000000000000000">Packet Data Format</A>
<LI><A NAME="tex2html39"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00042000000000000000">Packet Header Layout</A>
<LI><A NAME="tex2html40"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00043000000000000000">Packet Header Specification</A>
<LI><A NAME="tex2html41"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00044000000000000000">Payload</A>
<LI><A NAME="tex2html42"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00045000000000000000">Checksum</A>
</UL>
<BR>
<LI><A NAME="tex2html43"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00050000000000000000">Header Details</A>
<UL>
<LI><A NAME="tex2html44"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00051000000000000000">Protocol Packets</A>
<LI><A NAME="tex2html45"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00052000000000000000">Addressing Behaviour</A>
<LI><A NAME="tex2html46"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00053000000000000000">Acknowledgments</A>
<LI><A NAME="tex2html47"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00054000000000000000">Payload ID</A>
<LI><A NAME="tex2html48"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00055000000000000000">Sequence Numbers</A>
<LI><A NAME="tex2html49"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00056000000000000000">Length Of Payload</A>
</UL>
<BR>
<LI><A NAME="tex2html50"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00060000000000000000">General Information</A>
<UL>
<LI><A NAME="tex2html51"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00061000000000000000">Flow Control</A>
<LI><A NAME="tex2html52"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00062000000000000000">Reliable Transmission</A>
<LI><A NAME="tex2html53"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00063000000000000000">Packet Size</A>
<LI><A NAME="tex2html54"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00064000000000000000">Protocol Layers</A>
<LI><A NAME="tex2html55"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00065000000000000000">Response Times</A>
</UL>
<BR>
<LI><A NAME="tex2html56"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00070000000000000000">UART Specifc Information</A>
<UL>
<LI><A NAME="tex2html57"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00071000000000000000">Packet Data Format</A>
<LI><A NAME="tex2html58"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00072000000000000000">Bitwise Byte Format</A>
<LI><A NAME="tex2html59"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00073000000000000000">Escaping Scheme</A>
<LI><A NAME="tex2html60"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00074000000000000000">UART Specific Error Detection</A>
</UL>
<BR>
<LI><A NAME="tex2html61"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00080000000000000000">CAN Specific Information</A>
<LI><A NAME="tex2html62"
HREF="FreeEMS-SerialProtocolCoreSpecification.html#SECTION00090000000000000000">Payload IDs</A>
</UL>
<!--End of Table of Contents-->
<P>
<H1><A NAME="SECTION00020000000000000000">
Foreword</A>
</H1>
<P>
The purpose of the protocol is to provide reliable two-way serial communication
with FreeEMS and associated devices over multiple physical protocols. This will
commonly be used for live tuning, configuration changes, firmware updates and
data acquisition of various types.
<P>
This document covers the basic data transfer protocol, which all
implementations should adhere to. It describes the methods through which
various functions are achieved, right down to the hardware, at all but the
application level.
<P>
Each implementation will provide documentation on the device-specific
functionality offered and the payload data formats used. Not all devices
will support all functions, either because they have limited functionality
(a display device for example), or because the software versions may differ.
Where logging/debug facilities are available, the payload type of unrecognised
packets should be noted before discarding them.
<P>
<H1><A NAME="SECTION00030000000000000000">
Main Attributes</A>
</H1>
<UL>
<LI>Compact binary data format to maximize speed and bandwidth.
</LI>
<LI>Data is packetized with an escaping scheme.
</LI>
<LI>Each packet consists of a header, payload and checksum.
</LI>
<LI>Compulsory integrated low-cost checksum.
</LI>
<LI>Compulsory acknowledgment of received packets.
</LI>
<LI>Optional sequence numbers
</LI>
<LI>Big endian multi byte number format
</LI>
<LI>Compulsory core functionality across implementing devices
</LI>
</UL>
<P>
<H1><A NAME="SECTION00040000000000000000">
Packet Description</A>
</H1>
<P>
<H2><A NAME="SECTION00041000000000000000">
Packet Data Format</A>
</H2>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER">Packer header: 3 - 6 bytes</TD>
<TD ALIGN="CENTER">Packet payload: 0 - max bytes</TD>
<TD ALIGN="CENTER">CKS</TD>
</TR>
</TABLE>
</DIV>
<P>
A packet consists of a three to six byte header, a payload of variable length
from zero to implementation maximum payload size and a one byte checksum. This
format will be encapsulated in various lower level constructs depending on the
medium of transmission.
<P>
<H2><A NAME="SECTION00042000000000000000">
Packet Header Layout</A>
</H2>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER">Flags</TD>
<TD ALIGN="CENTER">Payload ID</TD>
<TD ALIGN="CENTER">Seq No.</TD>
<TD ALIGN="CENTER">Payload Length</TD>
</TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00043000000000000000">
Packet Header Specification</A>
</H2>
<P>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="LEFT">Byte sequence</TD>
<TD ALIGN="LEFT">Length</TD>
<TD ALIGN="LEFT">Data</TD>
</TR>
<TR><TD ALIGN="LEFT">1</TD>
<TD ALIGN="LEFT">1</TD>
<TD ALIGN="LEFT">Header flags</TD>
</TR>
<TR><TD ALIGN="LEFT" ROWSPAN=8 WIDTH=1>&nbsp;</TD>
<TD ALIGN="LEFT" ROWSPAN=8 WIDTH=1>&nbsp;</TD>
<TD ALIGN="LEFT">Bit 0 - Has Length</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">2,3</TD>
<TD ALIGN="LEFT">2</TD>
<TD ALIGN="LEFT">Payload ID</TD>
</TR>
<TR><TD ALIGN="LEFT">4</TD>
<TD ALIGN="LEFT">1 (opt)</TD>
<TD ALIGN="LEFT">Sequence number</TD>
</TR>
<TR><TD ALIGN="LEFT">4,5 or 5,6</TD>
<TD ALIGN="LEFT">2 (opt)*</TD>
<TD ALIGN="LEFT">Length of payload (excluding header/checksum)</TD>
</TR>
</TABLE>
</DIV>
* Required for some packet types
<P>
<H2><A NAME="SECTION00044000000000000000">
Payload</A>
</H2>
<P>
Packets are just containers and the payload data is specific to the payload
type being sent. See Payload ID.
<P>
<H2><A NAME="SECTION00045000000000000000">
Checksum</A>
</H2>
<P>
The checksum is a simple 8 bit type as the EMS deals with bytes during uart
transmission. It is compulsory to include the checksum in each packet. It is
located at the end of the payload to ease load on the EMS during send and
receive operations and keep the code simple and compact. The checksum covers
all bytes in the message before any escaping and packetising occurs, including
the header but not including the start and stop delimiter bytes.
<P>
<H1><A NAME="SECTION00050000000000000000">
Header Details</A>
</H1>
<P>
<H2><A NAME="SECTION00051000000000000000">
Protocol Packets</A>
</H2>
<P>
Payload IDs of less than <TT>256</TT>/<TT>0x0100</TT> (<TT>0x0000</TT> -
<TT>0x00FF</TT> / <TT>0</TT> - <TT>255</TT>) are of type ``protocol'' and
defined payload IDs should be implemented in all devices using this protocol in
their application. (See appendix&nbsp;<A HREF="#app:payload"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
SRC="file:/usr/lib/latex2html/icons/crossref.png"></A>)
<P>
All payload IDs of 256/0x0100 or more when the payload type bit of the header
flags is clear (<TT>0</TT>) the payload type is of the type ``firmware''. The firmware
payload IDs are covered in the FreeEMS Vanilla Specific protocol specification,
and are optional.
<P>
<H2><A NAME="SECTION00052000000000000000">
Addressing Behaviour</A>
</H2>
<P>
Addressing of packets will be handled by wrapping them in other protocols of
a different layer at a higher level. UART is a point to point protocol and
thus it does not make sense to use addressing at this layer of the protocol.
Wrapping could occur on CAN, SPI, Ethernet and other addressable bus type
protocols.
<P>
<H2><A NAME="SECTION00053000000000000000">
Acknowledgments</A>
</H2>
<P>
All packets received are responded to with an acknowledgement. The
acknowledgement payload ID is one greater than whatever was received. In the
header of the acknowledgement packet is a bit that specifies whether it is a
positive or negative acknowledgement. In the case of success, the payload will
either be empty (default) or contain the requested data in the format specified
for that payload ID. In the case of failure the payload contains a 16 bit error
code.
<P>
<H2><A NAME="SECTION00054000000000000000">
Payload ID</A>
</H2>
<P>
The payload ID is a unique identifier number that indicates the functionality
to be delivered by a request packet. All payload request IDs are to be even
and all response packets are the ID of the request plus one. See Apendix A for
protocol payload ID definitions.
<P>
<H2><A NAME="SECTION00055000000000000000">
Sequence Numbers</A>
</H2>
<P>
The protocol provides a facility for packets to be identified by sequence
number as well as just type and timing. If a sequence number is supplied and
flagged it will be returned just the same. Asynchronous packets will not carry
sequence numbers, and it is perfectly acceptable to not use them at all. They
are provided as an option for tuning authors to use.
<P>
<H2><A NAME="SECTION00056000000000000000">
Length Of Payload</A>
</H2>
<P>
Length from the end of the header to the end of the payload NOT including the
checksum, header or packet delimiters, and before escaping occurs.
<P>
<H1><A NAME="SECTION00060000000000000000">
General Information</A>
</H1>
<P>
<H2><A NAME="SECTION00061000000000000000">
Flow Control</A>
</H2>
<P>
Upon receiving a packet that requires a response the EMS will be responsible
for disabling receipt of further requests by disabling the receive register
full interrupt. By this mechanism it can ignore subsequent requests until the
current packet is dealt with and the receive buffer free again. The external
device should expect messages to be ignored up until the first byte of the
response packet comes back. If datalog streaming is enabled it will not be
possible to determine whether or not the packet is the response until it is
completely received. Instead, it is probably better to wait for some short
period after a packet is transmitted and delay sending further packets until
after that period is over. No harm can be done by sending packets while the
device is not listening, they will just be ignored. RS232 hardware flow control
is not used as it is rarely implemented correctly or even at all in common
physical implementations.
<P>
<H2><A NAME="SECTION00062000000000000000">
Reliable Transmission</A>
</H2>
<P>
In all cases the external software will be responsible for ensuring
unacknowledged messages sent to the EMS are resent. The EMS will work on a
``best effort'' basis to handle all requests promptly, however that can not be
guaranteed.
<P>
Several generic methods of recognising bad data exist:
<P>
<UL>
<LI>Checksum does not match that supplied.
</LI>
<LI>Packet length in the header (if present) does not match the actual length received.
</LI>
<LI>Packet is larger than the maximum allowed size.
</LI>
<LI>The payload length does not match that of the payload ID (where fixed and defined)
</LI>
</UL>
<P>
In addition, the specifics of how each different physical layer operates will
provide further means of recognising bad packet data as will the different
payload types.
<P>
<H2><A NAME="SECTION00063000000000000000">
Packet Size</A>
</H2>
<P>
Packet size is only limited by the size of the payload size field and the
specific implementations hardware software setup. Currently FreeEMS Vanilla
only requires&nbsp;2k packet size to be handled, however up to 64k is supported by
the 16 bit size field. This will ensure it stays useful for a longer time and
will therefore allow tool re-use too. If larger data blocks need to be sent in
some future FreeEMS implementation then the data can be packetised down inside
this format without much difficulty. Each implementation should provide the
facility to request the maximum permissible packet size.
<P>
<H2><A NAME="SECTION00064000000000000000">
Protocol Layers</A>
</H2>
<P>
<UL>
<LI>Physical layers: UART over RS232 or USB, CAN, SPI, I<IMG
WIDTH="13" HEIGHT="22" ALIGN="BOTTOM" BORDER="0"
SRC="img2.png"
ALT="$ ^2$">
C, etc
</LI>
<LI>Data layer (UART): escaping/start/stop/bit format/etc
</LI>
<LI>Data layer (CAN): yet to be determined
</LI>
<LI>Packet layer: generic across all mediums
</LI>
<LI>Application layer: device/firmware specific
</LI>
</UL>
<P>
<H2><A NAME="SECTION00065000000000000000">
Response Times</A>
</H2>
<P>
To be defined once implemented and tested. Thanks EdG!
<P>
<H1><A NAME="SECTION00070000000000000000">
UART Specifc Information</A>
</H1>
<P>
<H2><A NAME="SECTION00071000000000000000">
Packet Data Format</A>
</H2>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER"><TT>STX</TT></TD>
<TD ALIGN="CENTER">Data Packet (Header Payload and Checksum): 4 - max bytes</TD>
<TD ALIGN="CENTER"><TT>ETX</TT></TD>
</TR>
</TABLE>
</DIV>
<P>
This is a diagram of a single packet of data, in a serial stream. <TT>STX</TT> and
<TT>ETX</TT> are single bytes that mark the start and end of the packet (the escaping
scheme). Should the data flow be interrupted, the data flow can be picked back
up again, by looking for the <TT>STX</TT> byte. This escaped and delimited packet scheme
affords a number of opportunities to catch corrupt data as seen in the Reliable
transmission section.
<P>
<H2><A NAME="SECTION00072000000000000000">
Bitwise Byte Format</A>
</H2>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER">Start</TD>
<TD ALIGN="CENTER">8 data bits</TD>
<TD ALIGN="CENTER">Parity</TD>
<TD ALIGN="CENTER">Stop</TD>
</TR>
</TABLE>
</DIV>
<P>
Low level 9 bit data format consisting of 11 bits total. One start bit (low),
8 data bits, one hardware generated odd parity bit, one stop bit (high). See
MC9S12XDP512V2.pdf section 11.4.3 page 495
<P>
<H2><A NAME="SECTION00073000000000000000">
Escaping Scheme</A>
</H2>
<P>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER">Description</TD>
<TD ALIGN="CENTER">Byte value</TD>
<TD ALIGN="CENTER">Escaped pair</TD>
</TR>
<TR><TD ALIGN="CENTER">Start byte (<TT>STX</TT>)</TD>
<TD ALIGN="CENTER"><TT>0xAA</TT></TD>
<TD ALIGN="CENTER"><TT>0xBB</TT> <TT>0x55</TT></TD>
</TR>
<TR><TD ALIGN="CENTER">Escape byte (<TT>ESC</TT>)</TD>
<TD ALIGN="CENTER"><TT>0xBB</TT></TD>
<TD ALIGN="CENTER"><TT>0xBB</TT> <TT>0x44</TT></TD>
</TR>
<TR><TD ALIGN="CENTER">End byte (<TT>ETX</TT>)</TD>
<TD ALIGN="CENTER"><TT>0xCC</TT></TD>
<TD ALIGN="CENTER"><TT>0xBB</TT> <TT>0x33</TT></TD>
</TR>
</TABLE>
</DIV>
<P>
All packets start with <TT>STX</TT>, and end with <TT>ETX</TT>. Should any of
<TT>STX</TT>, <TT>ETX</TT> or <TT>ESC</TT> occur within the packet contents
(including the header and checksum), it must be ``escaped'', with a preceding
<TT>ESC</TT> byte and the byte itself XOR'ed with the value 0xFF. This will
yield the following easy to recognise pairs in the stream:
<P>
If the character <TT>0xBB</TT> is found in the raw stream without
<TT>0x55</TT>, <TT>0x44</TT> or <TT>0x33</TT> following it, the stream and
therefore packet is corrupt and invalid and should be discarded.
<P>
<H2><A NAME="SECTION00074000000000000000">
UART Specific Error Detection</A>
</H2>
<P>
This section is supplementary to the things mentioned in the reliable delivery
section above. The following things should be checked for when interacting over
a UART connection of any sort:
<P>
<UL>
<LI>Start byte found before stop byte while inside a packet.
</LI>
<LI>Escape byte not followed by an escaped special byte.
</LI>
<LI>Parity bit errors at the byte level.
</LI>
<LI>Framing errors
</LI>
<LI>Overrun errors
</LI>
<LI>Noise errors
</LI>
</UL>
<P>
Note, not all of these signals will be available on all devices, but whatever
is available should be used to ensure a highly robust serial solution is
implemented. After all, the EMS code can only confirm that the received data is
in good condition, it can not be responsible for the integrity of the data it
sends out as it could easily be corrupted in transit.
<P>
Note: The checksum doesn't cover the start, stop, escape or escaped bytes, only
the original packet data.
<P>
<H1><A NAME="SECTION00080000000000000000">
CAN Specific Information</A>
</H1>
<P>
Yet to be determined.
<P>
<H1><A NAME="SECTION00090000000000000000"></A>
<A NAME="app:payload"></A>
<BR>
Payload IDs
</H1>
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="LEFT"><FONT SIZE="-1"> ID </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Name </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Type </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Size </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Description and format </FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Interface Version </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Request </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> The unique number that identifies the firmware specific interface definition. If this is the same, there should be absolutely no difference in communications. Useful to allow tuning tools to support interface version ranges based on common functionality and different firmwares with the same interface type.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
1 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Interface Version </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 16 - 256 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Details on the semantics of handling and using this field are not yet defined. For now it can simply be used to identify whether the API and data layout are AT ALL changed from previous versions. That is not good enough in the long term, though.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
2 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Firmware Version </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Request </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> The unique string that identifies the firmware version running on the device. Useful for associating behaviours, issues and bugs with specific code versions.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
3 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Firmware Version </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 16 - 256 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> An arbitrary string 16 to 256 bytes long uniquely describing the firmware version running on the device.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
4 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Max Packet Size </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Request </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Ask the controller to tell us how large in bytes the maximum packet it can handle is. The size is measured from the end of start byte to beginning of stop byte including the header, payload and checksum regions.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
5 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Max Packet Size </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 2 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> 16 bit unsigned integer packet size.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
6 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Echo Packet </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Request </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Any </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Wrap and return the entire packet as the payload.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
7 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Echoed Packet </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Any </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> The wrapped packet returned.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
8 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Soft Reset * </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Command </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Instructs the device to software reset itself.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
9 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> <IMG
WIDTH="20" HEIGHT="35" ALIGN="MIDDLE" BORDER="0"
SRC="img3.png"
ALT="$ &lt;$">
special case<IMG
WIDTH="20" HEIGHT="35" ALIGN="MIDDLE" BORDER="0"
SRC="img4.png"
ALT="$ &gt;$">
</FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 2 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Only if the request is malformed you will get an error back.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
10 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Hard Reset * </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Command </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 0 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Instructs the device to hardware reset itself. (complete)</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
11 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> <IMG
WIDTH="20" HEIGHT="35" ALIGN="MIDDLE" BORDER="0"
SRC="img3.png"
ALT="$ &lt;$">
special case<IMG
WIDTH="20" HEIGHT="35" ALIGN="MIDDLE" BORDER="0"
SRC="img4.png"
ALT="$ &gt;$">
</FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Response </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 2 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Only if the request is malformed you will get an error back.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
13 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Error/Exception </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Assertion </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> 2 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> 16 bit unsigned integer error number.</FONT></TD>
</TR>
<TR><TD ALIGN="LEFT"><FONT SIZE="-1">
15 </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=57><FONT SIZE="-1"> Debug Data </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Assertion </FONT></TD>
<TD ALIGN="LEFT"><FONT SIZE="-1"> Any </FONT></TD>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH=198><FONT SIZE="-1"> Free form data of any type for debug purposes.</FONT></TD>
</TR>
</TABLE><FONT SIZE="-1">
<BR>* Note, soft and hard reset behaviour is implementation
dependent and both may behave the same way as each other.
</FONT>
<P>
<H3><A NAME="SECTION00090100000000000000">
ID</A>
</H3>
Payload ID number which uniquely identifies the purpose and format of the data
contained in the payload.
<P>
<H3><A NAME="SECTION00090200000000000000">
Type Key:</A>
</H3>
<UL>
<LI>Request - A message sent from a tuning device or similar to an embedded
device or similar. Typically PC <!-- MATH
$\rightarrow$
-->
<IMG
WIDTH="24" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
SRC="img5.png"
ALT="$ \rightarrow$">
EMS
</LI>
<LI>Response - The reply to a request from an embedded device or similar to a
tuning device or similar. Typically EMS <!-- MATH
$\rightarrow$
-->
<IMG
WIDTH="24" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
SRC="img5.png"
ALT="$ \rightarrow$">
PC
</LI>
<LI>Command - A message sent from a tuning device or similar to an embedded
device or similar. Typically PC <!-- MATH
$\rightarrow$
-->
<IMG
WIDTH="24" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
SRC="img5.png"
ALT="$ \rightarrow$">
EMS
</LI>
<LI>Assertion - A message sent from an embedded device or similar to a tuning
device or similar. Typically EMS <!-- MATH
$\rightarrow$
-->
<IMG
WIDTH="24" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
SRC="img5.png"
ALT="$ \rightarrow$">
PC
</LI>
</UL>
<P>
<H3><A NAME="SECTION00090300000000000000">
Size</A>
</H3>
Payload size is in bytes from end of header to beginning of checksum.
<P>
<H3><A NAME="SECTION00090400000000000000">
Description And Format</A>
</H3>
The purpose of this particular payload type and how the data is laid out.
<P>
Note: This table is liable to be extended in subsequent
versions.
<P>
<H1><A NAME="SECTION000100000000000000000">
About this document ...</A>
</H1>
<P>
This document was generated using the
<A HREF="http://www.latex2html.org/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2008 (1.71)
<P>
Copyright &#169; 1993, 1994, 1995, 1996,
<A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
Computer Based Learning Unit, University of Leeds.
<BR>
Copyright &#169; 1997, 1998, 1999,
<A HREF="http://www.maths.mq.edu.au/~ross/">Ross Moore</A>,
Mathematics Department, Macquarie University, Sydney.
<P>
The command line arguments were: <BR>
<STRONG>latex2html</STRONG> <TT>-split 0 FreeEMS-SerialProtocolCoreSpecification.tex</TT>
<P>
The translation was initiated by on 2011-11-17<HR>
<!--Navigation Panel-->
<IMG WIDTH="81" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next_inactive"
SRC="file:/usr/lib/latex2html/icons/nx_grp_g.png">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
SRC="file:/usr/lib/latex2html/icons/up_g.png">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
SRC="file:/usr/lib/latex2html/icons/prev_g.png">
<BR>
<!--End of Navigation Panel-->
<ADDRESS>
2011-11-17
</ADDRESS>
</BODY>
</HTML>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment