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.)
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...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
[comments > I am writing my own RTOS, which I intend to use in my projects and
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)
It looks like you are already following the "kitchen sink" approach. Where is your priority: footprint (TEXT/DATA) or features?
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.
Wait -- first *no* filesystem ("no need in a filesystem") now there
*is* one ("with ... and filesystems support")? Or, have I misread something?
"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.)
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)
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")
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").
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
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.
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?
Just look into any RTOS (VxWorks, OSEK, etc.) I assure you all features provided are necessary and useful in one way or another.
I would avoid using *any* new OS because of the learning curve.
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.
A platform with 100+ MHz and 1+ megabyte.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
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.
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.
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.
thanks for detailed answer. Please see clarifications and discussion inline.
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 depends on the project. One project will not start if some features can't be provided, and another needs smaller footprint. See above.
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.).
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.
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).
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.
ed
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 :-)
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.
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.
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.
There is nothing worse than some damned engineer doing their own RTOS, unless it is doing two RTOS..... :-))))
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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).
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.
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.
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.
Stargazer expounded in news:67fc4024-eeeb-4fe5-a1cf- snipped-for-privacy@z34g2000pro.googlegroups.com: ..
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?
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.
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.
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.
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)
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 Carpenter trimming the legs on the tipsy dinner table: "Ooops! Too short!"
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.