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>
* X7Pro adds CAN driver
* UAVCAN timer selection moved to default.cmake
* Modify some details about @CUAVcaijie UAVCAN timer selection moved to default.cmake
* Put some timer parameters to micro_hal.h from board_config.h. Fix all h7 boards
Co-authored-by: honglang <honglang@cuav.net>
Took the existing uavcan_stm32 driver and replaced all bxCAN code with
the equivalent for FDCAN following ST Reference Manual RM0433.
Note: There is still a bug somewhere in regards to FDCAN2 (probably
incorrect setup of the message RAM? Not sure.) But (FD)CAN1 is fully
functional (Classic CAN only, no CAN-FD).
Also TODO: Configure CAN filters. Right now there are no filters; all
incoming messages are accepted.
- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
This moves the handling of the BAT%d_SOURCE param inside of the battery
library. Users of the library now pass the source instead of the flag
whether to publish. The battery library then checks if the source is
selected using the param and publishes accordingly.
Since we removed the strange system_source flag, we now need to look at
all batteries in commander.
For current estimation - I think - it makes sense to sum them up.
CUAVmengxiao