Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28994 > unrolled thread

Task priorities in non strictly real-time systems

Back to article view | Back to comp.arch.embedded

Contents

  Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-03 14:41 +0100
    Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-03 15:19 +0100
      Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:25 +0100
        Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:32 -0600
          Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-05 16:49 -0500
            Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:05 -0600
          Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-05 17:08 -0700
            Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:26 -0600
              Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-05 22:10 -0700
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-06 07:37 -0600
                  Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 17:21 -0700
                    Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 19:23 -0600
                Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-06 20:36 -0500
                  Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 01:38 -0600
                    Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 06:53 -0500
              Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 07:13 -0500
              Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-07 10:11 +0100
                Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 07:05 -0500
                Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 19:34 -0600
            Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-06 10:44 +0200
              Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 02:51 -0700
                Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-06 15:39 +0200
                  Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 13:29 -0500
                    Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 14:38 -0700
                    Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 07:05 +0200
                      Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-07 13:09 -0500
                        Re: Task priorities in non strictly real-time systems Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-07 20:53 +0200
                          Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-08 08:43 +1100
                            Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-08 00:33 +0200
                            Re: Task priorities in non strictly real-time systems Dimiter_Popoff <dp@tgi-sci.com> - 2020-01-08 15:26 +0200
                        Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-08 00:08 +0200
                    Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-07 10:37 +0100
                  Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 16:10 -0700
                    Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 07:37 +0200
                      Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-07 01:49 -0600
                      Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:43 -0700
                    Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 10:21 +0200
                      Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:42 -0700
                        Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-07 22:23 -0500
                          Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-09 22:07 +0200
                    Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-07 10:54 +0200
                      Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-07 06:43 -0700
            Re: Task priorities in non strictly real-time systems Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-01-06 18:01 +0100
              Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-06 19:47 +0200
      Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:58 +0100
        Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-05 14:26 +1100
          Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-05 11:21 +0200
            Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 14:07 +0100
              Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-05 17:46 +0200
                Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 19:08 +0100
          Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 13:56 +0100
          Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:39 -0600
            Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-06 07:44 +1100
              Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 21:00 -0600
                Re: Task priorities in non strictly real-time systems Clifford Heath <no.spam@please.net> - 2020-01-06 14:50 +1100
                  Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-06 07:12 -0600
        Re: Task priorities in non strictly real-time systems Paul Rubin <no.email@nospam.invalid> - 2020-01-04 22:34 -0800
          Re: Task priorities in non strictly real-time systems David Brown <david.brown@hesbynett.no> - 2020-01-05 14:12 +0100
            Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-05 18:00 +0200
          Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:44 -0600
        Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 14:52 -0500
        Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-06 15:05 -0500
          Re: Task priorities in non strictly real-time systems gtwrek@sonic.net (gtwrek) - 2020-01-06 22:41 +0000
          Re: Task priorities in non strictly real-time systems Don Y <blockedofcourse@foo.invalid> - 2020-01-06 19:50 -0700
            Re: Task priorities in non strictly real-time systems George Neuner <gneuner2@comcast.net> - 2020-01-07 13:26 -0500
    Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-03 16:28 +0200
      Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:37 +0100
        Re: Task priorities in non strictly real-time systems Les Cargill <lcargill99@comcast.com> - 2020-01-05 13:46 -0600
          Re: Task priorities in non strictly real-time systems Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-01-05 22:44 +0200
    Re: Task priorities in non strictly real-time systems Rick C <gnuarm.deletethisbit@gmail.com> - 2020-01-03 11:49 -0800
    Re: Task priorities in non strictly real-time systems upsidedown@downunder.com - 2020-01-03 22:51 +0200
      Re: Task priorities in non strictly real-time systems pozz <pozzugno@gmail.com> - 2020-01-05 01:48 +0100
    Re: Task priorities in non strictly real-time systems Joe Chisolm <jchisolm6@earthlink.net> - 2020-01-03 15:34 -0600
    Re: Task priorities in non strictly real-time systems Richard Damon <Richard@Damon-Family.org> - 2020-01-03 21:46 -0500

Page 4 of 4 — ← Prev page 1 2 3 [4]

#29039

On Sun, 5 Jan 2020 01:58:04 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 03/01/2020 15:19, David Brown ha scritto:
>> With pre-emptive scheduling, you will have to go
>> through your existing code and make very sure that you have locks or
>> synchronisation in place for any shared resources or data.
>
>As I already wrote many times, I don't have experience with RTOS and 
>task sync mechanism such as semaphores, locks, mutexes, message queues 
>and so on.
>So I'm not able to understand when a sync is really needed.
>
>Could you point on a good simple material to study (online or book)?

Any book on operating systems will have a section on synchronization.
The discussions typically revolve around the "dining philosophers"
problem and/or the "producer-consumer / bounded buffer" problem:
https://en.wikipedia.org/wiki/Dining_philosophers_problem
https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem


Undertanding when to use synchronization generally is the easy part.
The hard part is that operating systems vary considerably in the
synchronization primitives they provide, what those primitives are
called, and how those primitives operate.

The term "lock" is non-specific: some systems may have something that
actually is called a "lock", but generally the term can refer to any
non-message based synchronization mechanism.

The weight and semantics of the primitive may be important: is it a
user-space or a kernel primitive?  Does the task wait (sleep) if the
lock is not available?  When the lock does become available, does it
wake all waiting tasks or only one?  Is the wait queue strictly FIFO
or is it by task priority?

Then there is the question of reentrancy: can you take a "lock"
multiple times?  And if so, do you have to release it an equal number
of times?  To both questions, the answer is implementation dependent.

A "mutex" and a "semaphore" conceptually are different in that a
semaphore is able to count and therefore it can enable some number of
concurrent accesses (perhaps to a replicated service).  However, a
mutex is a binary yes/no primitive.  But a mutex can be emulated by a
semaphore with its counter initialized to 1, so some systems provide
only semaphores.  And some systems provide what really are semaphores
but call them mutexes.


Basically you can't rely on the name of anything to understand its
semantics - you really have to study the system(s) you are writing
code for.  Particularly if you switch between different operating
systems.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#29040

On Sun, 5 Jan 2020 01:58:04 +0100, pozz <pozzugno@gmail.com> wrote:

>Could you point on a good simple material to study (online or book)?

Tony Hoare's book "Communicating Sequential Processes" is online at:
http://www.usingcsp.com/cspbook.pdf

Note: the 2015 date on the book refers to the online PDF - the
material in the book was published in 1985.

It will teach you everything you need to know about how to use message
passing to solve synchronization and coordination problems.  It won't
teach you about your specific operating system's messaging facilities.

George

[toc] | [prev] | [next] | [standalone]

#29042

In article <5d471fdcau3l6fvdu22lb3d51dl9kqap7a@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>
>Tony Hoare's book "Communicating Sequential Processes" is online at:
>http://www.usingcsp.com/cspbook.pdf
>
>Note: the 2015 date on the book refers to the online PDF - the
>material in the book was published in 1985.
>
>It will teach you everything you need to know about how to use message
>passing to solve synchronization and coordination problems.  It won't
>teach you about your specific operating system's messaging facilities.

George

It's gems like this why I keep browsing the newsgroups...

Thanks for the reference to Hoare's book.  I've just skimmed it now, and
will spend some more detailed reading in the coming weeks (and
months)...

Regards,

Mark

[toc] | [prev] | [next] | [standalone]

#29048

Hi George,

On 1/6/2020 1:05 PM, George Neuner wrote:
> On Sun, 5 Jan 2020 01:58:04 +0100, pozz <pozzugno@gmail.com> wrote:
> 
>> Could you point on a good simple material to study (online or book)?
> 
> Tony Hoare's book "Communicating Sequential Processes" is online at:
> http://www.usingcsp.com/cspbook.pdf
> 
> It will teach you everything you need to know about how to use message
> passing to solve synchronization and coordination problems.  It won't
> teach you about your specific operating system's messaging facilities.

It's not a panacea.  It introduces design and run-time overhead, as well
as adding another opportunity to "get things wrong".  <frown>

And, can complicate the cause-effect understanding of what's happening
in your system (esp if you support asynchronous messages... note how
many folks have trouble handling "signal()"!)

*But*, the UNDERstated appeal is that it exposes the interactions between
entities (that can be largely *isolated*, otherwise).  If you engineer
those entities well, this "goodness" will be apparent in the nature of
the messages and their frequency.

E.g., in my world, looking at the IDL goes a LONG way to telling you
what CAN happen -- and WHERE!

[toc] | [prev] | [next] | [standalone]

#29068

On Mon, 6 Jan 2020 19:50:23 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>Hi George,
>
>On 1/6/2020 1:05 PM, George Neuner wrote:
>> On Sun, 5 Jan 2020 01:58:04 +0100, pozz <pozzugno@gmail.com> wrote:
>> 
>>> Could you point on a good simple material to study (online or book)?
>> 
>> Tony Hoare's book "Communicating Sequential Processes" is online at:
>> http://www.usingcsp.com/cspbook.pdf
>> 
>> It will teach you everything you need to know about how to use message
>> passing to solve synchronization and coordination problems.  It won't
>> teach you about your specific operating system's messaging facilities.
>
>It's not a panacea.  It introduces design and run-time overhead, as well
>as adding another opportunity to "get things wrong".  <frown>

Yes, but not the point.  The question was study material, and Hoare's
book shows how to do it right.


>And, can complicate the cause-effect understanding of what's happening
>in your system (esp if you support asynchronous messages... note how
>many folks have trouble handling "signal()"!)

Yeah, but signal is a lossy channel.  MPC over network also might be
lossy (though not necessarily), but within a single host it is
reliable.  The case of within a single host (mostly) is the subject of
this discussion.


>*But*, the UNDERstated appeal is that it exposes the interactions between
>entities (that can be largely *isolated*, otherwise).  If you engineer
>those entities well, this "goodness" will be apparent in the nature of
>the messages and their frequency.
>
>E.g., in my world, looking at the IDL goes a LONG way to telling you
>what CAN happen -- and WHERE!

George

[toc] | [prev] | [next] | [standalone]

#28996

On 2020-01-03 15:41, pozz wrote:
> I have always worked on non real-time systems, i.e. when the reaction of 
> the system to an event should occur in a reasonable time. For example, 
> when the user presses a button, a motor should start rotating. If the 
> motor starts after 100us or 100ms is not so important.
> 
> I never used RTOS, so the architecture of my firmware is based on 
> "superloop technique" (background tasks running in the loop and 
> interrupts).
> 
> while(1) {
>    task1();
>    task2();
>    ...
> }
> 
> All the tasks don't block, ever. As a rule of thumb, I accept a block 
> time of maximum 100us-1ms. When the task needs to block for a greater 
> amount, I try to implement it as a state-machine, avoiding blocking.

... which can complicate the task's logical design, of course. That is 
the penalty you pay for the sequential-super-loop design.

And the same (state-machine) approach has to be used if a task contains 
some long sequential computation that must be divided into shorter 
stages (in which case the state-machine approach can have a much worse 
impact on the task's design). Again, that is the price...

    [snip]

> Sincerely I think this architecture is good enough for all non real-time 
> systems, so I don't understand why to use a RTOS in those cases.
> However I need to use a RTOS (FreeRTOS) for the next project, because it 
> is one of the requirement. It isn't a real-time system, but the RTOS is 
> required.
> 
> I think I can convert my architecture to RTOS by creating a task for 
> each of the function I call in the superloop and starting the OS 
> scheduler. However now the task function can't return, so I can write it 
> in the following way:
> 
> void task1_main(void) {
>    while(1) {
>      task1();
>    }
> }
> 
> task1() can be the *same* function of the superloop architecture.

A much simpler solution is to create *one* task that contains the 
*whole* superloop.

An RTOS does not *require* multiple tasks.

> I can assign each task the same priority: in this case, FreeRTOS will 
> use round-robin scheduling, giving all the tasks the same opportunity to 
> run.
> 
> Is it correct?

Probably not.

If your task<n>() functions have some interactions through data 
(variables), your superloop design probably assumes that the functions 
are called in a certain order, or at least that they do not pre-empt 
each other.

I am not very familiar with FreeRTOS, but to get round-robin scheduling 
of tasks of the same priority you probably have to insert "yield" points 
in the tasks (as David Brown's message explains) or you have to enable a 
pre-emptive time-slicing round-robin scheduling.

Neither approach gives you a predictable ordering of the task<n> calls, 
and the time-slicing approach moreover allows the functions to pre-empt 
each other, which probably messes up the data-flow of your program.

If the superloop design gives you sufficient performance and reactivity, 
just encapsulate it in a single task.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#29002

Il 03/01/2020 15:28, Niklas Holsti ha scritto:
> On 2020-01-03 15:41, pozz wrote:
>> I have always worked on non real-time systems, i.e. when the reaction 
>> of the system to an event should occur in a reasonable time. For 
>> example, when the user presses a button, a motor should start 
>> rotating. If the motor starts after 100us or 100ms is not so important.
>>
>> I never used RTOS, so the architecture of my firmware is based on 
>> "superloop technique" (background tasks running in the loop and 
>> interrupts).
>>
>> while(1) {
>>    task1();
>>    task2();
>>    ...
>> }
>>
>> All the tasks don't block, ever. As a rule of thumb, I accept a block 
>> time of maximum 100us-1ms. When the task needs to block for a greater 
>> amount, I try to implement it as a state-machine, avoiding blocking.
> 
> .... which can complicate the task's logical design, of course. That is 
> the penalty you pay for the sequential-super-loop design.

Yes, converting a blocking task in a non-blocking state-machine task can 
be hard, but it's complex to write tasks in a preemption schuduler (you 
need to know when to use locks, semaphores, mutexes and so on).


> And the same (state-machine) approach has to be used if a task contains 
> some long sequential computation that must be divided into shorter 
> stages (in which case the state-machine approach can have a much worse 
> impact on the task's design). Again, that is the price...
> 
>     [snip]
> 

Yes, but this isn't a very frequent situation, at least in my experience.

I remember a similar case with mbedTLS where a session setup taked a 
very long time, because I didn't use a hw crypto engine. For this 
reason, mbedTLS guys added a macro to enable an "incremental" 
calculation (I don't remember now the exact name they used). In practice 
the big calculus is divided in chuncks.


>> Sincerely I think this architecture is good enough for all non 
>> real-time systems, so I don't understand why to use a RTOS in those 
>> cases.
>> However I need to use a RTOS (FreeRTOS) for the next project, because 
>> it is one of the requirement. It isn't a real-time system, but the 
>> RTOS is required.
>>
>> I think I can convert my architecture to RTOS by creating a task for 
>> each of the function I call in the superloop and starting the OS 
>> scheduler. However now the task function can't return, so I can write 
>> it in the following way:
>>
>> void task1_main(void) {
>>    while(1) {
>>      task1();
>>    }
>> }
>>
>> task1() can be the *same* function of the superloop architecture.
> 
> A much simpler solution is to create *one* task that contains the 
> *whole* superloop.
> 
> An RTOS does not *require* multiple tasks.

Oh yes, this is another solution. However I'd like to migrate to a 
"full" RTOS approach step by step, and starting with the same tasks of 
the superloop should help on this way.

One after the other, I could work on each task and convert it in a 
"standard" task that blocks, if needed.


>> I can assign each task the same priority: in this case, FreeRTOS will 
>> use round-robin scheduling, giving all the tasks the same opportunity 
>> to run.
>>
>> Is it correct?
> 
> Probably not.
> 
> If your task<n>() functions have some interactions through data 
> (variables), your superloop design probably assumes that the functions 
> are called in a certain order, or at least that they do not pre-empt 
> each other.
> 
> I am not very familiar with FreeRTOS, but to get round-robin scheduling 
> of tasks of the same priority you probably have to insert "yield" points 
> in the tasks (as David Brown's message explains) 

Only in cooperative scheduler.


> or you have to enable a 
> pre-emptive time-slicing round-robin scheduling.

This is the "default" FreeRTOS configuration.


> Neither approach gives you a predictable ordering of the task<n> calls, 
> and the time-slicing approach moreover allows the functions to pre-empt 
> each other, which probably messes up the data-flow of your program.
> 
> If the superloop design gives you sufficient performance and reactivity, 
> just encapsulate it in a single task.

See my arguments against this approach above.

[toc] | [prev] | [next] | [standalone]

#29017

pozz wrote:
> Il 03/01/2020 15:28, Niklas Holsti ha scritto:
<snip>
> 
> Yes, converting a blocking task in a non-blocking state-machine task can 
> be hard, but it's complex to write tasks in a preemption schuduler (you 
> need to know when to use locks, semaphores, mutexes and so on).
> 
> 

The question becomes - how important is determinism in your system? IMO,
this can be expressed in economic terms - more determinism means fewer
times the phone rings.

<snip>

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#29019

On 2020-01-05 21:46, Les Cargill wrote:
> pozz wrote:
>>
>> Yes, converting a blocking task in a non-blocking state-machine task 
>> can be hard, but it's complex to write tasks in a preemption schuduler 
>> (you need to know when to use locks, semaphores, mutexes and so on).

I think that makes it sound harder than it is. Avoid directly shared 
variables when you can, using whatever message-passing tools the 
language or RTOS provides, or wrap all operations that access shared 
data in mutexes, and that will solve most problems.

What remains is mainly the skill and experience to design the shared 
data structures so that the mutex-protected operations are short and 
snappy without introducing polling, race conditions, deadlocks or 
starvation. But that polish is needed only for systems where processing 
resources are tight, which is not often the case today.

> The question becomes - how important is determinism in your system? IMO,
> this can be expressed in economic terms - more determinism means fewer
> times the phone rings.

I've been implementing pre-emptive, priority-driven real-time systems, 
off and on, since the mid-80's and never has the phone rung because of 
the non-determinism.

Yes, many customer write requirements saying that they want "simple, 
deterministic scheduling", and then write other requirements for which 
the only clean solution is a pre-emptive system.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

[toc] | [prev] | [next] | [standalone]

#28997

On Friday, January 3, 2020 at 8:41:13 AM UTC-5, pozz wrote:
> I have always worked on non real-time systems, i.e. when the reaction of 
> the system to an event should occur in a reasonable time. For example, 
> when the user presses a button, a motor should start rotating. If the 
> motor starts after 100us or 100ms is not so important.
> 
> I never used RTOS, so the architecture of my firmware is based on 
> "superloop technique" (background tasks running in the loop and interrupts).
> 
> while(1) {
>    task1();
>    task2();
>    ...
> }
> 
> All the tasks don't block, ever. As a rule of thumb, I accept a block 
> time of maximum 100us-1ms. When the task needs to block for a greater 
> amount, I try to implement it as a state-machine, avoiding blocking.
> 
> The ISRs are very lightweight: they only set/get some flags or push/pop 
> a byte to/from FIFO queues.
> With 32-bits MCUs (modern Cortex-M MCUs), I can change 32-bits variables 
> (mainly the ticks of the system) in ISRs without caring of 
> race-conditions that could occur on 8-bits MCUS when the background 
> tasks access the same variables.
> 
> In the past I used this architecture with success even in medium-complex 
> systems featuring Ethernet, lwip, mbedTLS, USB and touchscreen (emWin).
> 
> Sincerely I think this architecture is good enough for all non real-time 
> systems, so I don't understand why to use a RTOS in those cases.
> However I need to use a RTOS (FreeRTOS) for the next project, because it 
> is one of the requirement. It isn't a real-time system, but the RTOS is 
> required.
> 
> I think I can convert my architecture to RTOS by creating a task for 
> each of the function I call in the superloop and starting the OS 
> scheduler. However now the task function can't return, so I can write it 
> in the following way:
> 
> void task1_main(void) {
>    while(1) {
>      task1();
>    }
> }
> 
> task1() can be the *same* function of the superloop architecture.
> 
> I can assign each task the same priority: in this case, FreeRTOS will 
> use round-robin scheduling, giving all the tasks the same opportunity to 
> run.
> 
> Is it correct?

This is why I prefer to code in an HDL where parallel tasks all run concurrently with no swapping of memory or sharing of resources.  Life is so much simpler that way and systems are so less trouble prone. 

-- 

  Rick C.

  - Get 1,000 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#28998

On Fri, 3 Jan 2020 14:41:10 +0100, pozz <pozzugno@gmail.com> wrote:

>I have always worked on non real-time systems, i.e. when the reaction of 
>the system to an event should occur in a reasonable time. For example, 
>when the user presses a button, a motor should start rotating. If the 
>motor starts after 100us or 100ms is not so important.
>
>I never used RTOS, so the architecture of my firmware is based on 
>"superloop technique" (background tasks running in the loop and interrupts).
>
>while(1) {
>   task1();
>   task2();
>   ...
>}
>
>All the tasks don't block, ever. As a rule of thumb, I accept a block 
>time of maximum 100us-1ms. When the task needs to block for a greater 
>amount, I try to implement it as a state-machine, avoiding blocking.
>
>The ISRs are very lightweight: they only set/get some flags or push/pop 
>a byte to/from FIFO queues.
>With 32-bits MCUs (modern Cortex-M MCUs), I can change 32-bits variables 
>(mainly the ticks of the system) in ISRs without caring of 
>race-conditions that could occur on 8-bits MCUS when the background 
>tasks access the same variables.
>
>In the past I used this architecture with success even in medium-complex 
>systems featuring Ethernet, lwip, mbedTLS, USB and touchscreen (emWin).
>
>Sincerely I think this architecture is good enough for all non real-time 
>systems, so I don't understand why to use a RTOS in those cases.
>However I need to use a RTOS (FreeRTOS) for the next project, because it 
>is one of the requirement. It isn't a real-time system, but the RTOS is 
>required.
>
>I think I can convert my architecture to RTOS by creating a task for 
>each of the function I call in the superloop and starting the OS 
>scheduler. However now the task function can't return, so I can write it 
>in the following way:
>
>void task1_main(void) {
>   while(1) {
>     task1();
>   }
>}
>
>task1() can be the *same* function of the superloop architecture.
>
>I can assign each task the same priority: in this case, FreeRTOS will 
>use round-robin scheduling, giving all the tasks the same opportunity to 
>run.
>
>Is it correct?

When you have priority based pre-emptive kernel available, why put
everything on a single priority and run round robin between them ?
Some RTOS systems do not support round-robin but each task must have a
different priority.

Designing some RT application is not hard. 

First you check how time critical each task is and how long it
executes. For non-critical or long execution time tasks assign a
priority level as _low_ as possibly. When most long execution time
tasks gave received some low priority, they are only a few tasks left
that will execute at high priority. Conceptually interrupt service
routines is just a task with highest priority, but of course the ISR
implementation is different.

If there are time critical but long execution time tasks, better split
it into two tasks, the long execution time task and drop its priority
and remaining time critical but short execution task can have a high
priority.

Most of the time, tasks should just waiting for some event, such as an
external event or a message from an other task. In a typical RTOS
application, often all tasks are just waiting for an event and hence
consume no CPU power. Now and then a task becomes runnable, does its
job and then starts to wait for a new event.

In rare occasions a low priority task becomes runnable. After a while
a high priority task becomes runnable, pre-empts the low priority
task, the high priority task does its job and waits for new event and
the interrupted low priority task is resumed and runs to completation.

This is quite similar to systems that allow nested interrupts. Of
course nested interrupts can be avoided by moving the long execution
ISR function to a high priority RTOS task.

  

[toc] | [prev] | [next] | [standalone]

#29003

Il 03/01/2020 21:51, upsidedown@downunder.com ha scritto:
> On Fri, 3 Jan 2020 14:41:10 +0100, pozz <pozzugno@gmail.com> wrote:
> 
>> I have always worked on non real-time systems, i.e. when the reaction of
>> the system to an event should occur in a reasonable time. For example,
>> when the user presses a button, a motor should start rotating. If the
>> motor starts after 100us or 100ms is not so important.
>>
>> I never used RTOS, so the architecture of my firmware is based on
>> "superloop technique" (background tasks running in the loop and interrupts).
>>
>> while(1) {
>>    task1();
>>    task2();
>>    ...
>> }
>>
>> All the tasks don't block, ever. As a rule of thumb, I accept a block
>> time of maximum 100us-1ms. When the task needs to block for a greater
>> amount, I try to implement it as a state-machine, avoiding blocking.
>>
>> The ISRs are very lightweight: they only set/get some flags or push/pop
>> a byte to/from FIFO queues.
>> With 32-bits MCUs (modern Cortex-M MCUs), I can change 32-bits variables
>> (mainly the ticks of the system) in ISRs without caring of
>> race-conditions that could occur on 8-bits MCUS when the background
>> tasks access the same variables.
>>
>> In the past I used this architecture with success even in medium-complex
>> systems featuring Ethernet, lwip, mbedTLS, USB and touchscreen (emWin).
>>
>> Sincerely I think this architecture is good enough for all non real-time
>> systems, so I don't understand why to use a RTOS in those cases.
>> However I need to use a RTOS (FreeRTOS) for the next project, because it
>> is one of the requirement. It isn't a real-time system, but the RTOS is
>> required.
>>
>> I think I can convert my architecture to RTOS by creating a task for
>> each of the function I call in the superloop and starting the OS
>> scheduler. However now the task function can't return, so I can write it
>> in the following way:
>>
>> void task1_main(void) {
>>    while(1) {
>>      task1();
>>    }
>> }
>>
>> task1() can be the *same* function of the superloop architecture.
>>
>> I can assign each task the same priority: in this case, FreeRTOS will
>> use round-robin scheduling, giving all the tasks the same opportunity to
>> run.
>>
>> Is it correct?
> 
> When you have priority based pre-emptive kernel available, why put
> everything on a single priority and run round robin between them ?

Because assigning different priorities to ask avoiding deadlocks could 
be tricky for me, because I have no experience with RTOS.
And because I don't really have higher-priority tasks or hard real-time 
requirements.

> Some RTOS systems do not support round-robin but each task must have a
> different priority.

FreeRTOS supports round-robin in preempetive scheduler when multiple 
tasks with the same priority keep running for too long (see 
configUSETIMESLICING).


> Designing some RT application is not hard.
> 
> First you check how time critical each task is and how long it
> executes. For non-critical or long execution time tasks assign a
> priority level as _low_ as possibly. When most long execution time
> tasks gave received some low priority, they are only a few tasks left
> that will execute at high priority. Conceptually interrupt service
> routines is just a task with highest priority, but of course the ISR
> implementation is different.
> 
> If there are time critical but long execution time tasks, better split
> it into two tasks, the long execution time task and drop its priority
> and remaining time critical but short execution task can have a high
> priority.
> 
> Most of the time, tasks should just waiting for some event, such as an
> external event or a message from an other task. In a typical RTOS
> application, often all tasks are just waiting for an event and hence
> consume no CPU power. Now and then a task becomes runnable, does its
> job and then starts to wait for a new event.
> 
> In rare occasions a low priority task becomes runnable. After a while
> a high priority task becomes runnable, pre-empts the low priority
> task, the high priority task does its job and waits for new event and
> the interrupted low priority task is resumed and runs to completation.
> 
> This is quite similar to systems that allow nested interrupts. Of
> course nested interrupts can be avoided by moving the long execution
> ISR function to a high priority RTOS task.

Yes, the theory is this. I have to apply the theory in practice and 
could reserve some surprises.

I am worried about deadlocks that could occur very infrequently, maybe 
when the product is on the field.

[toc] | [prev] | [next] | [standalone]

#28999

On Fri, 03 Jan 2020 14:41:10 +0100, pozz wrote:

> I have always worked on non real-time systems, i.e. when the reaction of
> the system to an event should occur in a reasonable time. For example,
> when the user presses a button, a motor should start rotating. If the
> motor starts after 100us or 100ms is not so important.
> 
> I never used RTOS, so the architecture of my firmware is based on
> "superloop technique" (background tasks running in the loop and
> interrupts).
> 
> while(1) {
>    task1(); task2(); ...
> }
> 
> All the tasks don't block, ever. As a rule of thumb, I accept a block
> time of maximum 100us-1ms. When the task needs to block for a greater
> amount, I try to implement it as a state-machine, avoiding blocking.
> 
> The ISRs are very lightweight: they only set/get some flags or push/pop
> a byte to/from FIFO queues.
> With 32-bits MCUs (modern Cortex-M MCUs), I can change 32-bits variables
> (mainly the ticks of the system) in ISRs without caring of
> race-conditions that could occur on 8-bits MCUS when the background
> tasks access the same variables.
> 
> In the past I used this architecture with success even in medium-complex
> systems featuring Ethernet, lwip, mbedTLS, USB and touchscreen (emWin).
> 
> Sincerely I think this architecture is good enough for all non real-time
> systems, so I don't understand why to use a RTOS in those cases.
> However I need to use a RTOS (FreeRTOS) for the next project, because it
> is one of the requirement. It isn't a real-time system, but the RTOS is
> required.
> 
> I think I can convert my architecture to RTOS by creating a task for
> each of the function I call in the superloop and starting the OS
> scheduler. However now the task function can't return, so I can write it
> in the following way:
> 
> void task1_main(void) {
>    while(1) {
>      task1();
>    }
> }
> 
> task1() can be the *same* function of the superloop architecture.
> 
> I can assign each task the same priority: in this case, FreeRTOS will
> use round-robin scheduling, giving all the tasks the same opportunity to
> run.
> 
> Is it correct?

It's been a couple of years since I used FreeRTOS.  I downloaded the
latest version recently but have not had time to look at it.
FreeRTOS gives you multiple ways to control a task - semaphores, timers
message queues.  The main entry point of your firmware is going to
setup the various task and then start the scheduler.  The scheduler
will never return.

The scheduler is going to start each task.  The task will do some
initialization, if needed, and then sit in the loop.  The preemptive
scheduler can be a little tricky.  You have to watch for task 
critical sections.  If tasks have a natural blocking point on a
semaphore, timer, queue you can use the non preemptive scheduler.
Tasks can also yield.  If I remember correctly there are APIs to 
notify semaphores and queues from within a ISR.  You have to use 
the correct ones.  A ENET ISR can do some house keeping and notify
the semaphore for the ENET driver task. Blinking a led is a simple 
matter of the task setting the led on, wait on a timer, set the 
led off, wait on timer.  FreeRTOS takes care of all the work of
deciding when to wake up the task waiting on the timer.

There are arguments for and against RTOS but you said you had to use
FreeRTOS.  I think you will find it's easy to use .. BUT ... Read
the docs and have them handy when working on your code.

-- 
Chisolm
Texas-American

[toc] | [prev] | [next] | [standalone]

#29000

On 1/3/20 8:41 AM, pozz wrote:
> I have always worked on non real-time systems, i.e. when the reaction of 
> the system to an event should occur in a reasonable time. For example, 
> when the user presses a button, a motor should start rotating. If the 
> motor starts after 100us or 100ms is not so important.
> 
> I never used RTOS, so the architecture of my firmware is based on 
> "superloop technique" (background tasks running in the loop and 
> interrupts).
> 
> while(1) {
>    task1();
>    task2();
>    ...
> }
> 
> All the tasks don't block, ever. As a rule of thumb, I accept a block 
> time of maximum 100us-1ms. When the task needs to block for a greater 
> amount, I try to implement it as a state-machine, avoiding blocking.
> 
> The ISRs are very lightweight: they only set/get some flags or push/pop 
> a byte to/from FIFO queues.
> With 32-bits MCUs (modern Cortex-M MCUs), I can change 32-bits variables 
> (mainly the ticks of the system) in ISRs without caring of 
> race-conditions that could occur on 8-bits MCUS when the background 
> tasks access the same variables.
> 
> In the past I used this architecture with success even in medium-complex 
> systems featuring Ethernet, lwip, mbedTLS, USB and touchscreen (emWin).
> 
> Sincerely I think this architecture is good enough for all non real-time 
> systems, so I don't understand why to use a RTOS in those cases.
> However I need to use a RTOS (FreeRTOS) for the next project, because it 
> is one of the requirement. It isn't a real-time system, but the RTOS is 
> required.
> 
> I think I can convert my architecture to RTOS by creating a task for 
> each of the function I call in the superloop and starting the OS 
> scheduler. However now the task function can't return, so I can write it 
> in the following way:
> 
> void task1_main(void) {
>    while(1) {
>      task1();
>    }
> }
> 
> task1() can be the *same* function of the superloop architecture.
> 
> I can assign each task the same priority: in this case, FreeRTOS will 
> use round-robin scheduling, giving all the tasks the same opportunity to 
> run.
> 
> Is it correct?

I would likely make the loop:

     while(1){
         task1();
         taskYield();
     }

so that after task1 finishes what it was doing, you automatically roll 
to the next task rather than looping task1 for a full tick period, then 
switching to task2(), and so on. If the tasks naturally block/yield 
within them, then that isn't as needed.

Also, at that point you can undo all of your state-machining that was 
just to return and then resume where you left off. Which may make the 
code clearer.

The one difficulty is that, as has been mentioned, when two (or more) 
tasks share data, you need to add the needed protections to the access 
as they can now be effectively simultaneous. (Not really if it is a 
single core processor, but you can switch from one task to another at 
virtually arbitrary points)

As others have said, you can perhaps start with a single task written as 
before, and as you find the reasons they wanted an RTOS, move just that 
part into a separate task, maybe at a higher priority level.

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.arch.embedded

csiph-web