Searching \ for '[EE] RTOS Concepts' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/index.htm?key=rtos+concepts
Search entire site for: 'RTOS Concepts'.

Exact match. Not showing close matches.
PICList Thread
'[EE] RTOS Concepts'
2009\05\27@031401 by solarwind

picon face
I've read through a few RTOS articles and tutorials (like the one on
FreeRTOS' site) and I still have a few questions about RTOS.

Let's say we're using a preemptive RTOS for these set of questions:

1. Let's say we have two tasks, A and B, as follows:

void a() {
   while(1) {}
}

void b() {
   while(1) {}
}

If task A has higher priority than B, will B ever get a chance to run?
If so, how often?

How about when A is set to the highest priority and B to a low
priority? How is CPU time split up in that case?

If task A has equal priority as task B, will CPU time be shared
equally among the tasks?

2. Let's say we have two tasks, C and D, as follows:

void c() {
   while(1) {
       if(some condition that is true sometimes)
           return; (or yield)
   }
}

void d() {
   while(1) {}
}

If C and D have equal priorities, and c returns prematurely, does D
immediately get the rest of C's CPU time? Or does the IDLE task take
over for C's share of the CPU time/

Is there such thing as "yield()" in a preemptive scheduler system? I
mean, let's say we have a task that performs lengty floating point
math trig functions. And during a certain cycle, we don't need to
perform those math operations because a certain condition has been
met. Can we "yield()" out of the task so that task D will get the rest
of our CPU time?

Let's say we add another task, E, which has less priority than C and
D. If we are able to yield() out of task C, how is the rest of C's
time split among D and E?

3. Are tasks generally run over and over again? Or are they just run once?

4. Is there such thing as "realtime" priority? If so, what does it
mean? I've heard the term being used in the past.

5. If we have two tasks, J and K, which each perform very important
protocol operations (such as bitbang 1-wire and RS-485 protocol), and
both are set to the highest priority, how should they be set up so
that they don't interrupt each other in critical moments, such as when
task K has a job of sending a token while J is reading a temperature
sensor?



-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\27@125035 by olin piclist

face picon face
> If task A has higher priority than B, will B ever get a chance to run?
> If so, how often?

This depends on the scheduler.  Different implementations will have
different properties.

> How about when A is set to the highest priority and B to a low
> priority? How is CPU time split up in that case?

Heavily favored towards A, but B might get some time depending on the
scheduler.

> If task A has equal priority as task B, will CPU time be shared
> equally among the tasks?

In theory.

> If C and D have equal priorities, and c returns prematurely, does D
> immediately get the rest of C's CPU time? Or does the IDLE task take
> over for C's share of the CPU time/

If there is only one task, it will get CPU when the OS isn't using it.  If
nobody wants the CPU, then the idle task in the OS will run.

> Is there such thing as "yield()" in a preemptive scheduler system?

Usually yes.

> 3. Are tasks generally run over and over again? Or are they just run once?

That's up to you, not the OS.  Your app code starts tasks, then the OS
decides when to run them.

> 4. Is there such thing as "realtime" priority? If so, what does it
> mean?

That's usually a very high priority.  The details are up to the particular
scheduler.

> 5. If we have two tasks, J and K, which each perform very important
> protocol operations (such as bitbang 1-wire and RS-485 protocol), and
> both are set to the highest priority, how should they be set up so
> that they don't interrupt each other in critical moments,

It may not be possible.  Essentially you are asking for a way to have a
particular task declare that it be the only task that gets CPU until it says
otherwise.  Some real time OSes might support that, but no ordinary desktop
OS or multi-user system would allow that.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\27@125947 by Isaac Marino Bavaresco

flavicon
face
solarwind escreveu:
> I've read through a few RTOS articles and tutorials (like the one on
> FreeRTOS' site) and I still have a few questions about RTOS.
>
> Let's say we're using a preemptive RTOS for these set of questions:
>
> 1. Let's say we have two tasks, A and B, as follows:
>
> void a() {
>     while(1) {}
> }
>
> void b() {
>     while(1) {}
> }
>
> If task A has higher priority than B, will B ever get a chance to run?
> If so, how often?
>  

Only if A sleeps.

> How about when A is set to the highest priority and B to a low
> priority? How is CPU time split up in that case?
>  

A runs all the time. B runs when A sleeps (vTaskDelay for FreeRTOS).

> If task A has equal priority as task B, will CPU time be shared
> equally among the tasks?
>  

Usually, but depends how they use Yield, Sleep, etc.

> 2. Let's say we have two tasks, C and D, as follows:
>
> void c() {
>     while(1) {
>         if(some condition that is true sometimes)
>             return; (or yield)
>     }
> }
>  

In FreeRTOS a task must not return, it should call vTaskDelete. Yield
just give up the rest of the time slice, vTaskDelete will finish a task.

> void d() {
>     while(1) {}
> }
>
> If C and D have equal priorities, and c returns prematurely, does D
> immediately get the rest of C's CPU time? Or does the IDLE task take
> over for C's share of the CPU time/
>  

The next task gets the rest of the slice time.

> Is there such thing as "yield()" in a preemptive scheduler system? I
>  

Yes.

> mean, let's say we have a task that performs lengty floating point
> math trig functions. And during a certain cycle, we don't need to
> perform those math operations because a certain condition has been
> met. Can we "yield()" out of the task so that task D will get the rest
> of our CPU time?
>  

Yes.

> Let's say we add another task, E, which has less priority than C and
> D. If we are able to yield() out of task C, how is the rest of C's
> time split among D and E?
>  

In FreeRTOS, a lower priority task only runs if all the higher priority
tasks are sleeping.
Yield will only allow tasks with the same or higher priority to run. To
allow lower priority tasks to run, you must use vTaskDelay( n_ticks ).
n_ticks must not be zero.
I modified FreeRTOS  for vTaskDelay( 0 ) to behave as an Yield that
allows lower priority tasks to run for the rest of the tick.

> 3. Are tasks generally run over and over again? Or are they just run once?
>  

They are a while(1){}. They exist until some task (or itself) calls
vTaskDelete. They stop running when call vTaskSuspend, vTaskDelay, etc.
are called, but may become active again.

> 4. Is there such thing as "realtime" priority? If so, what does it
> mean? I've heard the term being used in the past.
>  

It is just the highest priority.

> 5. If we have two tasks, J and K, which each perform very important
> protocol operations (such as bitbang 1-wire and RS-485 protocol), and
> both are set to the highest priority, how should they be set up so
> that they don't interrupt each other in critical moments, such as when
> task K has a job of sending a token while J is reading a temperature
> sensor?
>  

Use critical sections. Or raise the task priority before doing the
critical work and lower again afterwards.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\27@133733 by Tamas Rudnai

face picon face
On Wed, May 27, 2009 at 5:59 PM, Isaac Marino Bavaresco <
spam_OUTisaacbavarescoTakeThisOuTspamyahoo.com.br> wrote:

> > If task A has higher priority than B, will B ever get a chance to run?
> > If so, how often?
> >
>
> Only if A sleeps.


No arguments here, but some RTOS' scheduler can raise the priority
temporarily for a task that was not running for a while. Theoretically you
should never design a code with tight loops though, so your task finishes
it's job in time or will wait for the OS in another way. One style is to
wait for a semaphore and your interrupt routine triggers your task to
continoue to run. You can also design your code to be event triggered so
your tasks will be started / wakened up from suspend state when a certain
even occures. In some RTOS you can even determine when your task should be
finished and instead of having a priority based sheduler the CPU time will
be given to the tasks that has the earlier deadlines. Anyways, you should
always learn how is your RTOS works and behaves and adopt your code
appropriately.


{Quote hidden}

I would rather go for the critical section if you ever plan to learn / use
other RTOS. It may also achievable to write an interrupt routine that
receives the sendable characters in a queue and sending it in bitbang way
using timer interrupt (or doing the opposite to receive). But then you may
also need to have some semaphores to mark whenever a certain task can be
started or enter to a critical section. I think as Olin suggested these are
the kind of things that might can make your project more complicated rather
than easing of it.

Tamas

2009\05\28@033513 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olin Lathrop wrote:
[snip]
> It may not be possible.  Essentially you are asking for a way to have a
> particular task declare that it be the only task that gets CPU until it says
> otherwise.  Some real time OSes might support that, but no ordinary desktop
> OS or multi-user system would allow that.

Ahem.... *points at Linux's sched_setscheduler(SCHED_FIFO)*:

"A SCHED_FIFO process runs until either it is blocked by an I/O request,
it is preempted by a higher priority process, or it calls sched_yield(2)."

although one does have to have CAP_SYS_NICE (typically only held by
root) to do this.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoePqYACgkQXUF6hOTGP7cMngCgguGWqfKy6Ad9rdjA/RDI/1EP
wqIAoIO+DU0UE42Nw7GWGdiuqTKaJN1q
=DUH9
-----END PGP SIGNATURE-----

2009\05\28@041348 by Alan B. Pearce

face picon face
>In FreeRTOS, a lower priority task only runs if all
>the higher priority tasks are sleeping.

One scheme I have seen used in a co-operative OS is each task is assigned a
priority number, the larger the number the lower priority of the task. Then
as the task scheduler checks each task, it decrements the priority number ,
and when it reaches 0, that task is run. This means that even the lowest
priority task will eventually reach a point where it will get an opportunity
to run, even with a large number of high priority tasks. When the task has
had an opportunity to run, and goes back to sleep, the OS reloads the
priority number with the original value, ready for the next round of
decrementing.

2009\05\28@074713 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> If task A has equal priority as task B, will CPU time be shared
>> equally among the tasks?
>
> In theory.

Depends on the scheduler, though, as everything else. There is not "the
RTOS" -- there are RTOS concepts, and their implementations. And pretty
much every implementation is different.

>> 5. If we have two tasks, J and K, which each perform very important
>> protocol operations (such as bitbang 1-wire and RS-485 protocol),
>> and both are set to the highest priority, how should they be set up
>> so that they don't interrupt each other in critical moments,
>
> It may not be possible.  Essentially you are asking for a way to have
> a particular task declare that it be the only task that gets CPU
> until it says otherwise.  Some real time OSes might support that, but
> no ordinary desktop OS or multi-user system would allow that.

Typical desktop/multi-user systems do allow this. Most systems have a
means of thread (aka task) synchronization. You can use this to prevent
that two threads interrupt each other in critical moments. Details (and
nomenclature) of course vary widely between systems.

However on a typical desktop/multi-user system this doesn't mean that
other processes (or the system) won't interrupt your task/thread. But if
that is a requirement, such systems are not suited anyway. I would think
that any OS that can be called a "real-time OS" should have a means to
guarantee this, though.

Gerhard

2009\05\28@081844 by Tamas Rudnai

face picon face
On Thu, May 28, 2009 at 12:47 PM, Gerhard Fiedler <
.....listsKILLspamspam@spam@connectionbrazil.com> wrote:

> Typical desktop/multi-user systems do allow this. Most systems have a
> means of thread (aka task) synchronization. You can use this to prevent
> that two threads interrupt each other in critical moments. Details (and
> nomenclature) of course vary widely between systems.
>

Within your app you can do that,  however, in a typical desktop you have
other tasks than just yours and those tasks are almost guaranteed that will
not care about your synchronization efforts.

Usually you need to write a kernel module / driver that can occupy the CPU
as long as it needs. The driver then will provide an API to the upper layer
so the user app does not have to be dependent on the timings or bother about
such things.

Tamas
--
http://www.mcuhobby.com

2009\05\28@110544 by Harold Hallikainen

face
flavicon
face

>>In FreeRTOS, a lower priority task only runs if all
>>the higher priority tasks are sleeping.
>
> One scheme I have seen used in a co-operative OS is each task is assigned
> a
> priority number, the larger the number the lower priority of the task.
> Then
> as the task scheduler checks each task, it decrements the priority number
> ,
> and when it reaches 0, that task is run. This means that even the lowest
> priority task will eventually reach a point where it will get an
> opportunity
> to run, even with a large number of high priority tasks. When the task has
> had an opportunity to run, and goes back to sleep, the OS reloads the
> priority number with the original value, ready for the next round of
> decrementing.
>

That's clever! I've just done cooperative multitasking before with equal
priority. In my schemes (like
http://www.piclist.org/techref/microchip/language/c/MultiTask.c.htm), a
task runs until it gets stuck waiting for input. It then sits in a loop
with NextTask() waiting for input. Once it has input, it runs until it
again is waiting for input. On the output side, the tasks generally drive
a fifo (often an input fifo for another task or for an I/O device), so
they do not get stuck there unless the fifo fills.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\05\28@115817 by Alan B. Pearce

face picon face
>> One scheme I have seen used in a co-operative OS is each task is
>> assigned a priority number, the larger the number the lower
>> priority of the task.
...

>That's clever!

Yes, that is what I thought when I first came across it. IIRC a task could
be assigned a priority between 1 and 99, with the default being somewhere in
the middle.

For an embedded system I suspect 1 through 7 would be plenty sufficient,
with 0 being the running task. If a number of tasks reached 0 together, then
I think it did a round robin on them.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...