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

Groups > comp.arch.embedded > #27466

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

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web