Embedded RTOS - features poll

In message <4C963A7C.2040704@given.com>, FreeRTOS info
<noemail@given.com> writes
>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.
>>
>>
>
>Just what the world needs - another RTOS.  Line up.
>Regards,
>Richard.

Pot, Kettle, Black?

There is nothing worse than some damned engineer doing their own RTOS,
unless it is doing two RTOS..... :-))))

>+ http://www.FreeRTOS.org
>Designed for Microcontrollers.  More than 7000 downloads per month.
>
>+ http://www.SafeRTOS.com
>Certified by T&#4294967295;V as meeting the requirements for safety related systems.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hi,

thanks for your answer.

On Sep 19, 10:59=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> 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.

Well, I already have a couple of filesystems umplemented, my own TCP/
IP stack with sockets interface (over Ethernet) and semi-working USB
host (I should probably say quarter-working, USB host controllers are
very different and so far I have difficulties with motivation to make
it work well without a requirement from a customer).

> What makes you think that your RTOS is going to be different from many
> existing ones?

One thing, I am implementing industry-standard interfaces in order to
make porting of existing software simpler. Another thing, I am going
to make declared feature list work.

I had painful experience with VxWorks, LynxOS, pSOS and friends during
over a decade (and companies that I worked for got hurt much more).
The problem with them is that they just don't work. They declare
features that are not implemented completely or have major flaws in
implementation. Not marginal semantic of some rarely-used function,
but things like major undocumented limitations of VMEbus support on
MVME5100/6100 platforms. They started with "sell before implement" and
got into "sell instead of implement". The problem is beyond repair,
you don't get better solution even if you are a company that makes $ 4G
+ annually. Now they don't even try to counter the problems with their
RTOS, but sell Linux distros instead.

That's (IMO) a reason why Linux took place of those RTOSes, despite
that it's not RT and was not even intended to be embedded. That's also
why so many people are distracted from RTOSes, some pick their
favorite Linux distro, some write their own OS (and now there are
hundreds of them) and some choose not to use an OS at all.

Thanks,
Daniel

Hi,

thanks for supportive comment.

> 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.

However, this is sort of replies that I am also interested in. It
reads something like that: "we're tired with 100s of different OS
offers, every one with different proprietary interface, tool set and
bugs/limitations list, in most cases not even documented. We will use
whatever OS we had one-two successes with, or won't use an OS at all.
We already wasted much time and money trying different offers and it
will be very hard to convince us to try another OS". I am interested
in what people in this field really think and feel.

I want to make something that is working well and useful, and I know
that people won't buy ideas or concepts - they may need a product (I
wouldn't buy either). The OS will have to build feature list and
reputation via my own projects step-by-step. For now I want to somehow
"check water" and may be find an optimal jumping point, so all kinds
of responses are use useful.

Thanks,
Daniel

On Mon, 20 Sep 2010 08:16:46 -0700 (PDT), Stargazer
<stargazer3p14@gmail.com> wrote:

>Hi,
>
>thanks for supportive comment.
>
>> 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.
>
>However, this is sort of replies that I am also interested in. It
>reads something like that: "we're tired with 100s of different OS
>offers, every one with different proprietary interface, tool set and
>bugs/limitations list, in most cases not even documented. We will use
>whatever OS we had one-two successes with, or won't use an OS at all.
>We already wasted much time and money trying different offers and it
>will be very hard to convince us to try another OS". I am interested
>in what people in this field really think and feel.
>
>I want to make something that is working well and useful, and I know
>that people won't buy ideas or concepts - they may need a product (I
>wouldn't buy either). The OS will have to build feature list and
>reputation via my own projects step-by-step. For now I want to somehow
>"check water" and may be find an optimal jumping point, so all kinds
>of responses are use useful.
>
>Thanks,
>Daniel

Daniel.  I write my own O/S for many products.  It's in c
(mostly) and the principal features I care about, because of
the wide variety of processors I seem to need to support, are
compile-time configurability and the availability of very
basic process semantics to choose from so that the code I
write can be better isolated against change.  When a feature
is not enabled or selected, the code and data associated with
it is eliminated from the resulting object code.  It's a
prime goal that adding features to the source code may not
incur a cost if an end-user (me) doesn't require them and
deselects them in the compile-time configurations.

A minimally compiled system does NOT have a real-time clock,
quantums, semaphores, messages, thread priorities, sleeping
threads, and so on -- but it does support all of those
features if desired at compile-time.  In the minimal case,
though, it's just a simple, cooperative switcher, able to
keep the stacks separated (and that's about it.)  It supports
Harvard and von Newmann architectures and the kinds of memory
systems that common microcontrollers provide (such as
read/write and read-only for either code or data.)  It has an
explicit design requirement to isolate those portions of the
thread/process data structures which can be arranged into
read-only memory from those portions which require read/write
access during operation in order to reduce ram requriements
further.  (Threads can also be defined at compile-time, not
only at run-time.)

Serves a niche that I cannot find being served yet by others.

Jon

Stargazer expounded in news:67fc4024-eeeb-4fe5-a1cf-
a71f9d56bbba@z34g2000pro.googlegroups.com:
..
> I want to make something that is working well and useful, 

I think that one of your first steps will be to determine
the size constraints of the MCU(s) you want to support.

What I look for in an 8-bit RTOS (if at all) is going to
be entirely different than a 32-bit platform.  The 8-bit
resource limitations can be extreme, so you need to know
up front what limitations you are prepared to design for.  

Can you implement a file system with 1K of SRAM?  Its 
difficult, but I've done if for FAT16/32.  You have to 
play some shell games with sector buffers to make it 
possible. But this emphasizes the point that a file 
system implementation for 8-bit is going to be a lot 
different than a 32-bit platform. Resource limitations
enforce some practical realities.

If not 8-bit, then are you looking at small, medium or
large footprints, or all of the above? The choices made
here will affect your compromises and "usefulness" to
a target audiences.

And, is this going to be open sourced?

> The OS will have to build feature list and..

I cringe whenever I see "feature list" mentioned. 
People new to software engineering tend to throw
things in with the naive belief that "more features"
is somehow "better".

I prefer a design to start with the known 
bare essentials. Then analyze what is missing by
putting it to work. What is missing becomes obvious 
when you actually try to apply something. And
even then, resist the "because I can" temptation to
add things. Everything that is "added" becomes a
support burden down the road.

An example of a kitchen sink item, is support for
linked lists in the RTOS.  If required at all, this
should be put in an application library. It doesn't
belong in O/S level support.  But I've seen it in 
at least one RTOS, because someone thought this 
added to the "feature list". (To be fair however, 
the RTOS may have used this feature internally, 
and thus it cost little extra to export this 
service -- I didn't check on that).

To summarize, "less" is "more".  Small software projects
that are focused on essentials are easier to build/port
and support.  For example, I like the avr-threads 
package over an RTOS (for 8-bitters) because it is so 
focused on what is needed- only threads, mutexes and 
events.  Not the extra baggage of features I have no
need for.

I know that Mach kernels are an old idea these days, but 
perhaps a good implementation of Mach on a suitable 
range of hardware might be something better than a
"YARTOS" (Yet Another RTOS). Just an idea.

You should also spend time to study what other people 
have done- this will quickly tell you what you didn't 
like about each, and what you did like about each. Learn 
from the other projects- it may save you from making 
similar mistakes.

Just some food for thought- have fun,
Warren

On Sun, 19 Sep 2010 19:00 +0100, "Paul E. Bennett"
<Paul_E.Bennett@topmail.co.uk> wrote:

>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.

A simple state machine is usable to a certain degree.

However, with too complex relations, the simple state machine is too
complicated for most people.

After all, a simple RT kernel can be implemented with 1-4 KiB of code
and perhaps between 50-1000 bytes per task (including stack) RAM.

Hacked some non-optimal RT kernels in the early 1980's :-).

Warren wrote:


> Can you implement a file system with 1K of SRAM?  Its 
> difficult, but I've done if for FAT16/32.

One guy showed me his very minimal FAT implementation which took less 
then 512 bytes of RAM. There is no need to buffer a full sector. This, 
of course, implied tremendous overhead and inconvenience.

>  You have to 
> play some shell games with sector buffers to make it 
> possible.  But this emphasizes the point that a file
> system implementation for 8-bit is going to be a lot 
> different than a 32-bit platform. Resource limitations
> enforce some practical realities.

The real point is that it is plain stupid to mount things like FAT or 
USB host or TCP/IP on 8-bitter with 1K of RAM. It is not wothy, those 
are be crippled implementations with lots of limitations.

VLV

On Mon, 20 Sep 2010 10:33:23 -0700, Jon Kirwan
<jonk@infinitefactors.org> wrote:

>
>A minimally compiled system does NOT have a real-time clock,

An interrupt caused by the RT clock is no different from any other
interrupt.

>quantums, 

What is that ? A feature of the 1960's time sharing systems ?

>semaphores, messages, 

These are syntactic sugar

>thread priorities, 

In a simple system, the priorities are defined by the order, in which
you declare them. 

There are extremely rare cases (one in a million) in which you really
need to change the priority at run time.

On Mon, 20 Sep 2010 22:24:55 +0300, Paul Keinanen
<keinanen@sci.fi> wrote:

>On Mon, 20 Sep 2010 10:33:23 -0700, Jon Kirwan
><jonk@infinitefactors.org> wrote:
>
>>
>>A minimally compiled system does NOT have a real-time clock,
>
>An interrupt caused by the RT clock is no different from any other
>interrupt.
>
>>quantums, 
>
>What is that ? A feature of the 1960's time sharing systems ?
>
>>semaphores, messages, 
>
>These are syntactic sugar
>
>>thread priorities, 
>
>In a simple system, the priorities are defined by the order, in which
>you declare them. 
>
>There are extremely rare cases (one in a million) in which you really
>need to change the priority at run time.

Didn't want to debate what is good and where.  If I don't
need or want something, it's parameterized out.  That was the
point.

What's yours?

Jon

Hi Paul,

Paul Keinanen wrote:
> On Mon, 20 Sep 2010 10:33:23 -0700, Jon Kirwan
> <jonk@infinitefactors.org> wrote:
> 
>> A minimally compiled system does NOT have a real-time clock,
> 
> An interrupt caused by the RT clock is no different from any other
> interrupt.

Some systems rely on the jiffy being "special".  <frown>

>> quantums, 
> 
> What is that ? A feature of the 1960's time sharing systems ?

<grin>  Actually, I typically allow each task to have a priority
and/or a "timeslice" (which I will assume "quantum" is intended to
reference).  This can be a win for tuning on smaller systems.
On larger systems, it provides a subdivision of "round robin"
scheduling (i.e., allowing you to give a bigger piece of the
"robin" to one task over another)

>> semaphores, messages, 
> 
> These are syntactic sugar
> 
>> thread priorities, 
> 
> In a simple system, the priorities are defined by the order, in which
> you declare them. 
> 
> There are extremely rare cases (one in a million) in which you really
> need to change the priority at run time.

Ignoring, of course, protocols to handle priority inversion?

I've been experimenting with dynamically altering priorities of
tasks based on user activities.  Mainly in an attempt to anticipate
future needs so I can have the "results" ready before the user
asks for them.

Historically, timesharing systems would use priority aging as a
hack to improve the performance of short-lived and interactive
tasks (processes/programs).

The problem with all these scheduling parameters is that they
are often abused by folks who haven't properly designed their
"system" and aren't getting the behavior/performance they want.
Akin to throwing things in an ISR because your application
architecture doesn't address the timeliness of that particular
"thing", adequately.

Once you start *playing* with these parameters, it's easy to
find yourself in the role of <fill-in-favorite-derogatory-ethnicity>
Carpenter trimming the legs on the tipsy dinner table:
"Ooops!  Too short!"