If you are getting started on development for the Controls system, please take a look at Setting up an Embedded Development Environment.
Structure
Applications
We currently host six critical RTOS tasksFiles in the Controls code base are split into three main groups: Board Support Package (BSP) Drivers, Device Drivers, and Applications. These layers enable us to separate low-level implementation details (such as specific peripheral initialization) from higher-level details (cruise control code, for example).
Applications
The apps layer sits atop the other two layers, making calls to driver code and operating system code in order to implement necessary logic for the function of the car. This code is divided into separate, independent tasks, each of which controls a certain aspect of the car.
Application | Description |
---|---|
SendTritium | the main task of our Finite State Machine which sends control commands to the Tritium Wavesculptor 22, our motor controller |
ReadTritium | reads feedback from our motor controller, watches for motor controller faults, and records velocity data |
SendCarCAN | contains a CarCAN queue that other applications can post to in order to send information across CarCAN, mostly for telemetry purposes |
PutIOState | currently a separate application that lives inside SendCarCAN, whose purpose is primarily to put the IO_STATE CAN message on the bus. This is subject to change. |
ReadCarCAN | reads feedback from the CarCAN bus and controls the car's ignition & precharge sequence |
UpdateDisplay | contains a display queue and several methods that other applications can call to update information on our Nextion display |
...
- The Debug Dump and Command Line tasks currently serve as purely debugging tasks and may be useful during competition (not to be used on the final vehicle).
Device Drivers
We also have five device drivers.The device drivers layer sits right above the BSP. Its job is to provide the hardware interface for all of our higher level code. This includes implementing device-specific behavior over the peripherals provided by the BSP, and in general aids in reducing the complexity of the application layer.
Device Driver | Description |
---|---|
CANbus | mutex-protects and adds semaphores for each CAN line to record the number of open mailboxes, provides an interface for Apps to use the CANbus, uses the CAN Lookup Table described in CANLUT.c |
Contactors | provides an interface to control precharge via the Array Precharge Bypass Contactor and Motor Precharge Bypass Contactor |
Display | provides an interface to control & send messages to the display |
Minions | provides an interface to control the lights and read the physical switches/buttons on the car |
Pedals | provides an interface to read the pedals |
BSP (Board Support Package)
...
The board support package is our lowest abstraction layer. Its job is to hide away microcontroller specific initialization code, and present an interface to built-in peripherals.
BSP Driver | Description |
---|---|
BSP_ADC | read the Analog to Digital Converter |
BSP_CAN | read/write on the CAN bus |
BSP_GPIO | read/write digital values from pins on the processor |
BSP_UART | read/write to UART (Universal Asynchronous Receiver/Transmitter) |
BSP_SPI (unused) | read/write to SPI (Serial Peripheral Interface) |
...