Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Background

This is an EFS & EE collaboration project, EE makes the board, and EFS writes the firmware for it. The final application of this Servo CAN adopter board is to control the flap wings, elevators, and rudders on a fixed-wing aircraft. To make that happen, EFS needs to work on firmware that converts the CAN servo control command transmitted from the flight controller to the PWM signal that servo motors understand.

The development of this project takes place on three different platforms:

  1. STM32 L5 Nucleo board - https://os.mbed.com/platforms/ST-Nucleo-L552ZE-Q/

  2. Single Servo Module - Single Servo Driver

  3. 6s Servo Module - 6S Servo Module Rev 1

The single servo module has the same CAN circuit and the same STM chip installed as the ones on the 6s Servo Module. So there will be a large overlap on the firmware of the two. 6s Servo Module has external facilities for voltage sensing and more Neopixel LEDs.

Nucleo L5 was mainly used for the project prototype before the PCB boards were ready. This is also the first platform that we got fully working firmware logic. The big difference between the STM32 L5 and STM32 L4 (the MCU used on the PCBs) is that they support slightly different versions of CAN. STM32 L5 uses CANFD which is a newer CAN protocol allowing a faster rate of CAN message transactions. Whereas, STM32 L4 uses normal CAN that is sufficient for running DroneCAN.

The branch that has a functioning Servo CAN firmware: https://github.com/UWARG/efs-can-servo/tree/cleaner_repo

CAN Transmit Logic on Nucleo L5

X_Hz Frequency Task: This is the task that runs at a certain frequency in our program. This type of task can send the node or servo status. The message you want to send will be added to a TX queue instead of transmitted right away. Due to the nature of the CAN protocol, one node is only allowed to transmit a message when the bus is idle.

Main Loop: We call processCanardTxQueue to attempt a transmission. If the CAN bus is busy, that is fine. We can try again in the next iteration. The message will be sent to the CAN bus when the transmission succeeds.

CAN Receive Logic on Nucleo L5

CAN Filter: This is the identifier filter for the message on the CAN bus. It examines the identifier of every CAN message it receives and rejects the message that violates the configuration. The filter can be configured by changing the fields in FDCAN_FiltertypeDef.

https://controllerstech.com/fdcan-normal-mode-stm32/

FIFO Callback: This overrides the STM32 HAL callback functions and is triggered when a valid CAN message is captured.

Should Accept & On Reception: These are the functions passed to a Canard instance when it is created. should_accept is another filter for the message on their DroneCAN data type. on_reception takes the custom action to handle the received DroneCAN message.

CAN Circuit

This is how you want to set up the circuit to test your CAN node firmware with a Nucleo board. Using a PCB can be easier because they have the CAN transceiver circuit on board.

  • No labels