Electronic – Must FreeRTOS task stack size account for interrupt stack size

Comms stacks :(

Comms stacks in plain C :((

This is a summary of how I do it, though it's surely not the only way:

The app starts by by creating a 'generalPool' array of buffer structs, (BS:), of a fixed size. No more buffers are ever allocated and no buffers are ever freed during the run. The BS has space for data, data len, next/prev index bytes and a 'command' enum that describes what the buffer is, (and other stuff, but that clouds the issue). Indexes to this array are used for all inter-thread and driver comms, (I use byte-size indexes, rather than pointers, because there are less than 256 BS and I have RAM constraints). The next/prev bytes are initialized to form a double-linked list, and the calls to get/put an index are protected by a mutex.

Inter-thread comms are performed by getting a BS index from the generalPool, loading it up as required, setting the enum and then pushing the index onto a producer-consumer queue. The thread at the other end dequeues the index and, typically, switches on the enum to handle the BS message. Once handled, the consumer thread can repool the BS or queue it on somewhere else for further handling, (logger, say).

Because the BS has those next/prev bytes, the producer-consumer queue class does not need any storage space of its own - it has first and last bytes and so can link together the BS in a similar manner to the pool.

OK, now drivers:

I have interrupt-nesting disabled so that only one interrupt can run at a time. This enables me to make a BS index 'DriverQueue'. The DriverQueue has actual storage space for the index bytes - it does not use the next/prev links. This allows BS indexes to be safely added at one end, and removed at the other, by any one interrupt and one thread.

I have one 'CommsPool' DriverQueue. This is pre-filled on startup with some BS extracted from the generalPool. These BS are used for received data.

I have one 'commsTx' DriverQueue for each tx interrupt. Outgoing data is queued on them.

I have one 'commsRx' DriverQueue for all rx interrupts. Incoming data is queued on it.

One 'commsThread' handles the higher-level comms by initializing and operating a state machine, similar to your idea. When idle, it waits on a 'CommsEvent' semaphore.

The rx interrupts get BS from the CommsPool, load them up with data from the hardware, set the command enum to 'RxX', (X is the comms channel/interrupt ID number), push the BS index onto the common commsRx queue and signal CommsEvent.

The tx interrupts get BS from their own, private commsTx, load the data into the hardware, set the command enum to 'TxUsed', push the BS index onto the common commsRx queue and signal CommsEvent.

The commsThread is responsible for managing all the I/O. It has a 'commsRq' input queue for comms request BS from other threads. This is not, however a blocking queue - just thread-safe. It is not blocking because the commsThread has to handle the commsEvent signals from the interrupt-handlers as well.

Any thread that wants to communicate stuff loads up a BS with appropriate data and command, queues it to commsRq and signals CommsEvent, so waking the commsThread.

The commsthread does not know why it has been woken, so it polls the commsRx queue first to see if there is a BS in it. If there is, it handles it - if an 'RxX', it processes it through its state-engine code/data, if a 'TxUsed', it checks the CommsPool first, to see if it needs 'topping up', and pushes it there if there is need, else it pushes it back onto the generalPool for re-use elsewhere.

Once the commsThread has handled the driver queues appropriately, it polls the commsRq queue to see if there are any new comms requests from other threads. If there are, it dequeues and handles the request thorough it's state-machine code/data.

After that, the commsThread checks again to see if any CommsPool 'topping up' is required and, if the CommsPool is not full, tops it off with more BS from the generalPool.

The commsThread then loops back to wait on the semaphore again. The semaphore ensures that the commsThread runs exactly as many times as are requried to handle all input from other threads and the interrupt-handlers, no more, no less. If the thread ever wakes up and finds nothing to do, it's an error.

That's how I do it, anyway:) It provides good throughput and efficient use of RAM. Inter-thread producer-consumer queues need no internal storage. Only one thread, (and so only one RAM-consuming stack:), is required for all interrupt-management and Tx/Rx data handling. No mallocs/frees required after initialization. There is no busy-waiting or any need for periodic checking of any flags. No copying of the data is required, (except in/out of hardware - unavoidable). Timeout actions can be handled by either a timed wait on the semaphore, (preferable, if your OS supports it), or by the periodic'injection' of a 'TimeTick' BS on the inputQueue from some other thread. Returned BS can easily be 'diverted' to, say, a logger or terminal, for debug display before returning them to the generalPool.

However you do this, you should consider moving to C++. C just gets messy for anything other than simple straight-line code. C++ allows, for instance the BS to be implemented as class instances with methods for streaming in data and for 'auto-extending' a BS by getting and linking another BS if one BS gets full, so generating a 'compound' data message.

I've left some stuff out. For example, perhaps you already know the misery of tx interrupts - after the tx has been idle, they often have to be 'primed' by having the first bytes loaded into a FIFO to get the TX interrupt to start again :(

Also hint: my UART debug terminal prompt looks like 'A:96>'. The number, (96 here), is the current count of BS in the general pool. If this number starts dropping, I know I have a leak:)

I believe there are several more driving forces for having two sets of functions, than you have mentioned.

1. Those RTOSs are designed to be portable to many different processor Instruction Set Architectures (ISAs), and they also try to ensure developers can write systems which are portable. So they have to accommodate all of the variability of processor ISAs in ways which hide the differences between ISAs from the RTOS users.
2. Some of the ISAs used under an RTOS have both 'user' mode, and 'privileged' mode. 'User' mode will not have access to all of the system, and specifically might not be able to block interrupts. Further some of the functions might not be able to run in 'user' mode, and may 'trap' to a privileged mode exception handler to actually do the work. So having two 'name spaces' aligned to the two CPU privilege states might be helpful to the RTOS and application developers.
3. IMHO it is much easier to remember to use a function from one 'name space' (e.g. 'user' mode) than it is to figure out exactly which function can be used in any specific context. Specifically, it is much easier for all the functions to come in a 'user application' name space, and a 'privilaged-system-component' name space. So, even if the code is identical, it is simpler for the application developer to use the functions in the 'application' or 'user' name space. If that is an advantage for the application developer, then it is more helpful for for the RTOS provider to 'duplicate' the code, into a function in the other 'name space' than not have the duplicated function.

Summary: IMHO having two sets of functions, effectively constituting two different 'name spaces' ('user application' and 'systemcomponent'), makes it easier for the 'application' developer, and developers adding extra 'privileged-system-component' to use.

It might also be easier to have two different function sets to make it easier to manage interrupts raised during the code running in two different system states.

It may be relatively straightforward to create the two alternatives using some carefully thought out pre-processor macros, to minimise code duplication.

If you are not intending anyone else to use your OS, or your OS will treat exceptions raised during 'user' mode and 'system' mode identically, then you can probably ignore the idea.

However, if you don't know how it might all work (for example this is the first time you have written an RTOS), or you think it might change, then you might want to think carefully about how you would re-introduce the two 'name spaces' part way through developing your OS.