RTOS users -- how many tasks?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you use some sort of RTOS in your projects, how would you estimate a number of concurrently running tasks and a size of the projects (in very generic terms, of course)?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For an avr class of project of around 12 to 20k of object using a cooperative scheduler, i'dhave the following tasks:

comms - run only when addressed

read analog inputs - every 100ms

process logic - every 100ms

user interface - every 100ms

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman beat me to it, but in general I break out the tasks into logical groups that seem to make sense to me,

and lets me partition the project for easy troubleshooting / debugging.

In a recent large project, I ended up with 7 tasks using a cooperative rtos

UI  input

UI output

Analog sensor input

Digital sensor input

digital outputs

analog outputs

process logic

 

 

JC

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
stack gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Thu. Oct 2, 2014 - 02:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This does kind of depend on the project. I worked on a satellite TV recorder that had something like 100 tasks. I think there were about 400 sem4/mutex and perhaps 20 queues. There was about 5MB of code. Perhaps about 250,000 lines of source. It ran on an ARM9.

 

Then of course there are devices based on Linux. There's some debate (even with realtime extensions) as to whether you can describe it as "RTOS" but even if you just boot Linux and "ps ax" you will see maybe 100+ active PIDs even before you get started.

 

But it does depend on the scale of the thing and teh flash/RAM/CPU resources available.

 

(I once did a 3 task demo using FreeRTOS on an atmega168 with its 2K of RAM).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How fast does the timer tic tick on that arm9 os? Every 10ms? So the scheduler needs to at least do a for loop on 100 task control blocks and decrement the ticstogo or something. If that takes 1ms, then the os is using 10% of the cpu. Is there a rule of thumb for spare cpu? 50% or so?

If you have 10 tasks and a 30ms loop time, I guess ea task should run about 3ms?

Imagecraft compiler user

Last Edited: Sat. Oct 4, 2014 - 06:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some RTOS schdulers have a fixed number of tasks. Many others, including FreeRTOS, allow for task creation (and deletion) at run time. The RAM for each task's stack is given by the task that "spawns" the new task - and that RAM can come from static RAM or allocated from the heap.

 

As to how many - You could estimate by how many tasks (threads) need to block waiting for an interrupt or waiting for a timer to expire (RTOS wait() ). Or waiting for an I/O driver to put a message on a queue (e.g., incoming wireless or some such).

But we don't want to create inter-task messaging and semaphore waits just for the computer science interest- often done by inexperienced people thinking gigabyte non-real time.

If you have, say, 3 tasks that might compete for a resource, like a single SPI port, one can use the RTOS wait for a mutual exclusion semaphore to "own" the SPI port for a while.

 

In any RTOS, beware of using task preemption... switching tasks at the interrupt level. Commonly done. But for embedded, esp. Arduino and the C library, some code is non-reentrant. Famous example is printf() and the underlying library scheme for handling a variable length argument list. Any library that uses static variables is a no-no with preemption. FeeRTOS, e.g., has a config option to disable preemption - thus avoiding all this. But the burden falls on every task to hot hog the CPU without a call to wait() or other RTOS function that will force a task switch - and done by the task when it is sure that no reentrancy issue will arise (e.g., after all printf()/scanf(), after releasing a mutual exclusion semaphore, etc.

 

Programming in an RTOS takes a different mindset - your code does NOT "own" the CPU and I/O devices, especially if you enable task preemption.

 

 

Last Edited: Sat. Oct 4, 2014 - 07:35 PM