Groups | Search | Server Info | Login | Register

Groups > comp.realtime > #627

Re: How is FREE RTOS?

Show all headers | View raw

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!

Back to comp.realtime | Previous | Next — Previous in thread | Find similar

Thread

How is FREE RTOS? Ed Prochak <edprochak@gmail.com> - 2023-11-12 17:40 -0800
  Re: How is FREE RTOS? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-11-13 12:22 +0200
  Re: How is FREE RTOS? Don Y <blockedofcourse@foo.invalid> - 2023-11-13 13:00 -0700
    Re: How is FREE RTOS? Ed Prochak <edprochak@gmail.com> - 2023-11-14 12:30 -0800
      Re: How is FREE RTOS? Don Y <blockedofcourse@foo.invalid> - 2023-11-14 20:20 -0700
        Re: How is FREE RTOS? Ed Prochak <edprochak@gmail.com> - 2023-11-15 20:06 -0800
          Re: How is FREE RTOS? Don Y <blockedofcourse@foo.invalid> - 2023-11-16 05:31 -0700
            Re: How is FREE RTOS? Ed Prochak <edprochak@gmail.com> - 2023-11-17 19:08 -0800
              Re: How is FREE RTOS? Don Y <blockedofcourse@foo.invalid> - 2023-11-18 13:08 -0700

csiph-web