Forums

Embedded RTOS - features poll

Started by Stargazer September 19, 2010
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&#2013265948;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!"