Question

Platform: ARM9

Programming Language C

Requirements – plain C and no external libs and no boost.

OS – REX RTOS

I have two threads running in an embedded platform –

1. one is at driver level handling all the comms and data transfer with the hardware.
2. the second thread runs the application that uses the data to/from the hardware.

The idea is to decouple the app thread from the driver thread so we can change the hardware and implementation in the hardware driver thread but have minimal impact on the application thread.

My challenge is that the data received from the hardware may be dynamic i.e. we do not know upfront how much memory the application thread should set aside for each request to/from the hardware as this is determined at run-time.

I was thinking the driver thread could inform the application thread that there is so much data to read. The application thread then allocates the memory and requests the driver thread to read the data. It is then up to the application thread to process the data accordingly. This way, all the memory management is within the application thread.

Answer 1

Couple options come to mind:

1) malloc the memory in the driver, free it in the app. But… we tend to avoid malloc use in anything that approaches a real time requirement. If you have access to malloc/free, and there are no ‘real time’ concerns or memory fragmentation issues (i.e. your heap is large enough), then this is a fairly easy approach. The driver just sends the allocated pointer to the app thread via a message queue and the app free’s the memory when done. Watch out for memory leaks.

2) Ring or circular buffers. The driver completely manages a fixed size ring buffer and simply sends a message to the application when a buffer is ready. See here for some details: Circular buffer. Then the application marks the data ‘available’ again via a driver API, which helps hide the ring buffer details from the app thread. We use this approach for one of our drivers that has a very similiar set of requirements as you describe. In this case, you need to be concerned with determining the ‘best’ size for the ring buffer, overflow handling in the driver, etc.

good luck!