RAM usage brain dump

[jschall]

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 CAN Tx queue uses more RAM than necessary #4 param list uses more RAM than necessary #3