Description

There are a number of useful extensions for working with STM32s in VS Code. .vscode/extensions.json should have the following (and any other useful extensions):

{
  "recommendations": [
    "ms-vscode.cpptools-extension-pack",
    "ms-vscode.makefile-tools",
    "ms-vscode.vscode-embedded-tools",
    "marus25.cortex-debug",
    "dan-c-underwood.arm"
  ]
}

Description

In can_publisher.c we currently make can data example of [0,1,2,3,4…]but change this to read from local file

Description

Integrate with new version of can-defs submodule

Requirements

Update can-defs submodule to release: v0.0.5 :

• Assign PDU Id's which are now specified in handler's table
• Use new table size macro

Description

Create config.h to implement two modes of operation: DEBUG and NORMAL mode. DEBUG mode will read data from LUT (#7) and NORMAL mode will use CAN interface (#8).

Requirements

• config.h contain definitions of two modes
• Source files must take in account the mode to compile the right piece of code

Note

This should be done after completion of #8 and #7

Description

The telemetry PCB (sufst/pcb) includes a MAX6958BAEE+T LED display driver which will drive a dual 7-segment display on the dashboard which is intended to show the state of charge of the accumulator. Since the on-car telemetry system will be located close to the dash and monitors all CAN bus traffic, it makes sense to use this microcontroller to control the display. The state of charge should be displayed as a 2-digit percentage.

Additional Notes

Rough outline for implementation:

• Low priority thread running in the MCU which subscribes to RTCAN notifications from the BMS for its state of charge.
• When a CAN message is received, a command should be sent to the display driver (controlled by I2C) to update the displayed value.
• Since the BMS diagnostics are on the CAN-S bus, this will rely on #17.
• If data is not received from the BMS after some period (e.g. 10s), there should be some indication of this error on the display.

Description

The intermediate server requires the XBee's to be configured in API mode. At the moment (for testing), the XBees are configured to operate in transparent mode. Since transparent mode has been shown to work in testing, we can now take the next step to running in API mode.

Additional Notes

This will require the STM32 port of the XBee library in https://github.com/sufst/xbee_ansic_library to be finished / tested.

Description

.cortex-debug.peripherals.state.json and .cortex-debug.registers.state.json in the .vscode folder shouldn't be under version control and should be added to the .gitignore.

Description

RTCAN handler functions need to be called in the HAL CAN callbacks, otherwise the RTCAN service will not function at all. Refer to the usage instructions in the RTCAN README for how to do this.

Expected Behaviour

RTCAN handler functions are called in the HAL CAN callbacks.

Description

Thread should meet the requirements of GPS Module Hardware.

Requirements

• Data packing into pdu telemetry message and sending together via UART/SPI with other CAN messages.
• Data logging as a CAN message.

Description

Add some simple runtime profiling to gather information on:

• Received CAN messages (count).
• Received CAN data (bits/s over some recent time period).
• Transmitted telemetry PDUs (count).
• Transmitted telemetry PDU data (bits/s over some recent time period).

Received CAN data could be calculated by summing DLCs of received CAN messages. Transmitted data could be calculated by summing the size of the packed PDU data for each PDU transmitted. In both cases, it might be good to add the header size to the calculation too.

This information should allow us to determine how much of the wireless bandwidth we are using.

Future Work

As a future development, this information could then be broadcast periodically on the CAN-S (non critical systems) bus for logging by the datalogger.

Description

The current implementation works for one CAN bus, but we have two (one for critical systems and one for sensors/non-critical stuff). We will need to extend the system to have a second RTCAN instance, and a second CAN database (from the can-defs repo, which will also need some changes).

Additional Notes

• One possible way to do this would be to have a second instance of RTCAN and a second unpacking thread. This way, the implementation doesn't have to change much other than providing each unpacking thread with a different database.
• This will require a new way of defining PDU IDs. If we have two CAN databases (one for each bus), using the ID in the look-up table as we are now will result in two PDUs with the same ID. We will need a way of including the PDU identifier in the handlers table.

Description

Write some key information in the README such as:

• Purpose of this project.
• Build instructions.
• Any useful resources.
• Related projects (can-defs, rtcan, intermediate-server).

Description

Implement error handling in can_unpack thread. This might be implemented by putting the device into an infinite loop and setting the on-board LED. Different error codes might be distinguished by different periods/scheme of LED blinking.

Description

Add rtcan integration. Replace can_publisher thread by can_id subscription issued in rtcan.