Embedded RTOS - features poll

Greetings,

I am writing my own RTOS, which I intend to use in my projects and
license for anyone who would like to use it. At first I will use it in
my own projects, so that it achieves a certain level of real-life
performance and stability, then release it.

The idea is to employ a "classic" embedded RTOS design (single address
space, multiple tasks, "hard" RT scheduling) with as much common
interfaces as possible (POSIX I/O, sockets, pthreads, standard C
library), with small storage and RAM footprint, with much higher
responsiveness than most of OS commonly used and without a need in
MMU. There's no need in a filesystem, everything runs from a single
binary. Most of the components are optional, it's easy even to use the
OS without a task manager as one big loop but with h/w, memory
management and filesystems support, for example.

I intend to use it in projects that would otherwise use embedded
Linux, but need better performance / responsiveness / free resources,
without increase in platform's cost. I experienced and witnessed many
problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
software quality, support and unnecessary amount of proprietary
interfaces where industry-standard interfaces exist. I believe that
those problems with dedicated RTOSes led to embedded Linux taking over
areas for which Linux wasn't even intended, and I hope to offer
similar (to Linux'es) advantages over them.

For now I want to give a shape to my offer and strengthen the most
popular use cases for the OS. I don't have resources to make it
"relatively good for anything" like Linux, and I don't want to take
this direction in order to not complicate interfaces and development
procedures.

Now I'd like to ask everybody who is willing to express his/her
opinion (as applicable):

- What features, supported architectures/platforms/hardware support,
interfaces and available frameworks would make you use a new OS (if
you already use an RTOS)?

- Why wouldn't you use a new OS (if you don't like the whole idea or
you're satisfied with the existing offer, etc.)?

- What will make you use an OS (if you currently don't use an OS at
all)?

Please write what platform(s) your answer relates to and what is the
project's field (even in general terms, e.g. "low-end media gateway",
"network filtering appliance", "high-end router", "surveillance DVR",
"IP camera" etc.)

Thanks,
Daniel

On 19/09/2010 16:31, Stargazer wrote:
> Greetings,
>=20
> I am writing my own RTOS, which I intend to use in my projects and
> license for anyone who would like to use it. At first I will use it in
> my own projects, so that it achieves a certain level of real-life
> performance and stability, then release it.
>=20
> The idea is to employ a "classic" embedded RTOS design (single address
> space, multiple tasks, "hard" RT scheduling) with as much common
> interfaces as possible (POSIX I/O, sockets, pthreads, standard C
> library), with small storage and RAM footprint, with much higher
> responsiveness than most of OS commonly used and without a need in
> MMU. There's no need in a filesystem, everything runs from a single
> binary. Most of the components are optional, it's easy even to use the
> OS without a task manager as one big loop but with h/w, memory
> management and filesystems support, for example.
>=20
> I intend to use it in projects that would otherwise use embedded
> Linux, but need better performance / responsiveness / free resources,
> without increase in platform's cost. I experienced and witnessed many
> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
> software quality, support and unnecessary amount of proprietary
> interfaces where industry-standard interfaces exist. I believe that
> those problems with dedicated RTOSes led to embedded Linux taking over
> areas for which Linux wasn't even intended, and I hope to offer
> similar (to Linux'es) advantages over them.
>=20
> For now I want to give a shape to my offer and strengthen the most
> popular use cases for the OS. I don't have resources to make it
> "relatively good for anything" like Linux, and I don't want to take
> this direction in order to not complicate interfaces and development
> procedures.
>=20
> Now I'd like to ask everybody who is willing to express his/her
> opinion (as applicable):
>=20
> - What features, supported architectures/platforms/hardware support,
> interfaces and available frameworks would make you use a new OS (if
> you already use an RTOS)?
>=20
> - Why wouldn't you use a new OS (if you don't like the whole idea or
> you're satisfied with the existing offer, etc.)?
>=20
> - What will make you use an OS (if you currently don't use an OS at
> all)?
>=20
> Please write what platform(s) your answer relates to and what is the
> project's field (even in general terms, e.g. "low-end media gateway",
> "network filtering appliance", "high-end router", "surveillance DVR",
> "IP camera" etc.)
>=20
> Thanks,
> Daniel
>=20
>=20

Just what the world needs - another RTOS.  Line up.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T=DCV as meeting the requirements for safety related systems=
=2E

--=20

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by T=DCV as meeting the requirements for safety related systems=
=2E

Stargazer wrote:

> Greetings,
> 
> I am writing my own RTOS, which I intend to use in my projects and
> license for anyone who would like to use it. At first I will use it in
> my own projects, so that it achieves a certain level of real-life
> performance and stability, then release it.
 
The question you should ask is:- "Do you really need an RTOS for the 
application?". It can often be surprising to list the feature set you need 
and see how you can do that easily without the RTOS. However, when you need 
an RTOS you need to have a really good one.

As one who uses Forth for quite a number of things, I have never felt the 
need to think of needing an RTOS. If I am dealing with an application that 
is so complex that it needs an RTOS then I am usually into the realms of 
commercial PLC's which already come with one. 

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Hi Daniel,

[comments interspersed with no real intent at a cogent argument]

Stargazer wrote:

> I am writing my own RTOS, which I intend to use in my projects and
> license for anyone who would like to use it. At first I will use it in
> my own projects, so that it achieves a certain level of real-life
> performance and stability, then release it.

If you've not written an RTOS before, I would suggest you add a
step *before* "public release" (I would actually suggest you add it
before you finish any of *your* projects, as well!):  namely,
"lather, rinse, repeat".  You'll find many of the classic features
offered in MTOS's and RTOS's are, in practice, redundant and/or
superfluous.  Once you've *used* them, you will be able to recognize
which fit this mold and how you can trim down a "bullet point
feature list to a true *core* of useful features -- though you might
have to look at things in a different way to see the duality hidden
there.  Then, revise your platform to more effectively use a smaller
set of features (IMO, this has led to more robust and responsive
implementations)

> The idea is to employ a "classic" embedded RTOS design (single address
> space, multiple tasks, "hard" RT scheduling) with as much common
> interfaces as possible (POSIX I/O, sockets, pthreads, standard C
> library), with small storage and RAM footprint, with much higher

It looks like you are already following the "kitchen sink" approach.
Where is your priority:  footprint (TEXT/DATA) or features?

> responsiveness than most of OS commonly used and without a need in
> MMU. There's no need in a filesystem, everything runs from a single

Note that "filesystem" need not carry the bloat of a *disk* (or
"memory") filesystem.  E.g., I like using fwrite, fread, etc.
in my "tasks" (lets not argue terminology) with the sort of interface
one typically thinks of with a namespace residing atop a filesystem.

> binary. Most of the components are optional, it's easy even to use the
> OS without a task manager as one big loop but with h/w, memory
> management and filesystems support, for example.

Wait -- first *no* filesystem ("no need in a filesystem") now there
*is* one ("with ... and filesystems support")?  Or, have I misread
something?

> I intend to use it in projects that would otherwise use embedded
> Linux, but need better performance / responsiveness / free resources,
> without increase in platform's cost. I experienced and witnessed many
> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
> software quality, support and unnecessary amount of proprietary
> interfaces where industry-standard interfaces exist. I believe that

"Proprietary interfaces" need not be *closed* interfaces.
E.g., you can design your API in such a way that it offers
the same functionality as "industry-standard interfaces"
without adopting the same *syntax* as them.

Personally, I find products that *tout* "industry standard"
API's more annoying than those that make no effort to "fit"
those molds.  How often do you dig through such an API and
then discover something is "not supported" -- for what the
vendor/developer *thinks* was a "good reason".  (e.g., does
your C library support fread, fwrite, fseek, etc.?  Or, do
you want to rely on the RATIONALIZATION that not supporting a
filesystem means you don't have to support these functions?
etc.)

> those problems with dedicated RTOSes led to embedded Linux taking over
> areas for which Linux wasn't even intended, and I hope to offer
> similar (to Linux'es) advantages over them.

I think you will find the biggest hook to acceptance is ease
of development.  I.e., if you can write your code on platform X
and port it to playform Y (think:  X == desktop PC, Y == embedded
hardware) then folks are more likely to use it (since most
folks are lacking hardware skills and could never build on bare iron)

> For now I want to give a shape to my offer and strengthen the most
> popular use cases for the OS. I don't have resources to make it
> "relatively good for anything" like Linux, and I don't want to take
> this direction in order to not complicate interfaces and development
> procedures.
> 
> Now I'd like to ask everybody who is willing to express his/her
> opinion (as applicable):
> 
> - What features, supported architectures/platforms/hardware support,
> interfaces and available frameworks would make you use a new OS (if
> you already use an RTOS)?
> 
> - Why wouldn't you use a new OS (if you don't like the whole idea or
> you're satisfied with the existing offer, etc.)?

Because an {MT,RT}OS is such a tiny part of a real application!
Why bother figuring out how to *bend* someone else's design to
fit the needs of your application?

I typically write a new {MT,RT}OS for each application to best
suit the needs of *that* application (my software is usually a
tight fit with the resources available in a particular application).
Of course, much of this effort is cutting and pasting from previous
designs -- with suitable tweaks to data types, algorithm enhancements,
other architectural consequences, etc.  (the same sort of effort
applies to my libraries as they can often be tweaked to better fit
the application than a "one size fits all" implementation)

Rather than focus on writing something that (you *hope*!) others
can reuse, I would, instead, suggest you look harder at what you
could do to better fit your "OS" to the needs of *your* applications
("projects").  Explore the value of different mechanisms to supply
particular services/features to your application -- what works well
in one application may be clumsy in another.  Rethink the way you
implement particular services -- what ASSUMPTIONS are you making
(or, have others made *for* you!) that don't really *need* to apply?
What assumptions can you rely on (that might not be true of "all"
application) that you could leverage to your advantage to produce a
better platform?

E.g., in one of my RTOS's, I adopted the philosophy of augmenting
*every* system call with timers and mutexes.  This allowed consumers
to get the simplicity of traditional function/procedure calls with
some of the benefits of asynchronous service requests (i.e., not
having to risk blocking indefinitely).  [In a later revision of this
RTOS, the timer implementation allowed consumers to determine how
*long* a service had taken to complete]  This required careful
consideration on how timers were implemented -- since they needed to
be very cheap and efficient (as they could, potentially, see lots of
use).

In another RTOS, I implemented a global namespace for all system
objects and an LDAP-like procedure for locating and accessing
objects within that namespace.  This overhead allowed me to
move objects in-to and out-of memory dynamically (without worrying
about "pointers" getting munged).

I redesigned the APIs in my MMRTOS to facilitate moving *large*
quantities of data with low overhead (e.g., lots of zero-copy
semantics throughout).  Again, shifting the "cost"-performance
point to favor the needs of that particular class of application.

Bottom line, add some value to your implementation instead of
being "yet another RTOS".  (and, if you really *want* to be an
RTOS, go to great pains to explain the mechanisms that you employ that
let you use this term -- "Real Time doesn't mean Real Fast")

> - What will make you use an OS (if you currently don't use an OS at
> all)?
> 
> Please write what platform(s) your answer relates to and what is the
> project's field (even in general terms, e.g. "low-end media gateway",
> "network filtering appliance", "high-end router", "surveillance DVR",
> "IP camera" etc.)

I work on a wide range of products of varying complexity.  Currently,
the projects I am working on are very *small* and VERY LARGE -- in
whatever terms you care to use (KB to GB, fractional MHz to GHz, a few
$ to 10's of $K).  A "one size fits all" RTOS is just "too funny"
in this context! :>

Finally, make sure you take a good survey of what's out there before
you start.  In particular, look at the works from academia (most
commercial offerings are pretty boring/uninspired... "me too").

Good luck!

On 09/19/2010 09:29 AM, FreeRTOS info wrote:
> On 19/09/2010 16:31, Stargazer wrote:
>> Greetings,
>>
>> I am writing my own RTOS, which I intend to use in my projects and
>> license for anyone who would like to use it. At first I will use it in
>> my own projects, so that it achieves a certain level of real-life
>> performance and stability, then release it.
>>
>> The idea is to employ a "classic" embedded RTOS design (single address
>> space, multiple tasks, "hard" RT scheduling) with as much common
>> interfaces as possible (POSIX I/O, sockets, pthreads, standard C
>> library), with small storage and RAM footprint, with much higher
>> responsiveness than most of OS commonly used and without a need in
>> MMU. There's no need in a filesystem, everything runs from a single
>> binary. Most of the components are optional, it's easy even to use the
>> OS without a task manager as one big loop but with h/w, memory
>> management and filesystems support, for example.
>>
>> I intend to use it in projects that would otherwise use embedded
>> Linux, but need better performance / responsiveness / free resources,
>> without increase in platform's cost. I experienced and witnessed many
>> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
>> software quality, support and unnecessary amount of proprietary
>> interfaces where industry-standard interfaces exist. I believe that
>> those problems with dedicated RTOSes led to embedded Linux taking over
>> areas for which Linux wasn't even intended, and I hope to offer
>> similar (to Linux'es) advantages over them.
>>
>> For now I want to give a shape to my offer and strengthen the most
>> popular use cases for the OS. I don't have resources to make it
>> "relatively good for anything" like Linux, and I don't want to take
>> this direction in order to not complicate interfaces and development
>> procedures.
>>
>> Now I'd like to ask everybody who is willing to express his/her
>> opinion (as applicable):
>>
>> - What features, supported architectures/platforms/hardware support,
>> interfaces and available frameworks would make you use a new OS (if
>> you already use an RTOS)?
>>
>> - Why wouldn't you use a new OS (if you don't like the whole idea or
>> you're satisfied with the existing offer, etc.)?
>>
>> - What will make you use an OS (if you currently don't use an OS at
>> all)?
>>
>> Please write what platform(s) your answer relates to and what is the
>> project's field (even in general terms, e.g. "low-end media gateway",
>> "network filtering appliance", "high-end router", "surveillance DVR",
>> "IP camera" etc.)
>>
>> Thanks,
>> Daniel
>>
>>
>
> Just what the world needs - another RTOS.  Line up.
>
You beat me to the punch.  RTOS's are too attractive a target, and it's 
too easy to make a mediocre one that convinces you that quality is just 
around the corner.

I may write one for my own amusement, but I couldn't see attempting to 
make one for the masses -- it's been done.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Stargazer wrote:

> Greetings,
> 
> I am writing my own RTOS, which I intend to use in my projects and
> license for anyone who would like to use it. At first I will use it in
> my own projects, so that it achieves a certain level of real-life
> performance and stability, then release it.

Congratulations.
Every embedded developer writes a RTOS upon reaching a certain point in 
his career. Some even build a bunch of applications around their RTOSes. 
It's perfectly normal. Writing a RTOS is also a very useful exercise in 
understanding how stuff works and why certain things have to be done in 
the certain ways.

> The idea is to employ a "classic" embedded RTOS design (single address
> space, multiple tasks, "hard" RT scheduling) with as much common
> interfaces as possible (POSIX I/O, sockets, pthreads, standard C
> library), with small storage and RAM footprint, with much higher
> responsiveness than most of OS commonly used and without a need in
> MMU. There's no need in a filesystem, everything runs from a single
> binary. Most of the components are optional, it's easy even to use the
> OS without a task manager as one big loop but with h/w, memory
> management and filesystems support, for example.

Yea, been there, done that :))))) After floundering in a sandbox for a 
while, you will realize that you need the MMU, filesystem, USB host, 
TCP/IP stack, etc.
What makes you think that your RTOS is going to be different from many 
existing ones?

> I intend to use it in projects that would otherwise use embedded
> Linux, but need better performance / responsiveness / free resources,
> without increase in platform's cost. I experienced and witnessed many
> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
> software quality, support and unnecessary amount of proprietary
> interfaces where industry-standard interfaces exist. I believe that
> those problems with dedicated RTOSes led to embedded Linux taking over
> areas for which Linux wasn't even intended, and I hope to offer
> similar (to Linux'es) advantages over them.
> 
> For now I want to give a shape to my offer and strengthen the most
> popular use cases for the OS. I don't have resources to make it
> "relatively good for anything" like Linux, and I don't want to take
> this direction in order to not complicate interfaces and development
> procedures.
> 
> Now I'd like to ask everybody who is willing to express his/her
> opinion (as applicable):
> 
> - What features, supported architectures/platforms/hardware support,
> interfaces and available frameworks would make you use a new OS (if
> you already use an RTOS)?

Just look into any RTOS (VxWorks, OSEK, etc.) I assure you all features 
provided are necessary and useful in one way or another.

> - Why wouldn't you use a new OS (if you don't like the whole idea or
> you're satisfied with the existing offer, etc.)?

I would avoid using *any* new OS because of the learning curve.

> - What will make you use an OS (if you currently don't use an OS at
> all)?

I will have to switch to a new RTOS only if it supports the already 
available hardware platform which is too complicated to be controlled as 
the bare metal.

> Please write what platform(s) your answer relates to and what is the
> project's field (even in general terms, e.g. "low-end media gateway",
> "network filtering appliance", "high-end router", "surveillance DVR",
> "IP camera" etc.)

A platform with 100+ MHz and 1+ megabyte.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Sep 19, 6:31=A0pm, Stargazer <stargazer3...@gmail.com> wrote:
> Greetings,
>
> I am writing my own RTOS, which I intend to use in my projects and
> license for anyone who would like to use it. At first I will use it in
> my own projects, so that it achieves a certain level of real-life
> performance and stability, then release it.
>
> The idea is to employ a "classic" embedded RTOS design (single address
> space, multiple tasks, "hard" RT scheduling) with as much common
> interfaces as possible (POSIX I/O, sockets, pthreads, standard C
> library), with small storage and RAM footprint, with much higher
> responsiveness than most of OS commonly used and without a need in
> MMU. There's no need in a filesystem, everything runs from a single
> binary. Most of the components are optional, it's easy even to use the
> OS without a task manager as one big loop but with h/w, memory
> management and filesystems support, for example.
>
> I intend to use it in projects that would otherwise use embedded
> Linux, but need better performance / responsiveness / free resources,
> without increase in platform's cost. I experienced and witnessed many
> problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
> software quality, support and unnecessary amount of proprietary
> interfaces where industry-standard interfaces exist. I believe that
> those problems with dedicated RTOSes led to embedded Linux taking over
> areas for which Linux wasn't even intended, and I hope to offer
> similar (to Linux'es) advantages over them.
>
> For now I want to give a shape to my offer and strengthen the most
> popular use cases for the OS. I don't have resources to make it
> "relatively good for anything" like Linux, and I don't want to take
> this direction in order to not complicate interfaces and development
> procedures.
>
> Now I'd like to ask everybody who is willing to express his/her
> opinion (as applicable):
>
> - What features, supported architectures/platforms/hardware support,
> interfaces and available frameworks would make you use a new OS (if
> you already use an RTOS)?
>
> - Why wouldn't you use a new OS (if you don't like the whole idea or
> you're satisfied with the existing offer, etc.)?
>
> - What will make you use an OS (if you currently don't use an OS at
> all)?
>
> Please write what platform(s) your answer relates to and what is the
> project's field (even in general terms, e.g. "low-end media gateway",
> "network filtering appliance", "high-end router", "surveillance DVR",
> "IP camera" etc.)
>
> Thanks,
> Daniel

My suggestion will be: do what you feel is right and will serve you.
Chances are if something is useful to you it will be useful to
other people as well.
And ignore the "why yet another RTOS" sort of replies, what you do
with your time is your choice - which I am sure you know anyway.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Didi wrote:

> On Sep 19, 6:31 pm, Stargazer <stargazer3...@gmail.com> wrote:
> 
>>Greetings,
>>
>>I am writing my own RTOS, which I intend to use in my projects and
>>license for anyone who would like to use it. At first I will use it in
>>my own projects, so that it achieves a certain level of real-life
>>performance and stability, then release it.
>>
>>The idea is to employ a "classic" embedded RTOS design (single address
>>space, multiple tasks, "hard" RT scheduling) with as much common
>>interfaces as possible (POSIX I/O, sockets, pthreads, standard C
>>library), with small storage and RAM footprint, with much higher
>>responsiveness than most of OS commonly used and without a need in
>>MMU. There's no need in a filesystem, everything runs from a single
>>binary. Most of the components are optional, it's easy even to use the
>>OS without a task manager as one big loop but with h/w, memory
>>management and filesystems support, for example.
>>
>>I intend to use it in projects that would otherwise use embedded
>>Linux, but need better performance / responsiveness / free resources,
>>without increase in platform's cost. I experienced and witnessed many
>>problems with "established" RTOS (VxWorks, LynxOS, iTRON) regarding
>>software quality, support and unnecessary amount of proprietary
>>interfaces where industry-standard interfaces exist. I believe that
>>those problems with dedicated RTOSes led to embedded Linux taking over
>>areas for which Linux wasn't even intended, and I hope to offer
>>similar (to Linux'es) advantages over them.
>>
>>For now I want to give a shape to my offer and strengthen the most
>>popular use cases for the OS. I don't have resources to make it
>>"relatively good for anything" like Linux, and I don't want to take
>>this direction in order to not complicate interfaces and development
>>procedures.
>>
>>Now I'd like to ask everybody who is willing to express his/her
>>opinion (as applicable):
>>
>>- What features, supported architectures/platforms/hardware support,
>>interfaces and available frameworks would make you use a new OS (if
>>you already use an RTOS)?
>>
>>- Why wouldn't you use a new OS (if you don't like the whole idea or
>>you're satisfied with the existing offer, etc.)?
>>
>>- What will make you use an OS (if you currently don't use an OS at
>>all)?
>>
>>Please write what platform(s) your answer relates to and what is the
>>project's field (even in general terms, e.g. "low-end media gateway",
>>"network filtering appliance", "high-end router", "surveillance DVR",
>>"IP camera" etc.)
>>
>>Thanks,
>>Daniel
> 
> 
> My suggestion will be: do what you feel is right and will serve you.
> Chances are if something is useful to you it will be useful to
> other people as well.
> And ignore the "why yet another RTOS" sort of replies, what you do
> with your time is your choice - which I am sure you know anyway.
> 
> Dimiter

The RTOS + hardware drivers is not a big deal. Giving RTOS to the other 
people opens entirely different set of problems. First problem is 
support for all kinds of emulators running on all kinds of hosts. Next 
problem is support for all kinds of connectivity (USB, 1394, IPv6...) 
and filesystems on the HDD and flash. Of course, each of those things 
could be developed. But, even if they pay well for that, I have more 
interesting things to do rather then re-implementation of a bunch of 
dull protocols and trivial algorithms by hand. Life is short and it is 
unreasonable to waste it on the things that had been done 10000 times 
already.

VLV

On Sep 19, 8:00=A0pm, "Paul E. Bennett" <Paul_E.Benn...@topmail.co.uk>
wrote:

Hi,

thanks for your reply.

> The question you should ask is:- "Do you really need an RTOS for the
> application?". It can often be surprising to list the feature set you nee=
d
> and see how you can do that easily without the RTOS. However, when you ne=
ed
> an RTOS you need to have a really good one.

Indeed I did ask this question (no. 3). Embedded projects is such a
broad field with very different needs. My objective with this poll is
to get a feel of different needs. I'm not into convincing people that
do well without an OS that they need one, but if such people complain
about missing software features, I'd think what I can offer.

Daniel

Greetings,

thanks for detailed answer. Please see clarifications and discussion
inline.

> If you've not written an RTOS before, I would suggest you add a
> step *before* "public release" (I would actually suggest you add it
> before you finish any of *your* projects, as well!): =A0namely,
> "lather, rinse, repeat". =A0You'll find many of the classic features
> offered in MTOS's and RTOS's are, in practice, redundant and/or
> superfluous. =A0Once you've *used* them, you will be able to recognize
> which fit this mold and how you can trim down a "bullet point
> feature list to a true *core* of useful features -- though you might
> have to look at things in a different way to see the duality hidden
> there. =A0Then, revise your platform to more effectively use a smaller
> set of features (IMO, this has led to more robust and responsive
> implementations)

I think you misunderstand how features in embedded OS are usually
implemented. Features exist in independent modules; if your current
project doesn't need them, then you don't build/link them in, save
memory and storage and get more robust and responsive application. But
if your next project needs them, you just build them in and may be
quite happy to have them handy. It's the same as configuring Linux
kernel if you are familiar with it.

[...]
> It looks like you are already following the "kitchen sink" approach.
> Where is your priority: =A0footprint (TEXT/DATA) or features?

It depends on the project. One project will not start if some features
can't be provided, and another needs smaller footprint. See above.

> > responsiveness than most of OS commonly used and without a need in
> > MMU. There's no need in a filesystem, everything runs from a single
>
> Note that "filesystem" need not carry the bloat of a *disk* (or
> "memory") filesystem. =A0E.g., I like using fwrite, fread, etc.
> in my "tasks" (lets not argue terminology) with the sort of interface
> one typically thinks of with a namespace residing atop a filesystem.

fwrite(), fread() etc. are standard C library functions. They are not
directly related to a filesystem but rather to streams concept of ISO
C standard. By filesystems I mean real data structures that represent
files and control information on some storage (ext2, FAT, JFFS2,
cramfs, etc.).

> > binary. Most of the components are optional, it's easy even to use the
> > OS without a task manager as one big loop but with h/w, memory
> > management and filesystems support, for example.
>
> Wait -- first *no* filesystem ("no need in a filesystem") now there
> *is* one ("with ... and filesystems support")? =A0Or, have I misread
> something?

Filesystems' support are features that may be built in if your project
needs them (you work with storage), or left out. In Linux, LynxOS and
other UNIX-inspired embedded OSes you may possibly leave all
filesystems out of kernel build, but then the OS won't boot - it must
load /sbin/init from a filesystem. My OS follows the line of
"classical" (my term) one-binary embedded OS that don't have a
requirement to boot from a filesystem, but you have them in order to
support storage devices.

> "Proprietary interfaces" need not be *closed* interfaces.
> E.g., you can design your API in such a way that it offers
> the same functionality as "industry-standard interfaces"
> without adopting the same *syntax* as them.

yes I can. But that's exactly what I don't want to do - I want to
provide industry-standard APIs with defined and well-known semantics.
Real-life story: a couple of years ago I sold a port of sockets
library for iTRON from my OS, then in early development. iTRON
provides networking APIs that are exactly what you describe: mostly
functionally equivalent to Berkeley sockets, but with different
syntax, structures etc. The company that produces heavily-networking C
framework and libraries, that wanted to support iTRON, decided to pay
me for the port rather than learn new interface and change their core
code - and I have to agree with their decision (from their point of
view).

> Personally, I find products that *tout* "industry standard"
> API's more annoying than those that make no effort to "fit"
> those molds. =A0How often do you dig through such an API and
> then discover something is "not supported" -- for what the
> vendor/developer *thinks* was a "good reason". =A0(e.g., does
> your C library support fread, fwrite, fseek, etc.? =A0Or, do
> you want to rely on the RATIONALIZATION that not supporting a
> filesystem means you don't have to support these functions?
> etc.)

Yes, my C library supports fread(), fwrite(), fprintf(), fscanf(),
notion of stdin, stdout, stderr and most of other standard C library.
(It also supports regular POSIX I/O calls open(), read(), write(),
ioctl(), dup(), sockets API, pthreads and "process" emulation:
execve(), system(), exit(), atexit() etc.).

Particular fread(), fwrite(), fseek() use read(), write(), lseek()
back-ends, which may interface devices or sockets rather than
filesystem. I have my own internal interface that connects POSIX I/O
calls to filesystems implementation; in some special situations you
may implement your own filesystem (or pseudo-filesystem) and use those
functions to interface it.

The whole C library is optional, as nearly everything else you may
leave it out of build. If you insist on compiling in standard C file I/
O with no streams that may be read/written, it's possible but IMO
useless. fopen() will always fail and obviously consequent fread()s/
fwrite()s will fail also.

> > those problems with dedicated RTOSes led to embedded Linux taking over
> > areas for which Linux wasn't even intended, and I hope to offer
> > similar (to Linux'es) advantages over them.
>
> I think you will find the biggest hook to acceptance is ease
> of development. =A0I.e., if you can write your code on platform X
> and port it to playform Y (think: =A0X =3D=3D desktop PC, Y =3D=3D embedd=
ed
> hardware) then folks are more likely to use it (since most
> folks are lacking hardware skills and could never build on bare iron)

That's what I think too. I can build on bare iron, but in my own
projects I always consider ease of porting of existing software. It
results in different amounts of work, and customers are always more
willing to pay less (money and time) than to pay more :-)

> Rather than focus on writing something that (you *hope*!) others
> can reuse, I would, instead, suggest you look harder at what you
> could do to better fit your "OS" to the needs of *your* applications
> ("projects"). =A0Explore the value of different mechanisms to supply
> particular services/features to your application -- what works well
> in one application may be clumsy in another. =A0Rethink the way you
> implement particular services -- what ASSUMPTIONS are you making
> (or, have others made *for* you!) that don't really *need* to apply?
> What assumptions can you rely on (that might not be true of "all"
> application) that you could leverage to your advantage to produce a
> better platform?

You're asking right questions, but the problem is that they can't be
answered before doing real projects. Thinking and considering without
real projects will not produce anything meaningful. I'd like to use
results of this poll to get in "better shape" to full-scale projects
and possibly even to shape fields where I will offer services.

> E.g., in one of my RTOS's, I adopted the philosophy of augmenting
> *every* system call with timers and mutexes. =A0This allowed consumers
> to get the simplicity of traditional function/procedure calls with
> some of the benefits of asynchronous service requests (i.e., not
> having to risk blocking indefinitely). =A0[In a later revision of this
> RTOS, the timer implementation allowed consumers to determine how
> *long* a service had taken to complete] =A0This required careful
> consideration on how timers were implemented -- since they needed to
> be very cheap and efficient (as they could, potentially, see lots of
> use).

I think that high-resolution timers need only to increment/decrement
counter, which the timing code will just read and subtract. If
platform is custom, I would also consider using dedicated hardware
timer or a CPU that has it. Regarding asynchronous requests - may be
your consumers would be happier if those were implemented with
industry-standard select() / poll(), did you ask them?

I undertand that embedded/RTOS won't fit all needs. One benefit is
that application runs on system level and may interface some hardware
directly independently of OS, while using OS services where they are
suitable.

> Bottom line, add some value to your implementation instead of
> being "yet another RTOS". =A0(and, if you really *want* to be an
> RTOS, go to great pains to explain the mechanisms that you employ that
> let you use this term -- "Real Time doesn't mean Real Fast")

I believe that the major value of an OS is that it provides the
feature list that it declares and implements them well. Most
"established" RTOSes simply don't provide the declared functionality.
Most customers that I did works for in the past decade do projects
over embedded Linux; and those are kind of projects where you would
expect to see a dedicated embedded/RTOS, and despite that Linux is not
RT and wasn't even intended to be an embedded OS. The situation looks
beyond repair - we have Windriver and LynuxWorks selling Linux
distributions instead of fixing and improving their RTOS offers.

> I work on a wide range of products of varying complexity. =A0Currently,
> the projects I am working on are very *small* and VERY LARGE -- in
> whatever terms you care to use (KB to GB, fractional MHz to GHz, a few
> $ to 10's of $K). =A0A "one size fits all" RTOS is just "too funny"
> in this context! :>

Why, Linux is just almost "one size fits all"

Thanks,
Daniel