-
Notifications
You must be signed in to change notification settings - Fork 1
USB Interface
The protocol used for communication between the client computer and the comms board is a simplified version of the main CAN Protocol. The main change is the removal of the from address. So packets from the computer to the comm board consist of the destination address, the command, any required data and finally a 0xFF byte as a terminator. The comms board then only replies if the command was a get request and simply replies with the data requested.
A very simple proof of concept client was written in Python. This consisted of
the files
client.py
and
definitions.py
.
The main loop of client.py retrieves a line of input from stdin and, using definitions.py to
convert the line to a packet, sends the packet over the usb link. If the
packet was a get request it then waits on a reply and prints it out.
On the Kart side the USB interface is mainly based on the USB Device CDC Serial project from the AT91SAM7X-EK Software Package. The USB client appears as a Serial device when an appropriate driver is installed (available from mariokart/Software/lib/usb/device/cdc-serial/drv/6119.inf
for Windows, in-built on most unices however we were unable to get it working on OS X). Any data input to the USB pseudo-serial device is forwarded on to the UART and any data from the UART is forwarded to the USB device.
From this starting point it was simple to remove the extraneous code and develop a module, (src/comms/usb.c
), to read the messages from the USB device and translate these into the messages required by the rest of the code, as well as taking data to be sent back to the host computer and doing that translation.
The current USB protocol is really only fit for the proof of concept application. The largest problem with it is the 0xFF message terminator, as the final bytes of the transfer are the data packets it is entirely possible that they should contain an 0xFF byte.
Once a better protocol has been devised the first step should be to create a library that encapsulates the communications, just providing mid level operations such as kart_set_accel(unsigned int)
to set the accelerator position and performing the translation into an appropriate message for the CAN bus.
Once a medium level library has been created a higher level library would be very helpful. This could provide operations such as kart_set_speed(unsigned int)
that takes in a speed and performs PID control on the host PC using the speed sensor and the accelerator and brake settings. This would make developing example applications a lot easier.