mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-09-24 10:58:09 +08:00
39eae27610
* fix(uavcan): apply UAVCAN_BITRATE on FlexCAN again58dfff0de7turned the SIOCSCANBITRATE path off for i.MX RT, S32K and Kinetis, which is every board in the tree that builds SocketCAN, so UAVCAN_BITRATE stopped doing anything at all. It was written beforedb6f7ec304, and the crash it works around is that commit's bug: the driver reports bit/s on NuttX 12 and the caller still divided by 1000, so a 1 Mbit/s board asked its controller for 1000 bit/s on every boot. Benched on an ARK FMU-v6XRT with the gate removed: 1 Mbit/s -> 500 kbit/s -> 1 Mbit/s round-trips with both DroneCAN nodes coming back OPERAT, buses error-active, no fault. Requesting a rate the controller cannot reach is also survivable now -- it is reported and the configured rate is kept, where before a negative return from here made CanDriver::init() give up and DroneCAN never started. The %u for a uint32_t is fixed as well; nothing compiled this branch while the gate was in place. * fix(work_queue): size the uavcan and TTY work queues for NuttX 12 NuttX 12.12 costs a few hundred bytes of stack on the paths that go through the file layer, and that is more than these two defaults left spare. Measured against the same PX4 tree on 10.3.0: wq:uavcan 2860/3728 -> 3184/3736 (ARK FMU-v6X, two DroneCAN GNSS nodes) wq:ttyS4 1088/1704 -> 1432/1712 (ARK FMU-v6XRT, crsf_rc) load_mon reports wq:ttyS4 low on stack with 280 bytes left, and wq:uavcan sits at 85 % of its own. 4096 and 2048 restore the margin the 10.3.0 figures had.