On a small embedded system project we have some code which we would like to run in a thread so we are electing to build in top of an embedded RTOS (eCos).
Previously, we have used a cyclic executive in main() that drove tasks each implemented as a state machine. For some tasks we encountered problems where the task would need to be broken up into many fine grained states thus making the code extra complex.
When switching to an RTOS we found the memory usage for each thread’s stack adds up quickly if we give each separate task it’s own thread. (we only have 64k and need the memory for our communications buffers)
We are considering using a tread for our communications task and an other thread for a cyclic executive. The cyclic executive will drive the other logical tasks.
Does it make sense to mix an RTOS and cyclic executive like this?
This is a perfectly valid design.
In one of our product, we used a similar design, where the asynchronous I/O channels (TCP/IP, 2 serial streams) were in their own tasks and we had a ‘main’ task which would be responsible for multiple areas of functionality.
Think of tasks as simply a partitioning mechanism that allows you to simplify your design.