Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29003
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Task priorities in non strictly real-time systems |
| Date | 2020-01-05 01:48 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <qurbof$nmk$1@dont-email.me> (permalink) |
| References | <qung9m$m79$1@dont-email.me> <s48v0f1a02i9oeoumh1hmq8enuc8slo2to@4ax.com> |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web