\uD83D\uDCD8 Background
For MSXIV, MS16 we use a Super Loop architecture for driving super loop architecture to drive all data transitions through each project. Each controller board has 3 cycle speeds it can transmit and receive at. Our receiving is ISR based and transmitting depends on the CAN TX Mailbox. We also autogenerate rx_structs and tx_structs to hold all messages using YAML files for each project.
Ex: Pedal PoardBMS Carrier
...
It begins with the initialization of all storages storage and modules. Next, the super loop , does 2 things, event_process, to grab the first event and then pass that event to can_process_event
...
event_process essentially loops through 5 fifos and returns the first highest priority event. The current CAN implementation is joined within this, meaning CAN messages are raise as events to process.
CAN Receiving:
...
In libraries/ms-common/src/can.c all incoming CAN messages trigger an interrupt and the messages is added to the can_storage->rx_info and an event_raise raises a CAN event, which needs to be propagated back up to the global event fifos and then processed through can_process_event. So the cycle is thisis really simple to implement! TLDR: All we do is call run_can_rx_cycle() and run_can_tx_cycle() and our rx_structs are updated, and tx_structs are transmitted onto the bus. run_can_rx_cycle() and run_can_tx_cycle() notify CAN_RX and CAN_TX tasks. CAN_RX will flush the rx_queue and update the rx_structs based on the message raw ID. CAN_TX will similarly go through the entire tx_struct and transmit the respective messages. It will then check all CAN watchdogs, which are autogenerated variables that are incremented each time a message is not received and reset when it is.
...
CAN Receiving:
...
All incoming CAN messages trigger an interrupt USB_LP_CAN1_RX0_IRQHandler() or USB_LP_CAN1_RX1_IRQHandler() which calls on can_hw_receive, fetching all the data. Within the ISR, we compare the current CAN ID with the CAN filter IDs. If the message is not in the filter, we then push the CAN message to the global rx_queue. The data now waits in the queue to be popped an used, typically by the CAN_RX task.
Incoming CAN msg → CAN Receive ISR → raise Filter CAN event → parse through event_process super loop → can_process_event → look in CAN storage for msg → call specific can_rx_handler And most often what happens is that the can_rx_handler will raise another event going through the entire cycle again to tell other processes what to do.IDs → Push message to rx_queue → Pop message from rx_queue for access
CAN Transmit:
...
can_hw_transmituses the STM32’s mailbox to transmit messages. A mailbox is basically a hardware storage unit, and for CAN TX, the mailbox also schedules out transmissions. We attempt 3 times to transmit the given message, but if the mailbox is full, then it suggests that CAN is not connected or another underlying issue exists in the TX process.
\uD83C\uDF08 Options considered
Proposal: Redesign CAN architecture to be main clock of system, since its the main mode of communication between different boards of the car.
...