Does it make sense to mix an RTOS and cyclic executive?

Question

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?

Answer 1

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.

Answer 2

Yes, having a cyclic executive in one OS thread running multiple 'tasks' can make sense. In fact unless two tasks conflict with scheduling needs (one needs to block, one is higher priority than the other and the low-priority one takes a long time to execute, etc.), I'd recommend putting them in the same thread.

This is especially true in the case where you are using a light-weight RTOS with no memory protection: separate threads aren't any safer than one thread (no MMU protection of address spaces), in fact they are potentially more dangerous because of the greater need for concurrency protection. Even if your IPC scheme is robust and not susceptible to misuse by programmers, it's overhead is usually non-zero, so avoiding the need for it can result in performance gains.

Answer 3

If you look at FreeRTOS, they actually run another scheduler in a task, sort of :)

And to echo others, nothing sounds wrong in the design. No reason (some of) your tasks can't be state machines if there's a clear way to express something that way.

Answer 4

It is a valid design, but I think I missed the reason for having the OS at all.

What facilities of the OS are you planning to use?

From the information available it seems that you will end up moving the complexity of the tasks to your new main loop.