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

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

Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Robert Wessel <robertwessel2@yahoo.com> - 2017-12-09 23:34 -0600
    Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? pozz <pozzugno@gmail.com> - 2017-12-11 14:19 +0100
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Ed Prochak <edprochak@gmail.com> - 2017-12-15 10:45 -0800
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2017-12-16 11:57 -0600
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Grant Edwards <invalid@invalid.invalid> - 2017-12-16 19:09 +0000
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? upsidedown@downunder.com - 2017-12-16 22:14 +0200
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-12-16 23:19 +0000

#27460 — Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)?

On Sat, 9 Dec 2017 17:05:51 +0100, pozz <pozzugno@gmail.com> wrote:

Mainly it's a question of complexity.  If you need complex services,
say networking, threading, UI, storage, there a lot to be said for an
RTOS - getting those right is a ton of work, and you probably have
better things to do.  If you have a simple device, that needs only
basic functionality, say there's only a limited amount of ROM based
code, a couple of interrupts to handle, and mainly just interaction
with whatever you're controlling, do without.  There is, of course, a
huge grey area between those two, and RTOS come in a number of levels
of complexity as well.

[toc] | [next] | [standalone]

#27462

Il 10/12/2017 06:34, Robert Wessel ha scritto:
> On Sat, 9 Dec 2017 17:05:51 +0100, pozz <pozzugno@gmail.com> wrote:
> 
> Mainly it's a question of complexity.  If you need complex services,
> say networking, threading, UI, storage, there a lot to be said for an
> RTOS - getting those right is a ton of work, and you probably have
> better things to do.  

In the past I worked with networking (lwip), UI (emwin) and storage 
(fatfs) without an RTOS, even if one at a time.  All of them can be used 
with and without a RTOS.  The "infinite loop" method worked well for these.

Maybe the only serious drawback I noticed is that MCU is continuously 
polling something.  This isn't efficient if you need low power consumption.


 > threading

Good point.  Multi-threading is a good thing... but it's not simple to 
move from a "bare-metal" model to a "multi-threading" approach.  You 
have to face unseen problems, like sharing resources among different 
threads.


> If you have a simple device, that needs only
> basic functionality, say there's only a limited amount of ROM based
> code, a couple of interrupts to handle, and mainly just interaction
> with whatever you're controlling, do without.  There is, of course, a
> huge grey area between those two, and RTOS come in a number of levels
> of complexity as well.
> 

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

#27464

On Monday, December 11, 2017 at 8:19:31 AM UTC-5, pozz wrote:
[]
> 
> In the past I worked with networking (lwip), UI (emwin) and storage 
> (fatfs) without an RTOS, even if one at a time.  All of them can be used 
> with and without a RTOS.  The "infinite loop" method worked well for these.
> 
Both Mike and Robert made good points. You need to examine your requirements.

> Maybe the only serious drawback I noticed is that MCU is continuously 
> polling something.  This isn't efficient if you need low power consumption.
> 
Was this in your loop application?

An RTOS may have features for low power that would be difficult to
create in a simple loop implementation.
> 
>  > threading
> 
> Good point.  Multi-threading is a good thing... but it's not simple to 
> move from a "bare-metal" model to a "multi-threading" approach.  You 
> have to face unseen problems, like sharing resources among different 
> threads.
> 
Yes it can be a little more work, but the Grand Do All Loop can have
the other problem: Each routine in the given state is called whether
it needs to execute or not. So you still may be delayed in getting
to that one function that has to run NOW.

My point is, the design planning needed for multi-threaded RTOS
is more complex, but how often have you coded a bare metal multi-threaded system. If you want the benefits of threading, there is a cost to pay.
Overall, the system can be more efficient with a multithreaded RTOS.


One last comment: some folks gravitate automatically to the Do All loop.
Don't choose that just because you think an RTOS is too much overhead
(e.g. task swapping). In many cases, the overhead of an RTOS is a
lot lower than you might think. and the brain power needed to program
in an RTOS environment can be lower too.

I remember working on one system that you had to count the number
of instructions you were executing between checkpoints because the
Do All loop was trying to maintain a clock.
A real pain to make changes!

So the pain can go both ways.

HTH,
  ed

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

#27466

pozz wrote:
> Il 10/12/2017 06:34, Robert Wessel ha scritto:
>> On Sat, 9 Dec 2017 17:05:51 +0100, pozz <pozzugno@gmail.com> wrote:
>>
>> Mainly it's a question of complexity.  If you need complex services,
>> say networking, threading, UI, storage, there a lot to be said for an
>> RTOS - getting those right is a ton of work, and you probably have
>> better things to do. 
> 
> In the past I worked with networking (lwip), UI (emwin) and storage 
> (fatfs) without an RTOS, even if one at a time.  All of them can be used 
> with and without a RTOS.  The "infinite loop" method worked well for these.
> 
> Maybe the only serious drawback I noticed is that MCU is continuously 
> polling something.  This isn't efficient if you need low power consumption.
> 
> 
>  > threading
> 
> Good point.  Multi-threading is a good thing... but it's not simple to 
> move from a "bare-metal" model to a "multi-threading" approach.  You 
> have to face unseen problems, like sharing resources among different 
> threads.
> 
> 

It can get fiddly ( especially with respect to shared resources between
ISRs and "app space" ) but you can always divide things into control 
blocks and have one "thread" per control block. Each control block 
contains almost all the state for one "thread". "Almost" - you'll still 
need stuff to talk to ISRs.

This will work in or outside of an RTOS. If an RTOS offers a killer
service - something that would be too expensive to recreate ( I'm
thinking of power management ) - then you can migrate to an RTOS with a
minimum of fuss. I'd suggest making the  RTOS non-preemptive in that case.

And since you now have stuff partitioned into control blocks, might as
well make it state machines. That way you can put code in to hedge race 
conditions and make it all truly event-driven.

Plus, out of hardware timers? Write a hardware timer-queue mux with 
callbacks.

And if you're careful with C++ compilers, the actual code looks
suspiciously the same - the local state per thread is all class members
rather than control_block[curblock].<something>.

The main thing is how allocation is managed - what's the
ctors()/dtors() story?

>> If you have a simple device, that needs only
>> basic functionality, say there's only a limited amount of ROM based
>> code, a couple of interrupts to handle, and mainly just interaction
>> with whatever you're controlling, do without.  There is, of course, a
>> huge grey area between those two, and RTOS come in a number of levels
>> of complexity as well.
>>
> 

-- 
Les Cargill

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

#27468

On 2017-12-11, pozz <pozzugno@gmail.com> wrote:

> Good point.  Multi-threading is a good thing... but it's not simple
> to move from a "bare-metal" model to a "multi-threading" approach.
> You have to face unseen problems, like sharing resources among
> different threads.

I don't see how it's "unforseen".  It's not much different than
sharing resources among different interrupt routines and the
foreground process in a "bare-metal" approach.

-- 
Grant

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

#27469

On Mon, 11 Dec 2017 14:19:28 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 10/12/2017 06:34, Robert Wessel ha scritto:
>> On Sat, 9 Dec 2017 17:05:51 +0100, pozz <pozzugno@gmail.com> wrote:
>> 
>> Mainly it's a question of complexity.  If you need complex services,
>> say networking, threading, UI, storage, there a lot to be said for an
>> RTOS - getting those right is a ton of work, and you probably have
>> better things to do.  
>
>In the past I worked with networking (lwip), UI (emwin) and storage 
>(fatfs) without an RTOS, even if one at a time.  All of them can be used 
>with and without a RTOS.  The "infinite loop" method worked well for these.
>
>Maybe the only serious drawback I noticed is that MCU is continuously 
>polling something.  This isn't efficient if you need low power consumption.
>
>
> > threading
>
>Good point.  Multi-threading is a good thing... but it's not simple to 
>move from a "bare-metal" model to a "multi-threading" approach.  You 
>have to face unseen problems, like sharing resources among different 
>threads.
>
>
>> If you have a simple device, that needs only
>> basic functionality, say there's only a limited amount of ROM based
>> code, a couple of interrupts to handle, and mainly just interaction
>> with whatever you're controlling, do without.  There is, of course, a
>> huge grey area between those two, and RTOS come in a number of levels
>> of complexity as well.
>> 

An RTOS can be quite primitive.

Just allocate a private stack for each task and a small control block.
The simplest system just used a 3 byte control bytes for each task, 2
bytes for the saved stack pointer and a single byte for the task state
(mainly runnable/non-runnable bit).  

After each interupt or system call, just scan the task status bytes in
a fixed priority order to find the first task in runnable state, load
that stack pointer and perform return from interrupt and off you go
with the new task :-) . 

A more elaborate design would check if the same task is going to
continue after a system call and continue without doing a
(software)interrupt register save/restore each time.
 

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

#27470

On 11/12/17 13:19, pozz wrote:

> Good point.  Multi-threading is a good thing... but it's not simple to move
> from a "bare-metal" model to a "multi-threading" approach.  You have to face
> unseen problems, like sharing resources among different threads.

It is if you have a good solid theoretical background with
tools that implement the theory.

Start by having a single core dedicated to each I/O device,
with many cores, and with a programming paradigm that lets
all the cores communicate with each other.

Previous embodiment was the Transputer and Occam, current
embodiment is the XMOS xCORE processors and xC. See DigiKey
for pricing and pointers to the 30,000ft architectural
overviews.

Effectively the RTOS is cast in silicon.

No interrupts; each core sleeps until there is something
for it to do, e.g. input, output, or messages to other
cores.

Add no caches and the min/max execution times can defined
by the IDE examining the optimised object code.

All in all it is a surprisingly pleasant and mature system.

[toc] | [prev] | [standalone]

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

csiph-web