Communications Protocol

In order to allow communications between the robot and a control computer (a PC in the first instance and a Palm Pilot in the final piece), a protocol was devised.

Early on, it became apparent that it would be limiting and require a lot of unnecessary work to devise a system which would only allow specific commands to be sent to specific parts od a specific PIC project. The decision was made to devise a protocol which would allow any RAM address in the PIC to be modified via its USART port. IMP (Inspection and Modification Protocol) was born. As a side effect, it can also be used to inspect and modify the SFRs and plans are afoot to investigate mechanisms to directly address any EEPROM which maybe available.

To start a "conversation", the control computer might send any (or all) of the following commands to the PIC:
  • set bank
  • set address
  • set bit index
  • set value (low byte)
  • set value (high byte)
This causes some internal registers to be set in the PIC which hold the bank, address and value, etc. of the bit or byte (or word!) about to be inspected or modified. One these registers are set, they remain set, so if all of the RAM to be accessed is known to be in bank 0, the PIC only needs to be told "set bank 0" once. Likewise, if only one RAM location ever needs modified, it only nees to be told "set address nn" once.

It then follows with one of:
  • modify bit
  • inspect bit
  • modify byte
  • inspect byte
  • modify word
  • inspect word
which causes the information given in the first phase to be used to inspect or modify a location.

Of course, the textual names of the commands given are not actually sent on the serial port: each of the above has a corresponding byte, so each command is actually only one byte in size. NB each item in the first list above also requires a data byte to be sent.

By way of verification, each command byte sent to the PIC is echoed after it has been executed. this means the PIC does not require a software receive buffer, but that the host is responsible for ensuring that no data byte is sent until the echo from the previous has been received.

No comments: