User Tools

Site Tools


software_behav

This is an old revision of the document!


ANT protocol features

General Specifications

ANT protocol relies on messages (commands) sent from the MNC to the selected SNC or to all connected SNCs if communication is initiated with the brodcast message.

The MNC initiates communication by sending a Break signal. After this an address is sent and if the address is not the brodcast address (0xFF) only the SNC with the specified address can be active on the network (being active means receiving commands and providing answers). All other SNCs are inactive, which means that they will ignore any byte sent by the MNC until the next Break. Note that inactive SNCs can still assert the SRQ line to inform the MNC that a Servce ReQuest need to be processed.

Commands are a sequence of bytes. Commands are all formed in the following way:

  • First byte: length of the command including this very byte
  • Second byte: a byte identifying the command, or command code (form 0x00 to 0xFF)
  • Following bytes: command arguments, if any.

For instance, suppose command 7 has no argument. To issue command 7 the MNC will send:

  • First byte: 2 (0x00) number of bytes in the command
  • Second byte: 3 (0x03) the command code

Suppose now that MNC need to issue the command 10 (0x0A) with 2 bytes as arguments. The MNC will send:

  • First byte: 4 (0x04) number of bytes in the command
  • Second Byte: 10 (0x0A) the command code
  • Third Byte: b1 (0x??) first argument
  • Fourth Byte: b2 (0x??) second argument.

The command structure is chosen in this way so that the SNC is capable of completing the reception of any command regardless of the actual command, that is without the need for the SNC to know the number of arguments to be expected for each command. The SNC stores the incoming bytes in the command receiving queue and “knows” that a command is complete when the number of received bytes is equal to the value of the first byte. In some situations, if one is sure that the receiving queue has not been modified, if the command 10 has to be re-issued a second time without modifying the arguments, one can simply send the sequence (0x02)(0x0A): the SNC will interpret the command as complete after the second byte and the service routine will not know the difference with respect to the first case (provided, as said before, that the command input queue has not been modified with regards to the bytes holding the arguments between successive calls).

ANT should be able to manage predefined commands (commands required for the operation of ANT itself such as setting the SNC address, writing sections of the SNC flash, managing SRQ and so on) as well as user defined commands. Actually, system commands may also include a set of default commands that is expected anyone might be glad to have readily available when developing applications (write/read a byte in a memory location or in a registers, read/write the content of a register in the EEPROM, read the content of a word in the flash and so on).

Non all SNCs have the need for encoding the entire range (256) commands, and yet, for simplifying conventions and developing, one should actually have code for each and every potential command, even if they are not implemented.

The way in which SerNet (the precursor of ANT) recovers the address of the service routine for each command is to use the command code as an index in a vector of addresses stored in the program memory (Command Vector Table or CVT). Now let us assume that in one application we can live with just 16 commands (among system commands and user commands) while in the case of another more sophisticated application we require, say, 64 commands. We can certainly employ a 16 word long CVT in one case and a 64 word long CVT in the second case. Presumably, the 64 commands version will be, in most cases, a super-set of the 16 commmand set, and therefore it would be nice to maintain the same command code for the fundamental “core” commands regardless of the length of the CVT.

In ANT this result is achieved according to the following conventions.

  • The MNC interprets the command code as a 2's complement 8 bit long integer. This means that, form the MNC point of view, command codes range from -128 to 127;
  • The SNC, upon receiving the command code, sets to 0 the M most significant bits, depending on the CVT length being implemented [M=0 for len(CVT)=256, M=1 for len(CVT)=128, M=2 for len(CVT)=64, M=3 for len(CVT)=32]
  • From the point of view of the MNC, all negative commands are System Commands; all non negative commands are user commands.

According to the previous conventions, the core system commands (and the most common command developed by the user) will correspond to small (either negative or non negative) integers.

The system command with code -1 will be issued by the MNC by sending 0xFF in all cases. The receiving SNC will transform this code in a different index depending on its CVT length.

Detail on implementation are discussed in the software session.

Required functionalities

At present we will discuss required functionalities as if we had an infinite number of commands and not concerns for efficiency (speed and memory occupancy). Later on a synthesis will be attempted.

System Commands

Commands for writing/reading to/from RAM and registers

When accessing registers, IO space and RAM through a command, it makes no sense to worry about efficiency in access. Therefore it will b assumed that access is always done through ST/LD as far as addresses are concerned. It does not appear to be practical to implement safeguards within the SNDs against inadvertently writing into registers or IO locations. It is the responsibility of the MNC not to perform “dangerous” operations.

In order to “keep it simple” we will only observe that reading (writing) from from (into) the IO registers only requires addresses form 0X0000 to 0X001F. In a sense, the I/O spaces can be regrded as a sort of Page “0” (with reference to the glorious 6502) and therefore it makes sense to distinguish in accessing “page0” (ony one byte as address) and the generic ram (two bytes for address).

Therefore we may define the following commands (cc represents the command code yet to be defined):

MNEMDescriptionbyte1byte2byte3byte4byte5
RPG0Read from page 03ccADD
RRAMRead from RAM 4ccADD HADD L
WP0MWrite into page 0 with mask 5ccADDVALMASK
WRAMWrte into RAM 5ccADD H ADD L VAL

RPG0

Reads the byte at address ADD (ADD from 0X00 to 0X1F); Response can be the same transmitted string with the read value in place of ADD.

N.B. Leaving the length of the response string unchanged with respect to the transmitted string simplifies writing the commands (in ANT transmit buffer and receive buffer in the SNDs coincide).

RRAM

Reads the byte at address ADD H:ADD L; Response can be the same transmitted string with the read byte in place of one of the two address bytes.

WP0M

We are writing into the IO space and therefore it make sense adding a MASK byte for those many cases in which we want to write specific bits leaving the other unchanged. The WPOM routine will first read the contents of the register at (RAM) location ADD, will “AND” it with mask complemented (bit by bit). the result will be “OR”ed bit by bit with the result of VAL “AND” MASK. Mask will therefore have at “1” the bits to be changed.

Response message might contain the actual value written to ADD instead of VAL.

WRAM

Writes VAL into the memory location ADD_H:ADD_L. In this case there is not MASK. Note that WRAM can also be used to write into the IO registers without MASK.

Response can simply be the sent message that is therefore used as as sort of acknowledge (for non time sensitive applications).

Commands for modifying the flash
software_behav.1496683284.txt.gz · Last modified: by admin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki