UART stream packetisation; stream or vector?

Question

I am writing some code to interface an STM32H7 with a BM64 Bluetooth module over UART.

The BM64 expects binary data in bytes; in general:

1. Start word (0xAA)    
2-3. Payload length    
4. Message ID    
5-n. Payload    
n+1. Checksum

My question is around best practice for message queuing, namely: Custom iostream, message vectors inside an interface class or other?

My understanding so far, please correct if wrong or add if something missed:

1. Custom iostream has the huge benefit of concise usage inline with cout etc. Very usable and clean and most likely portable, at least in principle, to other devices on this project operating on other UART ports. The disadvantage is that it is relatively a lot of work to create a custom streambuf and not sure what to use for "endl" (can't use null or '\n' as these may exist in the message, with it being binary.)

2. Vectors seem a bit dirty to me and particularly for embedded stuff, the dynamic allocations could be stealing a lot of memory unless I ruthlessly spend cycles on resize() and reserve(). However, a vector of messages (defined as either a class or struct) would be very quick and easy to do.

3. Is there another solution? Note, I'd prefer not to use arrays, i.e. passing around buffer pointers and buffer lengths.

What would you suggest in this application?

Answer 1

On bare metal systems I prefer fixed sized buffers with the maximum possible payload size. Two of them, fixed allocated, one to fill and one to send in parallel, switch over when finished. All kind of dynamic memory allocation ends in memory fragmentation, especially if such buffers jitters in size.

Even if you system have an MMU, it is maybe a good idea to not do much dynamic heap allocation at all. I often used own written block pool memory management to get rid of long time fragmentation and late alloc failures.

If you fear to use more than currently needed ram, think again: If you have such less ram that you can't spend more than currently needed, your system may fail sometimes, if you really need the maximum buffer size. That is never an option on embedded at all. The last one is a good argument to have all memory allocated more or less fixed as long as it is possible that under real runtime conditions this can happen at "some point in the future" :-)