Controls Software
If you are getting started on development for the Controls system, please take a look at Setting up an Embedded Development Environment.
Structure
Files 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 |
Other:
- The Initialization task starts up all necessary tasks on the system, and then dies.
- 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
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) |
Environment
Currently, the Controls system is using the Micrium µCOS-III (pronounced micro-C OS three) as its Real Time Operating System. (documentation)
The Controls system runs on our Controls Leaderboard, which includes a STM32F413 processor. (documentation)
For low-level operation below the BSP, we utilize the Standard Peripheral Library provided by ST Microelectronics.
Welcome to the University Wiki Service! Please use your IID (yourEID@eid.utexas.edu) when prompted for your email address during login or click here to enter your EID. If you are experiencing any issues loading content on pages, please try these steps to clear your browser cache.