Compare all this with the development of multi-programming OSs in the first place. In the beginning there was batch, and the program owned the machine. Then came time sharing, which was developed to let the program assume it owned the machine, because program development was much easier in such circumstances, and divorced from the actions of other programs (at least it was hoped). If we had to think about disk access, write and read queues, terminal buffers and interrupts in every useful utility, we would never get anywhere.
Similarly the embedded OS comes in once there are several programs, pronounced processes, that have to be coordinated. Adding RT to that means that we can predict the limits of service delays. The more complex the overall system, the more the isolation effects of an RTOS will help.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
I was simply trying to use the commercially available RTOS selection (which are widely used and understood) to make my point about the common understanding/definition/ connotation of the term RTOS.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Thank you. I feel ... enlightened ;-) Or at least not as ignorant.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Well, for starters, the "OS" appearing in RTOS means "operating system". Which, to me at least, strongly implies that there must be a strong division of the overall software being run into two parts: the OS, and something else, which, for sake of this discussion, let's call the "application". The key aspect of that division being that the same, fixed OS will be used with many different applications, over its lifetime.
IOW, though it doesn't have to actually be a commercial product, it really must have enough technical merit (as opposed to legalese barriers) to become one, to be bearing the name RTOS rightfully.
A simple event-loop programmed from scratch along with the rest of the application doesn't fit these criteria by any stretch of the imagination.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
A *huge* limitation. Try finding an RTOS for a Sunplus, Winbond, or Elan/EMC chip. Some of us *have* to write our own RTOS - and our own language inerpeter/compiler.
I assert that it can because I with others developed just such a simple event loop topology which was reused in a range of products of varying complexity over a ten year period.
So? Semantic point. You call this an RTOS or at least an OS. I, and also apparently Hans-Bernhard, call it a programming technique for OS-less embedded systems. Pursuing this to its logical conclusion you would be calling any switch statement an OS, no?
I think the point was [ITTPW?, naw.] that an RTOS is generally application independent. It is a chunk of software entire unto itself: although not a commercial product it could be one.
I would bet a vast majority of RTOS's are proprietary. I have four of them in my back pocket, but they all have documentation as if they came from MicroCenter (well, sort of).
'Shrinkwrappable' may be a good description.
An event loop or foreground/background scheme isn't separate from the application, not in any way that makes sense. The idea is application-free, but the implementation isn't.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Why on earth should it be so? An RTOS is a chunk of software that performs the specific set of functions. I would have thought that what those specific functions were and how they were achieved was very application dependent. Otherwise we could all use the same RTOS.
Quite possibly but I see no reason why that should form any part of the
*definition* of an RTOS.
So your argument boils down to whether an RTOS is considered to be 'an idea' or an 'identifiable (independent??) chunk of software'. I subscribe to the view it is 'an idea'. I see no reason to constrain an RTOS to an identifiable chunk of software precisely because that may not be the most effective means of realising it.
At any rate it seems to me we are becoming hopelessly bogged down in semantics.
I see you are using google, and managing to make it quote. Does it fail to attribute or are you stripping those off?
To the subject. To me, an OS is something that manages resources, some of which are sharable (like a file system, maybe memory) and others are not, such as displays, ports, disk drives. The OS has to be able to apparently run at least one program, when sharability becomes moot, or multiple, when sharing and exclusion becomes very important. Now a critical thing becomes "how does the OS schedule things". This may be by pre-emption (fairly safe, but complex) or by mutual agreement between programs (requiring cooperation). Even further, the OS may be able to guarantee some sort of response time to an external stimulus, regardless of the various programs action. This last makes it a RTOS.
Notice that with sufficient rules the cooperative system can be a RTOS. In all cases the complete gestalt of OS and programs (or processes) can be viewed as one big single thread of execution. (Except some real multi-processing systems). A model for a cooperative system can be as simple as:
while (running) { process(n); n = selectnext(n); }
accompanied by specifications of how process operates. If these rules include specification of the longest execution path, together with a limitation on the range of n, it can be used to build an RTOS.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
There is a whole class? of applications which are implemented on simple microcontrollers where resource sharing is handled by allocation at design time. Perhaps the only shared resource in these is the CPU core.
Again there is a whole class of (real time) applications where nothing more complex than a cooperative scheduler is required.
Yikes Ian, I didn't realize that I was being so underhanded.
OK, include open source RTOS, eCos, RTEMS and *many* others. The "commercial" attribute has no bearing on my argument. What I *am* saying, and I think most embedded software engineers would agree, is that when one uses the term "RTOS", it is commonly assumed that it is preemptive if for no other reason than the fact that most common RTOS are preemptive.
I certainly do not deny that there may be those who do not make this assumption. Of course, applications written to run under a preemptive RTOS are different from those written under the non-preemptive variety.
E.g. an application written for an RTOS does not need to volutarily give time to other threads, unless it is busy waiting instead of blocking.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
What in the world does an RTOS have to do with a specific piece of hardware? Sounds like one would need a device driver for a particular err... "operating environment framework", whether that be an RTOS or not.
Surely a sufficiently factored RTOS implementation is independent of the applications which use its services. Otherwise, one *would* need to write an RTOS for every application and that would be a continual re-invention of the wheel.
Certainly, an all encompassing statement like this is just a troll. Clearly, there are many application, platform and other differences that make a one-RTOS-fits-all solution impossible.
However, having said that it should be equally clear that many similar applications can (and do) use the same RTOS or else what would be the point of the many freely and commercially available RTOS?
Without meaning (semantics) there is no understanding. Hopeless? I hope not.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Despite my comment about Salvo possibly being considered a commercial RTOS without pre-emption (I believe this is how it is sold to the public since their catch phrase is "The RTOS that runs in tiny places.?"), I agree with you, here.
If I see the word "RTOS," I presume that it is has support for pre-emption. This expectation was, in fact, the reason I remember Salvo so well (I have never tried to use it.) I had this expectation when I started reading the manual for it and was startled when I couldn't find pre-emption support.
My first exposure to the phrase, "real time operating system," came about with RT-11 on the PDP-11, back in... 1973 or so. At that time, real-time operating systems were differentiated from time-sharing systems (like RSTS/E and, later on, Unix, for example) and from systems that had no pre-emption support, at all. The "real-time" meant that the operating system was designed from the ground up to provide the real-time I/O services. A minimal system required access to a
50/60 Hz clock, for example. In any case, implicitly if not explicitly, this idea of "real-time" meant pre-emption.
Today, I think the term "real-time" has been so mixed up by marketplace messages that it's hard to say that it has any useful meaning we all share in common. If I had my choice, I'd prefer that "real-time" have a meaning that usefully divides away some kinds of things while including others. But it seems to mean just about anything you want it to, and in going that way, looses all value it may have once had.
If so, it means nothing useful now. It's just a catch phrase.
But if I were to define it, it would be something like this:
A real-time operating system is one which provides an unusual focus on services for time-critical responses to external/hardware events and does NOT focus on providing general support for a wide variety of tasks, such as is provided by Unix. (Unusual in the sense of not being usual!) A real-time operating system should connote "lean" and "timely" and should be differentiated from any which can be described as "large" (because of the extensive support required for a wide variety of general purpose services) or "sometimes timely and sometimes not" (because of the scheduling methods.)
Come to think of it, perhaps the process scheduler is the way to determine whether or not something is "real-time" or not. If it supports priorities and supports an immediate and rapid transition to a high priority task on the basis of an event with very low latency (for the given processor's capabilities), then it may be "real-time." But this *does* mean, if it supports hardware events and not just software ones, that pre-emption is in place.
Which brings us back to expect that RTOS be a term NOT applied to operating systems which do NOT feature pre-emption.
I can't speak for Michael, but nothing I saw off-hand in it would cause me to reconsider my own recent comment. You might want to point to something specific in that list of thousands of hits to help others see what you are trying to say. It's somewhat difficult to gather your point from what's written above.
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.