ArduPilot:master
← peterbarker:wip/comm-num-buffers-change
opened 02:40AM - 03 Jan 23 UTC
Currently we define `MAVLINK_COMM_NUM_BUFFERS` without defining MAVLINK_GET_CHAN…NEL_BUFFER
This makes the mavlink library statically allocate objects to hold data about messages being received. Combined this comes to about 300 bytes per value in `MAVLINK_COMM_NUM_BUFFERS`
`MAVLINK_COMM_NUM_BUFFERS` is 5 on our embedded boards. Our default parameters set mavlink on serials 0, 1 and 2. So in the default configuration we burn ~900 bytes of RAM on static buffers that will never be used.
This change moves the buffer (and the status object) into the GCS_MAVLink objects, which are dynamically allocated at boot-time according to the user's parameters. This will stop us burning that 900 bytes, and for each backend the user disables will free up an additional 300 bytes.
Drawbacks here include
- we size a lot of arrays on MAVLINK_COMM_NUM_BUFFERS - these *should* at least be based off a renamed variable, something like MAX_GCS_MAVLINK_BACKENDS or similar.
- increased overheads when getting the buffer and status objects
- severity yet to be assessed
- possibly a few more bytes of flash used (yet to be assessed)
Some very, very badly extracted numbers from a CubeBlack:
```
master freemem/backends:
3: STABILIZE> 277: MEMINFO {brkval : 0, freemem : 50384, freemem32 : 50384}
2: STABILIZE> 522: MEMINFO {brkval : 0, freemem : 52864, freemem32 : 52864}
1: STABILIZE> 654: MEMINFO {brkval : 0, freemem : 55328, freemem32 : 55328}
new freemem/backends:
3: STABILIZE> 1493: MEMINFO {brkval : 0, freemem : 51160, freemem32 : 51160}
2: STABILIZE> 1102: MEMINFO {brkval : 0, freemem : 53960, freemem32 : 53960}
1: STABILIZE> 906: MEMINFO {brkval : 0, freemem : 56520, freemem32 : 56520}
```
... but at least there's rough correlation with the expected savings.
@Hwurzburg should we document disabling un-used `SERIALn_PROTOCOL==2` backends as a way of saving memory on e.g. F405?