uavcan: statically allocate memory pool

[dakejahl]

Solved Problem

The uavcan drivers allocate memory from the heap. This can cause memory allocations during run time if the RX/TX queues are not serviced quickly enough. This can result in system jitter. In general we have a policy of not allocating memory after init.

Solution

Statically allocate the uavcan memory pool. The HeapBasedPoolAllocator implementation seems to come from a time when RAM constraints were an ongoing battle (like flash is today). Modern flight controller designs use STM32H7 which has plenty of RAM (1MB).

Changelog Entry

For release notes:

uavcan: statically allocate memory pool

Test coverage

FC: ARK FPV
CANnode: ARK Mosaic GPS

Context

I implemented high rate data streaming via uavcan.tunnel on the ARK Mosaic GPS and noticed the CAN bus appears to choke resulting in sporadic CAN frame loss. This was occuring in conjunction with memory allocations to increase the CAN TX queue size.

[dagar]

This isn't static allocation, it's a fixed size pool allocator vs one that can grow. If you can't allocate from the pool the CAN frames will be dropped.

If we're going to consider this we first need to get a handle on existing HeapBasedPoolAllocator usage or have this as entirely different option through kconfig.

Given the huge range of potential UAVCAN I don't see how we could size this properly unless it's more directly based on enabled publishers with some understanding of max output data rate.

[dakejahl]

Yes not statically technically statically allocated but effectively statically allocated. Allocated once during init and is a fixed size known at compile time.

And yeah we need to add this to KConfig so we can define the pool size per target, even better if it's a function of the enabled publishers/subscribers and their expected rates.