All data transfers are initiated by the PC, meaning that the controller waits for incoming commands and replies accordingly. Each
command is followed by the controller response, with rare exceptions of some service commands. One should not send another
command without waiting for the previous command answer.
Commands are split into service, general control and general information types.
Commands are executed immediately. Parameters which are set by Sxxx commands are applied no later than 1ms after
acknowledgement.
Command processing does not affect real-time engine control (PWM, encoder readout, etc).
Both controller and PC have an IO buffer. Received commands and command data are processed once and then removed from buffer.
Each command consists of 4-byte identifier and optionally a data section followed by its 2-byte CRC. Data can be transmitted in both
directions, from PC to the controller and vice versa. Command is scheduled for execution if it is a legitimate command and (in case of
data) if its CRC matches. After processing a correct command controller replies with 4 bytes - the name of processed command,
followed by data and its 2-byte CRC, if the command is supposed to return data.
Controller-side error processing
Wrong command or data
If the controller receives a command that cannot be interpreted as a legitimate command, then controller ignores this command,
replies with an "errc" string and sets "command error" flag in the current status data structure. If the unreconized command contained
additional data, then it can be interpreted as new command(s). In this case resynchronization is required.
If the controller receives a valid command with data and its CRC doesn't match the CRC computed by the controller, then controller
ignores this command, replies with an "errd" string and sets "data error" flag in the current status data structure. In this case
synchronization is not needed.
CRC calculation
CRC is calculated for data only, 4-byte command identifier is not included. CRC algorithm in C is as follows:
unsigned short CRC16(INT8U *pbuf, unsigned short n)
{
unsigned short crc, i, j, carry_flag, a;
crc = 0xffff;
for(i = 0; i < n; i++)
{
crc = crc ^ pbuf[i];
for(j = 0; j < 8; j++)
{
a = crc;
carry_flag = a & 0x0001;
crc = crc >> 1;
if ( carry_flag == 1 ) crc = crc ^ 0xa001;
}
}
return crc;
}
This function receives a pointer to the data array, pbuf, and data length in bytes, n. It returns a two byte CRC code.
Transmission errors
Most probable transmission errors are missing, extra or altered byte. In usual settings transmission errors happen rarely, if at all.
Frequent errors are possible when using low-quality or broken USB-cable or board interconnection cable. Protocol is not designed for
use in noisy environments and in rare cases an error may match a valid command code and get executed.
Missing byte, controller side
A missing byte on the controller side leads to a timeout on the PC side. Command is considered to be sent unsuccessfully by the PC.
Synchronization is momentarily disrupted and restored after a timeout.
Missing byte, PC side
A missing byte on the PC side leads to a timeout on PC side. Synchronization is maintained.
Extra byte, controller side
An extra byte received by the controller leads to one or several "errc" or "errd" responses. Command is considered to be sent
unsuccessfully by the PC. Receive buffer may also contain one or several "errc" or "errd" responses. Synchronization is disrupted.
Extra byte, PC side
An extra byte received by the PC leads to an incorrectly interpreted command or CRC and an extra byte in the receive buffer.
Synchronization is disrupted.
Altered byte, controller side
An altered byte received by the controller leads to one or several "errc" or "errd" responses. Command is considered to be sent
unsuccessfully by the PC. Receive buffer may also contain one or several "errc" or "errd" responses. Synchronization can rarely be
disrupted, but is generally maintained.
Altered byte, PC side
An altered byte received by the PC leads to an incorrectly interpreted command or CRC. Synchronization is maintained.
To Next Page
Loading...