TIVA-PIC Communication on WHA:LE using SPI


Division among the PIC and the TIVA on the WHA:LE

  • The complexity of handling communication with the Goggle, the deciding of “itness” and controlling the audio board will be handled by the PIC.
  • The tasks of controlling the drive motors, bump sensors, ultrasound sensors and servo motors will be handled by the TIVA.
  • The TIVA will constantly update the PIC with the readings of its Ultrasound sensors and bump sensors, and the PIC will relay commands for the DC of the left and right motors and direction of motors (HI if backwards), long with the status of the bot (paired or not, it or not, singing or not).


Protocol

  • TIVA will act as Master, PIC as slave.
  • Each data packet will be 4 bytes long.
  • To start a message packet, the TIVA will send out an init message 0x55, to which the PIC will reply 0x5; if the PIC does not reply with this then the TIVA will resend 0x55 till it receives the appropriate response.


  • Message packet from TIVA to PIC:
    • First Byte sent: 0x55 (for sync between the 4 bytes, as the data bytes themselves have no identifier in them)
    • Second Byte sent: 0x55 (as prev PIC message would not have been 0x55)
    • Third Byte sent: Left-Right Ultrasound Info (MS 4 bits) + Bumper Status (LS 4 bits)
    • Fourth Byte sent: Front-Rear Ultrasound Info (8 bits)
  • Message packet from PIC to TIVA:
    • First Byte sent : 0x55 (in response to the 0x55 just received from the TIVA)
    • Second Byte sent: 0x55 (in response to the 0x55 just received from the TIVA)
    • Third Byte sent: Right Motor Duty Cycle (MS 7 bits) + Right Motor backwards(1 bit)
    • Fourth Byte sent: Left Motor Duty Cycle (MS 7 bits) + Left Motor backwards (1 bit)
    • As we transmit the magnitude as a 7 bit number and the incoming message from the Goggle according to the Communication Protocol denotes speed in the range of 0-127, no complicated scaling of message from Goggle required when passing through PIC.


  • If the TIVA ever receives 0x0000 or loses connection with the PIC, (in which case it behaves as though it received 0x0000) then it turns off motors and speakers.


Choosing update rate for information between TIVA and PIC

Initially we chose a baud rate of 200,000, which is greater than 20x baud rate that the PIC will communicate with the XBee.

9600 baud for the wireless communication corresponding to approx. 1 byte transferred every 0.8 milliseconds; 200,000 baud for the SPI which corresponds to around 1 byte every 0.04 ms.

We initially thought that an ideal update rate would be 3-4x faster than wireless transfer (as we will be using an event checker which is inherently not perfectly periodic, and will send 3 SPI messages for each UART Status message) but much slower than the SPI transfer rate; hence we choose a rate of initiating a transfer every 0.2 ms.

This would be a good choice for when Whale and Goggle exchange information almost continuously; however, in our case this only happens every 200ms and so this is way over kill.

In fact due to the imperfect timing of other systems, this almost constant transfer resulted in the status and control messages that had to travel between WHA:LE and PIC to maintain pairing not getting processed in time and hence a loss of pairing.

We therefore decreased the baud rate to around 10,000 baud resulting in an improvement in our Whale-Goggle communications.


Wireless Communications Protocol

ME218C1819CommsProtocolrev1.1.pdf