...

• We have multiple hardware libraries that handle interactions with the hardware, including GPIO, PWM, ADCs, and GPIO interrupts.

• Our schematics are primarily stored on GitHub Altium 365 at https://github.com/uw-midsun/hardwareuniversity-of-waterloo-solar-car-team.365.altium.com; slack Ryan Dancy to get added

• You have to look at the schematic to understand how to talk to an integrated circuit (what pins do what)

• You need to look at the datasheet of a integrated circuit to understand how to use it (what commands do what)

• We write driver programs to talk to integrated circuits

...

For example code on using SPI, check out the ‘smoke_spi’ project: https://github.com/uw-midsun/firmware_xiv/blob/master/projects/smoke_spi/src/main.c

Although the SPI protocol is universal (ish), ICs tend to implement their own set of commands to use. Again going back to our MPPTs as an example:

...

This is all fine and good, but it could get pretty annoying to pack the right values into the right places every time you want to send a message, especially if you’re mixing data types like having two uint16_ts and one uint32_t. To facilitate this, we use something called code generation.

Code Generation

We actually define all our CAN messages in a separate repo called codegen-tooling-msxivthe codegen/can_messages.asciipb file, found here: https://github.com/uw-midsun/codegen-tooling-msxivfirmware_xiv/blob/master/codegen/can_messages.asciipb. Have a quick look at this file. In general, we define messages similar to the following:

...

Once we have these definitions, we generate CAN_TRANSMIT, CAN_PACK, and CAN_UNPACK functions for every message. For detailed instructions on generating To generate these messages you can check the repo README, or , just use make codegen. Also see this writeup: Codegen Tooling.

Once the code is generated, it’s placed in the firmware_xiv repo under libraries/codegen-tooling/inc. Here’s the definitions generated from the above example:

...