Refering to the refernece manual:
Tx queue operation is configured by programming FDCAN_TXBC.TFQM to 1. Messages
stored in the Tx queue are transmitted starting with the message with the lowest message
ID (highest priority). **In case that multiple queue buffers are configured with the same
message ID, the queue buffer with the lowest buffer number is transmitted first**
Tx FIFO operation is configured by programming FDCAN_TXBC.TFQM to 0. Messages
stored in the Tx FIFO are transmitted starting with the message referenced by the get index
FDCAN_TXFQS.TFGI. After each transmission the get index is incremented cyclically until
the Tx FIFO is empty. The Tx FIFO enables transmission of messages with the same
message ID from different Tx buffers in the order these messages have been written to the
Tx FIFO
The issue will be cancelation:
The FDCAN supports transmit cancellation. To cancel a requested transmission from a
dedicated Tx buffer or a Tx queue buffer the Host has to write a 1 to the corresponding bit
position (= number of Tx buffer) of register FDCAN_TXBCR. Transmit cancellation is not
intended for Tx FIFO operation.
But there is nothing preventing it. This seems to indicate it will
work. When a transmission request for the Tx buffer referenced by the get index is canceled, the
get index is incremented to the next Tx buffer with pending transmission request and the Tx
FIFO free level is recalculated. When transmission cancellation is applied to any other Tx
buffer, the get index and the FIFO free level remain unchanged.
Supporting direct down loads from ROMFS with preferece give to the
files fould on the SD card first. This will allow a user to provide
an updated uavcan firware on the SD card, and there is no overhead
of coping files from the ROM FS to the SD card.
This will ensure that the CRCs will match with deployed units to avoid unnecessary incompatibilities while we are figuring out how to best standardize these between stakeholders.
Add new DeviceBusType_SERIAL to Device::DeviceId union
Add DRV_DIST_DEVTYPE's for all distance sensors
Change distance_sensor_s.id to distance_sensor_s.device_id
Modify all distance_sensor drivers to apply 'proper' device_id
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
Adds automatic control of more light types via UAVCAN. Publishes
commands for beacon, strobe, nav, and landings lights. Each is
automatically controlled based on arming state and this behavior is
configurable per light type via params. For example, nav lights can be
set to be always on while beacons turn on when the system is prearmed
and strobes turn on only when armed.
Forwards messages on the gps_inject_data uORB topic as
uavcan::equipment::gnss::RTCMStream messages on the UAVCAN bus. This
enables differential/RTK GPS over UAVCAN to work.
Tested with CubePilot Cube Orange, Here+ base and Here3 rover.
Signed-off-by: Alex Mikhalev <alexmikhalevalex@gmail.com>
I observed stack overflows when executing `uavcan params list`, so the
stack size probably needs to be increased.
Signed-off-by: Alex Mikhalev <alexmikhalevalex@gmail.com>
- new sensors work item that subscribes to N x sensor_gps and publishes vehicle_gps_position
- blending is now configurable with SENS_GPS_MASK and SENS_GPS_TAU
Co-authored-by: Jacob Crabill <jacob@volans-i.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Peter van der Perk