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.

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.

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):

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 ones 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 same as the transmitted string that is therefore used as as sort of acknowledge (for non time sensitive applications).

The commands for modifying the flash are at the core of ANT and there are a number of possibility for their implementation. In the prospect of defining some “core” commands to be available both in the tiny2313 and mega328 we define only the minimum set of commands. In particular, when filling out the page buffer prior to programming, the MNC will only be able to send one word at the time.

Flash programming occurs in this fashion:

• the content of a page (16 words for tiny2313 and 64 words fot mega328) is prepared in a buffer
• when ready, the entire page is programmed.

In order to allow the possibility of altering one single flash word one can proceed as follows:

• a copy of the page is made in the internal buffer;
• the words that need to be modified are modified;
• the page is programmed.

In order to accomplish this goal (and also read program memory) we can define the following commands.

FLRW Reads a program word. The address is (ADD_H:ADD_L)AND(0xFFFE). Word value can be returned in the answer in place of the address.

FLCP Copy a flash page into the internal temporary buffer. The page address is that of the page to which the location specified by ADD_H:ADD_L belongs. Answer could be the address page in the proper format.

FLWW Writes a word in the temporary buffer. Note that proper care should be paid in addressing, according to the precautions (see devices' Data Sheets) required to avoid corruption of the temporary buffer. No answer is really needed, a simple “1” would suffice as a sort of “done, send another command” acknowledgement.

FLPG Issue the command for programming flash. Once again, a simple “1” is sufficient in the answer as acknowledgement.

N.B.: In principle, the command FLCP is not strictly required. One can read the content of a flash page using FLRW and write the value in the proper location via FLWW. When programming a large number of flash pages, the time required for communication becomes significant: FLRW require at east 8 ms (transmission of 4 bytes, reception of 4 bytes). FLWW requires at least 7 ms (transmission of 6 bytes and acknowledgment reception) for a total of 15 ms. Reading/Writing 1k-words will therefore require at least 15 seconds. Using FLCP the overall time reduces to about 7 seconds.

Most of the operations required for reading and writing the EEPROM can be accomplished by reading/writing IO registers through the proper command (seeding address, seeting data for write). However actual writing requires a sequence of operation that can only managed by a aproper sequence of code (“arming” the writing mechanism and issuing the writing command within four clock cycles).

Therefore a dedicated command for writing is required, while reading can be accomplished to the data writing commands. However, we can define a specific command for EEPROM reading.

Command core set is the minimum sets of commands that need to be implemented and whose action cannot be replicated with a combinations of other commands in the same set.

As we have note before, for instance, the FLCP command, while useful, is not a core command: we can obtain the same effect by using a series of FLRW and FLWW.

At this stage, the commands that appear to belong to the core set are:

RRAM,WRAM,FLRW,FLWW,FLPG and EEWB;

This means that the minimum length for the CVT should be 16, with a margin for two more core system command (in case we realize we have forgotten something) and a set of 7 user comments.

The other commands listed so far (RPG0, WP0M, FLCP and EERB) can be included in the immediate super-set (len(CVT)=32) together with other commands for ase of use.

The target should be, however, to start in any case with the core command set ( from now on CMN_LVL_0) and to obtain reconfiguration toward richer command sets using the core command set. In short, we should insure that once a SNC is programmed with the core command set (with an external programmer), it can be upgraded by the MNC through ANT.