software_behav
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| software_behav [2017/06/05 17:01] – [Required functionalities] admin | software_behav [2017/06/06 11:20] (current) – [Commands Core Set] admin | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =====ANT protocol features===== | + | ======ANT protocol features====== |
| - | ====General Specifications==== | + | =====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. | 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. | ||
| Line 54: | Line 54: | ||
| 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. | 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=== | + | ====System Commands==== |
| - | == Commands for writing/ | + | === Commands for writing/ |
| When accessing registers, IO space and RAM through a command, it makes no sense to worry about efficiency in access. | When accessing registers, IO space and RAM through a command, it makes no sense to worry about efficiency in access. | ||
| Line 64: | Line 64: | ||
| In order to "keep it simple" | In order to "keep it simple" | ||
| - | Therefore we may define the following commands: | + | Therefore we may define the following commands |
| ^MNEM^Description^byte1^byte2^byte3^byte4^byte5^ | ^MNEM^Description^byte1^byte2^byte3^byte4^byte5^ | ||
| Line 71: | Line 71: | ||
| |**WP0M**|Write into page 0 with mask |5|cc|ADD|VAL|MASK| | |**WP0M**|Write into page 0 with mask |5|cc|ADD|VAL|MASK| | ||
| |**WRAM**|Wrte into RAM |5|cc|ADD H| ADD L| VAL| | |**WRAM**|Wrte into RAM |5|cc|ADD 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 ones unchanged. The WPOM routine will first read the contents of the | ||
| + | register at (RAM) location ADD, will " | ||
| + | |||
| + | Response message might contain the actual value written to ADD instead of VAL. | ||
| + | |||
| + | |||
| + | **WRAM** | ||
| + | |||
| + | Writes VAL into the memory location ADD_H: | ||
| + | |||
| + | Response can simply be the same as the transmitted string that is therefore used as as sort of acknowledge (for non time sensitive applications). | ||
| + | |||
| + | ===Commands for reading and modifying the flash=== | ||
| + | |||
| + | 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 " | ||
| + | |||
| + | 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. | ||
| + | |||
| + | ^MNEM^Description^byte1^byte2^byte3^byte4^byte5^byte6^ | ||
| + | |**FLRW**|Read a Flash word|4|cc|ADD H|ADD L | | | | ||
| + | |**FLCP**|Make a temp copy of a flash page|4|cc|ADD H|ADD L | | | | ||
| + | |**FLWW**|Flash write word |6|cc|ADD H|ADD L|VAL H | VAL_L| | ||
| + | |**FLPG**|Program Flash |4|cc|ADD H|ADD L| | | | ||
| + | |||
| + | **FLRW** | ||
| + | Reads a program word. The address is (ADD_H: | ||
| + | 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' | ||
| + | No answer is really needed, a simple " | ||
| + | |||
| + | **FLPG** | ||
| + | Issue the command for programming flash. | ||
| + | Once again, a simple " | ||
| + | |||
| + | |||
| + | 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: | ||
| + | |||
| + | |||
| + | |||
| + | ===Commands for reading and modifying EEPROM === | ||
| + | |||
| + | Most of the operations required for reading and writing the EEPROM can be accomplished by reading/ | ||
| + | |||
| + | 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. | ||
| + | |||
| + | ^MNEM^Description^byte1^byte2^byte3^byte4^byte5^byte6^ | ||
| + | |**EERB**|Read a byte from EEPROM |4|cc|ADD H|ADD L | | | | ||
| + | |**EEWB**|Write a byte to EEPROM |5|cc|ADD H|ADD L |VAL | | | ||
| + | |||
| + | |||
| + | ==== Commands Core Set ==== | ||
| + | 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**, | ||
| + | |||
| + | |||
| + | 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), | ||
| + | |||
software_behav.1496682090.txt.gz · Last modified: by admin
