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?

Futile

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.

Hargeisa

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.

Anaglyph

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.

Encephaloma

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.

Scalenus

The preemptive threading capability allows us to avoid building an overly complex state machine in the communications task. By having a thread for the communications part the code is pretty straight forward. If we broke it up into a state at every point which currently has a sleep(1000) type of block the code would basically be a spaghetti code mess of very small states. It could be done, however, we would rather keep the code clean and maintainable. The other state machines range from simple to somewhat complex (one has ~15 states). The communications state machine would be even more co – Futile