[SOFT 421] Transmit motor temp

[YiJie-Zhu]

Half-finished code for transmitting motor temperature through CAN.

[hewittmcg]

Thanks for taking the time to work on finishing this, Frank! It looks good overall, and I like the idea of moving the temperature checking logic into its own module. Some of my comments are minor issues -- the general important things are:

• Make sure to write unit tests so that we know the module is working as expected. These will likely be similar to the ones in test_mci_broadcast.c, so you can use that as a reference.
• Change how the messages get received from the motor controllers so that the handling functions get called from mci_broadcast.c.
• Figure out a way to differentiate between the different temperature readings when broadcasting over CAN so that we can easily process them when we receive a SYSTEM_CAN_MESSAGE_MOTOR_TEMPS message

I mentioned the possibility of moving things into mci_broadcast.c, but that's only if it makes life easier for you 😃

[hewittmcg]

We don't actually use generic CAN for this (anymore). Instead, there's a function in mci_broadcast.c, prv_process_rx, that routes the messages we get from the WaveSculptor to the correct handling function.

There are stubs to handle motor temperature measurements in mci_broadcast.c already: prv_handle_motor_temp_rx and prv_handle_dsp_temp_rx. You can use these by making prv_handle_dsp_temperature_rx and prv_handle_sink_temperature_rx public and either:

• Calling them from the above mci_broadcast.c functions directly, or
• Removing the above mci_broadcast.c functions, and updating the s_cb_storage array to point to your functions instead.

The second option is a bit cleaner, but it's your call.

Note that this probably makes unit testing a bit annoying to get working, so you might want to move everything into mci_broadcast.c similar to how we handle velocity/status/bus measurements already. Then you can just update the mci_broadcast unit tests to also check for temperature instead of having to write your own test sequence. This also comes with the advantage of being able to broadcast your measurements in the mci_broadcast.c prv_periodic_broadcast_tx instead of needing a separate function/soft timer.

[github-actions]

Uncommitted codegen changes detected!

It looks like the generated header files in libraries/codegen-tooling don't match the CAN message definition file at codegen/can_messages.asciipb. If you've changed the CAN message definitions, please run make codegen locally and push the changes.

Alternatively, maybe you've edited can_messages.asciipb in the codegen-tooling-msxiv repo. This has been deprecated: please make your changes to codegen/can_messages.asciipb instead.

[ryandancy]

Looks good to me! Will merge once @hewittmcg approves

[hewittmcg]

One really minor nitpick, LGTM otherwise!

[hewittmcg]

LGTM!