More progress has happened already!! I managed to get a basic comms protocol up and running to allow a flexible command structure for accessing the PIC's debug functions. The comms protocol makes considerable use of the 18F's additional commands and indirect addressing, and is quite generous with RAM since the 4520 version has 1.5KB available.
There is a simple syntax for commands:
|0||Command||The command code|
|1||Data Length||The length of any data in the packet. Can be 0 if there is no data. Data length is limited to 253 bytes so that a whole packet (Command, Length, Data and Checksum) add up to 256 bytes.|
|[n-m]||Data||The actual data payload of the command. Can be zero length if specified earlier. There is no restriction on byte values in this data section.|
|m+1||Checksum||An XOR checksum of all bytes in the data packet (excluding the checksum itself of course.)|
So the shortest valid command could for example be "A\0A" (using C syntax) where the command code is "A" and the checksum of "A" xor "\0" is obviously also "A".
The response to these commands follows a similar structure;
|0||Command||The command code this response belongs to (e.g. "A"). If this is an error report then the lower case letter is used or an ascii numeral (0-9) for special error responses.|
|1||Length||The length of the data payload. For a normal acknowledge message it may be zero. In case of an error it is at least 2 as there is always an error code with an error response.|
|[n-m]||Data||Can be any string of bytes up to 253 bytes long that matches the length specified earlier. If the response is an error report the length is at least 2 and the first two bytes form a 16-bit error number (see below).|
|m+1||Checksum||The XOR checksum of the packet including all headers and data|
So if the response to the command is simply an acknowledge, the response would be something like "A\0A" for example.
As it says above an error response is a special case. Generally an error report to a command is started by the lowercase letter to signify an error. However in two cases (so far) the command letter is uncertain or unsafe so a number is used. A "0" character is sent at the start of a packet when the checksum is invalid as the error may be in the command character and would result in unpredictable response messages. A "1" character is sent if the command sent was not in the range "A-Z" since the maths to swap it to a lower case could produce a non-eight bit value if it is not an upper case character.
In all error messages the data packet is at least 2 bytes long and the first two bytes are a big-endian 16bit error code. This can then be followed by other data that may be helpful in debugging the error, but the additional data is dependant on the command and error. The error codes are laid out below.
|1||Checksum Error||The calculated checksum|
|2||Bad Command (not in range [A-Z])||The value of the command character|
|3||Unused Command (in range [A-Z] but not used)||None|
All this is working so far, however none of the commands are implemented so they all respond with "Unused Command" error (0x0003). Checksum error and bad command detection is functioning correctly.
|pic_master_serial_protocol.asm_.txt||April 23, 2014, 9:06 p.m.||25.0 KB|