How is FREE RTOS?

[Ed Prochak]

Hi to anyone still listening here.

Any opinions about FREE RTOS?
I like priority scheduling, but are there any significant
issues or just annoying features?

That's all.
Ed

[Niklas Holsti]

On 2023-11-13 3:40, Ed Prochak wrote:
> Hi to anyone still listening here.

Hello! Very little traffic on this group.

> Any opinions about FREE RTOS?
> I like priority scheduling, but are there any significant
> issues or just annoying features?

I have no experience with Free RTOS, but I have not seen any complaints
from its users.

I would ask (also) on comp.arch.embedded, it is a much more active group.

[Don Y]

On 11/12/2023 6:40 PM, Ed Prochak wrote:
> Hi to anyone still listening here.
>
> Any opinions about FREE RTOS?

It's been around for quite a while which makes you wonder how
much "extra cruft" (bloat) it has accumulated -- that may not
be essential for any specific application.

[Software tends to grow when it should, instead, *shrink*
to add value]

> I like priority scheduling, but are there any significant
> issues or just annoying features?

*Why* do you like /priority/ scheduling? Have you sorted out how
you will assign priorities (or, do you plan on rejiggering them
once you see how the code *runs*?)

Have you identified the *minimum* set of features/services
that you need/expect from the OS? And, how that fits with
those offered?

[Do you even need timeliness guarantees or are you just looking
for an MTOS?]

Do you need others to be able to use your codebase (and thus
the OS)?

Any piece of code "of size" will have bugs. The question is,
which of those bugs will bite *you* and how severe their
consequences.

> That's all.
> Ed

[Ed Prochak]

On Monday, November 13, 2023 at 3:00:51 PM UTC-5, Don Y wrote:
> On 11/12/2023 6:40 PM, Ed Prochak wrote:
> > Hi to anyone still listening here.
> >
> > Any opinions about FREE RTOS?
> It's been around for quite a while which makes you wonder how
> much "extra cruft" (bloat) it has accumulated -- that may not
> be essential for any specific application.
>
> [Software tends to grow when it should, instead, *shrink*
> to add value]
> > I like priority scheduling, but are there any significant
> > issues or just annoying features?
> *Why* do you like /priority/ scheduling? Have you sorted out how
> you will assign priorities (or, do you plan on rejiggering them
> once you see how the code *runs*?)

For small embedded systems, I've found this kind of kernel
very efficient.

>
> Have you identified the *minimum* set of features/services
> that you need/expect from the OS? And, how that fits with
> those offered?

No, I haven't seen the product requirement document yet.
But from the verbal product description This kernel should be
more than adequate.

>
> [Do you even need timeliness guarantees or are you just looking
> for an MTOS?]

There's definitely some timeliness requirements. It is a medical device.

>
> Do you need others to be able to use your codebase (and thus
> the OS)?

No. This is product specific.

>
> Any piece of code "of size" will have bugs. The question is,
> which of those bugs will bite *you* and how severe their
> consequences.

Thanks Don. And I will post over in .embedded group. I was just hoping
to stir up some discussion here for a change. 8^)

Enjoy,
Ed

[Don Y]

On 11/14/2023 1:30 PM, Ed Prochak wrote:
> On Monday, November 13, 2023 at 3:00:51 PM UTC-5, Don Y wrote:
>> On 11/12/2023 6:40 PM, Ed Prochak wrote:
>>> Hi to anyone still listening here.
>>>
>>> Any opinions about FREE RTOS?
>> It's been around for quite a while which makes you wonder how
>> much "extra cruft" (bloat) it has accumulated -- that may not
>> be essential for any specific application.
>>
>> [Software tends to grow when it should, instead, *shrink*
>> to add value]
>>> I like priority scheduling, but are there any significant
>>> issues or just annoying features?
>> *Why* do you like /priority/ scheduling? Have you sorted out how
>> you will assign priorities (or, do you plan on rejiggering them
>> once you see how the code *runs*?)
>
> For small embedded systems, I've found this kind of kernel
> very efficient.

You may want to, also, look at uCOS and ThreadX -- assuming
"free" is one of your concerns. The problem with priority based
schedulers is they only indirectly address timeliness design goals:
if X is higher priority than Y will X finish before (or after?)
Y? Will X finish in time for its deadline (which isn't encoded
anywhere)?

>> Have you identified the *minimum* set of features/services
>> that you need/expect from the OS? And, how that fits with
>> those offered?
>
> No, I haven't seen the product requirement document yet.
> But from the verbal product description This kernel should be
> more than adequate.

A lot will depend on how much folks have envisioned your
device as a "computer" vs. "appliance". Lots of (often
unnecessary) bloat gets added to design goals based
on perceptions of what COULD be available (despite not
being strictly necessary)

>> [Do you even need timeliness guarantees or are you just looking
>> for an MTOS?]
>
> There's definitely some timeliness requirements. It is a medical device.

Cyclic Executive, instead?

>> Do you need others to be able to use your codebase (and thus
>> the OS)?
>
> No. This is product specific.

So, things like Posix aren't essential...

>> Any piece of code "of size" will have bugs. The question is,
>> which of those bugs will bite *you* and how severe their
>> consequences.
>
> Thanks Don. And I will post over in .embedded group. I was just hoping
> to stir up some discussion here for a change. 8^)

USENET is largely obsolescent. Most discussions, now,
seem to happen on (closed) email lists -- especially where
disclosure may be a concern -- or in (moderated) "forums".

Good luck!

[Ed Prochak]

On Tuesday, November 14, 2023 at 10:20:11 PM UTC-5, Don Y wrote:
> On 11/14/2023 1:30 PM, Ed Prochak wrote:
> > On Monday, November 13, 2023 at 3:00:51 PM UTC-5, Don Y wrote:
> >> On 11/12/2023 6:40 PM, Ed Prochak wrote:

[]

> > For small embedded systems, I've found this kind of kernel
> > very efficient.
> You may want to, also, look at uCOS and ThreadX -- assuming
> "free" is one of your concerns. The problem with priority based
> schedulers is they only indirectly address timeliness design goals:
> if X is higher priority than Y will X finish before (or after?)
> Y? Will X finish in time for its deadline (which isn't encoded
> anywhere)?

Well, this is a maintenance/update project, so I did not make the choice.

> >> Have you identified the *minimum* set of features/services
> >> that you need/expect from the OS? And, how that fits with
> >> those offered?
> >
> > No, I haven't seen the product requirement document yet.
> > But from the verbal product description This kernel should be
> > more than adequate.
> A lot will depend on how much folks have envisioned your
> device as a "computer" vs. "appliance". Lots of (often
> unnecessary) bloat gets added to design goals based
> on perceptions of what COULD be available (despite not
> being strictly necessary)

This is definitely in the appliance category.

> >> [Do you even need timeliness guarantees or are you just looking
> >> for an MTOS?]
> >
> > There's definitely some timeliness requirements. It is a medical device.
> Cyclic Executive, instead?

Cyclic executives are difficult to enhance it you happen to add features that now
extend the timing cycle.

[]

> > Thanks Don. And I will post over in .embedded group. I was just hoping
> > to stir up some discussion here for a change. 8^)
> USENET is largely obsolescent. Most discussions, now,
> seem to happen on (closed) email lists -- especially where
> disclosure may be a concern -- or in (moderated) "forums".
>
> Good luck!

We'll see if this sparks others to at least peek in.
I see I got two responses, you and Niklas.

Thank , Niklas for your response too.

Enjoy the run.
Ed

[Don Y]

On 11/15/2023 9:06 PM, Ed Prochak wrote:
> On Tuesday, November 14, 2023 at 10:20:11 PM UTC-5, Don Y wrote:
>> On 11/14/2023 1:30 PM, Ed Prochak wrote:
>>> On Monday, November 13, 2023 at 3:00:51 PM UTC-5, Don Y wrote:
>>>> On 11/12/2023 6:40 PM, Ed Prochak wrote:
> []
>>> For small embedded systems, I've found this kind of kernel
>>> very efficient.
>> You may want to, also, look at uCOS and ThreadX -- assuming
>> "free" is one of your concerns. The problem with priority based
>> schedulers is they only indirectly address timeliness design goals:
>> if X is higher priority than Y will X finish before (or after?)
>> Y? Will X finish in time for its deadline (which isn't encoded
>> anywhere)?
>
> Well, this is a maintenance/update project, so I did not make the choice.

So, it's not "from scratch" but, rather, a reuse of an existing
*design* (though not necessarily *implementation*) refactored
to add some new set of features/behavior -- ?

If that's the case -- and it was "designed" with a priority-based
RTOS at its core (that you can't/won't reuse, for whatever reason),
-- make sure you are aware of how *that* behaved in all applicable
use cases. Else, a new RTOS may have slightly different policy
implementations that can cause subtle (but important) differences
in some cases.

E.g., if the old implemented Priority Ceiling Protocol while
the new implements Priority Inheritance Protocol, there will
be marked differences in how those conflicts are resolved
in terms of execution time. (Or, if the old didn't address
this, at all, and just left things entirely to chance).

Or, if the old wasn't preemptive while the new is.

Or, if the old only allowed preemption at specific places.

Or, ...

[i.e., all are not created equally]

>>>> Have you identified the *minimum* set of features/services
>>>> that you need/expect from the OS? And, how that fits with
>>>> those offered?
>>>
>>> No, I haven't seen the product requirement document yet.
>>> But from the verbal product description This kernel should be
>>> more than adequate.
>> A lot will depend on how much folks have envisioned your
>> device as a "computer" vs. "appliance". Lots of (often
>> unnecessary) bloat gets added to design goals based
>> on perceptions of what COULD be available (despite not
>> being strictly necessary)
>
> This is definitely in the appliance category.

As long as someone didn't "imagine": "Gee, we can store the
settings in a (genuine) *file* in one of the filesystems supported
by the kernel" or similar. (Thereby placing an added dependency
on the kernel that wasn't strictly necessary.)

[I really like to find ways to REMOVE code from designs
instead of finding uses for code that doesn't have to be there!]

>>>> [Do you even need timeliness guarantees or are you just looking
>>>> for an MTOS?]
>>>
>>> There's definitely some timeliness requirements. It is a medical device.
>> Cyclic Executive, instead?
>
> Cyclic executives are difficult to enhance it you happen to add features that now
> extend the timing cycle.

Yes. But, that is also true of other scheduling approaches.
Priority-based schedulers often find their developers
rejiggering priorities to "make things work" (shouldn't they
continue to work if they were jiggered properly to begin with?)

>>> Thanks Don. And I will post over in .embedded group. I was just hoping
>>> to stir up some discussion here for a change. 8^)
>> USENET is largely obsolescent. Most discussions, now,
>> seem to happen on (closed) email lists -- especially where
>> disclosure may be a concern -- or in (moderated) "forums".
>>
>> Good luck!
>
> We'll see if this sparks others to at least peek in.
> I see I got two responses, you and Niklas.
>
> Thank , Niklas for your response too.
>
> Enjoy the run.

Good Luck!

[Ed Prochak]

On Thursday, November 16, 2023 at 7:31:34 AM UTC-5, Don Y wrote:
> On 11/15/2023 9:06 PM, Ed Prochak wrote:
> > On Tuesday, November 14, 2023 at 10:20:11 PM UTC-5, Don Y wrote:
> >> On 11/14/2023 1:30 PM, Ed Prochak wrote:
> >>> On Monday, November 13, 2023 at 3:00:51 PM UTC-5, Don Y wrote:
> >>>> On 11/12/2023 6:40 PM, Ed Prochak wrote:
> > []
> >>> For small embedded systems, I've found this kind of kernel
> >>> very efficient.
> >> You may want to, also, look at uCOS and ThreadX -- assuming
> >> "free" is one of your concerns. The problem with priority based
> >> schedulers is they only indirectly address timeliness design goals:
> >> if X is higher priority than Y will X finish before (or after?)
> >> Y? Will X finish in time for its deadline (which isn't encoded
> >> anywhere)?
> >
> > Well, this is a maintenance/update project, so I did not make the choice.
> So, it's not "from scratch" but, rather, a reuse of an existing
> *design* (though not necessarily *implementation*) refactored
> to add some new set of features/behavior -- ?
>
> If that's the case -- and it was "designed" with a priority-based
> RTOS at its core (that you can't/won't reuse, for whatever reason),
> -- make sure you are aware of how *that* behaved in all applicable
> use cases. Else, a new RTOS may have slightly different policy
> implementations that can cause subtle (but important) differences
> in some cases.

Don, I'm going to assume you are writing these comments for other readers.
I've been doing this kind of work for a LONG time, especially taking over
maintenance and enhancement of a system.

I will be looking for those issues that you described in your comments.
I will also be looking for these items of interest:
how are source materials (requirements, design, code) maintained?
what are the quality control processes?
What are the build tools and processes (and how are they maintained)?
what are the known defects?
How are defects documented and processed?
And more.

Thanks for your thoughts.
Ed

[Don Y]

On 11/17/2023 8:08 PM, Ed Prochak wrote:
> Don, I'm going to assume you are writing these comments for other readers.
> I've been doing this kind of work for a LONG time, especially taking over
> maintenance and enhancement of a system.

Sorry, Ed, I don't mean to "preach" as much as "caution". I've had to
dig into other folks' work many times, over the years, and have come to
realize that many developers treat the OS as a "black box" -- with no
real interest in what it ACTUALLY does (i.e., HOW it does it).

Instead, they IMAGINE what it should be doing -- a fuzzy sort of
conceptualization -- and, as testing those ideas is tedious, they
just rely on their instincts.

If the OS in the earlier version of your device wasn't completely
characterized, its likely that a new choice may yield different
performance in some of the "corner cases" that inevitably pop
up, at run time -- but can't be coerced to manifesting during testing.

I've seen priority-based schedulers that didn't do anything to
guard against inversion (fine if the situation never turns up
in the application *or* if it can sort itself out, over time).
I've seen PCP (incorrectly) implemented as priority-max-possible
(which distorts the whole priority scheme). I've seen PIP
implemented incorrectly.

I've seen mutexes that will block if the current holder tries to take it
a SECOND time (while holding it). And, other implementations where a
second attempt is granted but the first release releases ALL holds. Etc.

But, when folks look at an OS selection, they just tend to look at
feature lists: what do they use for communications? how many
priority levels? support for semaphores? etc. Unless you know
(or can access) the individual who made the initial selection,
its hard to know what details were overlooked or emphasized.

The devil is always in the details (which aren't often published)

> I will be looking for those issues that you described in your comments.
> I will also be looking for these items of interest:
> how are source materials (requirements, design, code) maintained?
> what are the quality control processes?
> What are the build tools and processes (and how are they maintained)?
> what are the known defects?
> How are defects documented and processed?
> And more.

Much of that boils down to process. That will be "highly personal"
(from the standpoint of the client) and fungible to some extent
(depending on how pedantic they want to be).

Other things you might want to address are bug tracking DURING
development, envisioned future enhancements (so you consider
them in the foundation you lay), LIKELIHOOD of those enhancements,
likelihood that the hardware will change before they come about,
etc.

> Thanks for your thoughts.

Good luck!