cubepilot / framework Goto Github PK

Currently, an array of 50 param pointers and keys are allocated whether or not they are used, using around 500 bytes of RAM. These lists could be dynamically allocated on setup.

Moving to C++ and using templates could help with this.

sizeof(struct can_tx_frame_s) is currently around 32 bytes. Reducing this will save significant amounts of RAM. A few ways:

• packed storage
• 16-bit milliseconds for creation time and timeout.
• 8-bit or 16-bit array index for the next pointer rather than a full 32-bit pointer
• split into 2 types: one that carries a payload, and one that carries ID and metadata.

reducing framework RAM usage:

• Current pubsub behavior that allows a slow listener to prevent the deallocation of a lot of stale messages is memory-inefficient.
  • Changing from a circular buffer to a heap would potentially allow stale messages that are not the oldest in the queue to be deallocated.
  • Messages deallocated automatically when the last listener finishes on it.
    • Accomplish this by keeping a listener count. When a message is allocated, it starts with a listener count equal to the number of active listeners on its topic. When listeners either finish on the topic or de-register, the count is decremented. When the count becomes zero, the message is deallocated.
  • Otherwise, keep everything the same?
  • NOTE: use chHeapGetSize instead of storing message size, saves 4 bytes overhead
• Current UAVCAN flow of CAN frame -> pubsub -> libcanard memory pool -> decode -> pubsub is memory-inefficient.
  • Decoded message is always maximum message size and usually there is only one subscriber for a given UAVCAN message. The UAVCAN message subscriber could decode the needed fields one at a time. Ideally one block of memory is used for assembling messages and for storing assembled messages for subscribers to read.
• No CAN acceptance filter is memory-inefficient
  • CAN frames that are not used are being put on pubsub
• UAVCAN is inherently memory-inefficient
  • A UAVCAN node theoretically requires a maximum of sum([size[msg_type]*num_transmitters_on_bus[msg_type] for msg_type in subscribed_msg_types]). If messages of a given type were required to be contiguous on the bus, it would be reduced to sum([size[msg_type] for msg_type in subscribed_msg_types]). If messages were simply required to be contiguous on the bus, it would be further reduced to just max([size[msg_type] for msg_type in subscribed_msg_types]).
    • This may require significant changes on the transmit-side of all UAVCAN nodes, to add re-transmit of interrupted messages.
• pubsub memory overhead
  • message header is: 4 bytes size, 4 bytes topic pointer, 4 bytes next message pointer, 4 bytes next message in topic pointer
  • could be: 2 bytes size, 2 bytes topic index, 2 bytes next message pointer as offset from topic group memory start, 2 bytes next message in topic pointer as offset from topic group memory start
  • if switching pubsub to heap, 6-byte overhead savings in implementing custom heap to eliminate the heap pointer in the block header and reduce size field to 16-bit
• See also #4 #3

In many places, during initialization, there is a check for a fault condition that just causes the function to return without reporting anything. This is potentially unsafe and there should be a common way to handle initialization faults.

Failure scenarios I can think of:

• Messages aren't protected during write. If a low-priority publisher is writing to the oldest message in the topic group, and a high-priority publisher needs to drop that message in order to publish, the topic group memory could become corrupted.
• A low-priority listener is publishing something on its own topic group, and the topic group is full. In this case, the low-priority listener might try to take its own mutex.

These sorts of issues can be prevented by ensuring that topics never run out of memory. See also #5

This allows static node id allocation via parameter to work on the bootloader.

This is both a safety and RAM recovery issue - if pubsub topic groups are running out of memory, that's not safe, but we don't want to waste memory unnecessarily.

this will allow for storage mechanisms other than flash, while keeping the same param frontend

This allows event-driven update of intermediate variables when parameters are changed.

Being able to shrink these could save significant RAM.

If a bootloader.bin file is present in the board configuration directory, create a combined bootloader+application binary file.

e.g.:

#include <modules/worker_thread/worker_thread.h>

WORKER_THREAD_DECLARE_EXTERN(spi3_thread)

static struct worker_thread_listener_task_s imu_delta_listener_task;
static void imu_deltas_handler(size_t msg_size, const void* buf, void* ctx);

RUN_AFTER(INIT_END) {
    worker_thread_add_listener_task(&spi3_thread, &imu_delta_listener_task, &imu_deltas_topic, imu_deltas_handler, NULL);
}

static void imu_deltas_handler(size_t msg_size, const void* buf, void* ctx) {
    const struct imu_delta_s* deltas = (const struct imu_delta_s*)buf;

    // ...
}

should be more like:

WORKER_THREAD_LISTENER(spi3_thread, imu_deltas_topic) {

}

Or something more C++-y.