Most of what I saw were preemptive RTOS references, although I admit that I didn't click *every* link. Perhaps I'm only seeing what I want to see. Am I missing something?
--
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
Not sure about this. Most time-critical hardware tasks can be broken down into: - the bits that *really* need to run now (via hardware interrupt) - the bits that can be dealt with by the scheduler in a synchronous fashion
I therefore have no trouble with the idea of a real-time co-operative scheduler. Maybe I'm misunderstanding your point. Perhaps you include hardware interrupts in your definition of pre-emption (I don't).
Describes a computer program or system that must respond to stimuli within a fixed response time with a predictable and deterministic upper limit on response.
A fixed frequency synchronous loop with a cycle time that is less than the required response time is a fine example of a real-time system.
Perhaps you are confusing Real-Time with Real Fast?.
Actually, no. I've written real-time operating systems so I'm not quite that confused, Guy. I wrote one I've already recently described here, in fact.
I also just laid out my own version of my perceptions and what I consider a useful meaning. I've no right to force that on anyone, but you've got my view of matters.
If you are trying to include a polling loop as an example of a real-time operating system that should be included in the classification, then the classification itself loses much meaning to me. I understand that it CAN be faster than having to deal with the latencies involved in interrupt handling and I've used exactly what you are talking about myself for just those reasons. But you wouldn't find me calling it a real-time operating system. You might find me calling it real-fast, though.
And here I was thinking that's exactly what you are doing, calling a for-loop a real time O/S.
Oh, well. You have my views from an elsewhere post today. They are my own and from my perspective. You can like them or not, but there they are anyway.
I believe that "real-time" is a *functional* description. You appear to see it as an architectual description, which is why you reject tight loops that clearly perform a real-time function. Nothing wrong with seeing things that way, of course. I suspect that you would also reject my opinion that the standard light switch that is on the wall in my lab is a real-time system.
In my opinion, "fast" has nothing to do with "real-time", and thinking that it does leads to conceptual errors.
I once worked on a real-time system that kept the wax in a tank hot enough to be liquid but not hot enough to vaporize and catch fire. If the wax became too hot it would catch fire, and if it became too cool it would solidify and it would take several days to slowly melt it.
The real deadline (determined by the physics of heating wax until it catches on fire) was well over ten hours. I designed my control system for a worst-case response time of one hour and a typical response time of 20-30 minutes (you don't want to turn the burners on and off several time a minute...) and I defined a system hard deadline of four hours. This was a very, very hard deadline; the system absolutely had to turn off that heater before the four hour deadline.
For the heaters to go on and stay on for over four hours would have required failures in the control system and six different emergency cutoff systems that measured with six technologies (Bimetallic contact, thermistor, thermocouple, excessive fuel use, IR, meltable link) which shut off the heaters four ways (cutting off the fuel (four valves in series, all from different manufacturers), cutting power to the fuel pump, dumping the fuel into a holding tank, and cutting off the air to the burners.) In addition, the operator manually checked the temperature once per hour, and the security security guard checked another temperature gage during his rounds. And we had a couple of really loud sirens.
Real-time? Yes, Fast? Not even close.
I consider the bimetallic contact shutoff alone to be a real-time system - because I view real-time as a functional description.
I like the following namespace:
(Management version)
real-time, high-performance real-time, medium-performance real-time, low-performance ordinary high performance ordinary medium performance ordinary low performance batch, high performance batch, medium performance batch, low performance
(Engineer version)
real-time + real fast real-time + half fast real-time + not fast some-time + real fast some-time + half fast some-time + not fast long-time + real fast long-time + half fast long-time + not fast
(Yes, I am setting up a joke about a half fast design... )
Real-time, low performance would be controlling the temperature in the tank full of wax.
Ordinary high performance is your usual desktop application; faster is better than slower, but slower is better than never.
Batch high performance would be the IRS processing millions of returns. Soft deadlines but high throughput.
High performance is an interesting thing to design for, but high performance is not the same as real-time. Low performance/low cost is another interesting thing to design for, but low performance /low cost is not the same thing as not being real-time.
I don't believe that Jonathan is arguing with the fact that a real-time system can be realized without a real-time operating system.
The issue is the implication that real-time operating systems (RTOS) are preemptive in general. We are *not* discussing the definition of "real-time system."
--
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
Heh - I have a similar story, but involving a vat full of lipstick ;).
Years ago I designed PID temperature controllers. There were several hard real-time requirements, including: - Sample rate was 4 (or 8) samples per second. All signal processing, including ADC capture, linearisation, PID calculations, and output maintenance, *had* to be complete within one sample window (a relatively long time, but an absolute limit). - Part of the ADC system involved switching the ADC input from the measured variable to a couple of references (ratiometric system). Measurement accuracy depended directly on the accuracy of the *time* spent measuring each input; it had to be exact to a very tight latency indeed. (Achieved via hardware interrupt processing.) - Comms was RS485, hence bidirectional, hence the transmitter had to be turned off within a short time of transmitting the last stop bit; failure to achieve this would result in clobbered comms. (Again achieved via hardware interrupts.) - Front-panel key activity had to be "snappy", i.e. the display would react rapidly enough that the operator would not perceive any delay. - etc...
All of this was run on a fairly humble 6801 (later 8051) CPU, with a fairly simple (but nonetheless fairly sophisticated) synhronous cooperative scheduler.
I guess the question is whether or not one would classify this scheduler as an RTOS ;). I can see it both ways: in one sense, yes, it's an RTOS in that it provided a set of services that were dedicated to timely response. On the other hand, it was application-specific and depended on correct partitioning of the tasks into top-level synchronous tasks and low-level interrupt-driven tasks. And of course it depended on each task relinquishing control in time for all other tasks to run before the end of the timeslot.
One thing to add to all this: these were low-cost, high-volume embedded products - they *HAD* to be reliable. If they ever crashed or failed to meet their time deadlines, the units could be considered to be broken - and we, the manufacturers, would probably face lawsuits. (I'd argue that the definition of an RTOS should include this parameter - total reliability - since a software glitch represents a hard realtime failure!)
Which brings me back to the lipstick. One application involved controlling the temperature of a vat containing about a million bucks worth of lipstick, which had a very tight temperature control window - any overtemperature by just a few degrees would result in a vat full of worthless goo. It served to remind me, in a fairly banal but graphic fashion, of my responsibilities as a designer ;).
An interesting aside is that, in system specs I usually get, they demand that the response to the pressing of any button, operating any switch or clicking any mimic icon, is no more than 500ms. I have found that for items that take a long time to get to where they are going, a flashing indication, which begins the instant a user initiates an action, lets the operator know that something is in progress. The indication can become its final steady state when the action is complete. A separate user interface processor can help quite a bit here as well.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
I would guess 99.999% of installed real-time systems don't have an RTOS. After all, Mattel toys are real-time, right?
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . net com . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Damn, that sounds familiar. I ran the development of the CE Taylor MicroScan/Fulscope/ERC - later the ABB Commander - line of PID controllers/recorders/recording controllers. What controller were you working on?
Started with an 8051 and an RTOS written in PLM/51 as the translation of one written in assembler for the 8x86.
In an RTOS all the above information is specified in the Initial Task Control Blocks (name varies between systems). That doesn't make it application specific: It's the embedded equivalent of putting a word processor directory in a DOS path (kinda of).
I think the 'OS' part of the 'what is an RTOS?' debate is "_can_ you extract the scheduling code so it has nothing of the application in it and apply it to another application?"
-- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Ah, 500 mSec to change the cursor to an hour glass, and an hour to get back to an arrow. Where have I seen that ...
I have designed front panels that beeped, these seemed to keep the operator happy: if it didn't beep he pounded the front panel until he got a response - and a 5-lb sledge seemed to be the proper tool for pounding.
I found if something really obvious doesn't start to happen in 0.1 seconds the operator gets annoyed.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
A requirement which is far too often ignored. With command line control you usually have the echo to announce that you have been heard, but with mouse ticks etc. the response is often total passivity. So you conclude "I didn't press hard enough" and do it again, for further passivity and eventual error messages or other worse foulups.
--
"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
Hehe. Yes. So is a chicken hatchery, with temperature sample times in minutes and PI control loops that can oscillate over periods of hours.
The question in my mind was exactly whether or not an operating system itself should carry the tag. Not whether an application on the whole is "real time."
Letting the application decide whether or not an operating system it uses is real time or not is the logical equivalent for not making any judgment about the operating system at all.
Add me to the list, I suppose. I also worked on PID controllers, but as part of an overall instrument. Not as a separate product or product line by itself.
Some things I learned in that experience was the importance of reducing "phase delay" between the time of measurement and the time of the controlling output. Even a trivial system, where the output is simply a phase-delayed copy of the control input, wreaks havoc on the effectiveness of PID controls. Lengthing that delay only makes things worse. But so does letting that delay vary all over the place, so repeatable delays are important too. Not just minimizing them. It's bad news to allow them to jitter. (You can easily see the impact through analysis of the PID equations.)
I imagine it like this: Control loops are something akin to trying to keep the far end tip of a long, narrow, and flexible bamboo stick centered over the hole in a distant birdhouse in a tree. The length of the bamboo stick is your phase delay. Shorter is easier. The variations in the length of that stick is your jitter. Lots of jitter make it a lot harder, too. Use short sticks with no variation in length and it's a lot easier.
Keep your total software delays through the entire system to a dead minimum and make them precisely repeatable and you are a long ways ahead with PID in between.
I have a Sony Trinitron 100GS monitor. It has a momentary contact on switch with an LED next to it. It takes five seconds between pushing the button and the LED turning on. If the user pushes the button a second time before the LED comes on, it never starts up. I call that a user-hostile design.
Company was West Instruments (then part of Gulton Industries, now part of Danaher), and the product line was the West 3000 series - came out in '84/'85, IIRC. I also worked on bits of various other product lines (2072, Octet et al), but the 3000 series was my baby. The 3400 version was the first 1/8-DIN micro-based self-tuning controller in that price range (around £100), I'm told.
A while back I visited the West facility here in the UK for the first time in many years, and was disconcerted and flattered to discover that many of their product range were derived in some way from the West 3000 series, but
3 or 4 generations on. Suddenly I was a great-great-grandfather. I've rarely felt so old.
Oooohhh... I *really* wanted PLM/51, but never managed to convince my boss to let me move up out of assembler. Even then, code maintenance was a problem, and I could see PLM/51 helping in that respect...
Yes, I'd tend to agree. However - this is perhaps part of the whole issue of code re-use. I typically do re-use the last version of my co-op scheduler as the basis of a new design; thus it is continually improved and refined. It's not a separate entity, and I typically do re-structure chunks of it to suit the new application. So, to answer your question: yes and no ;).
This seems to me to be (or at least it's been my experience that it's) typical for practical code re-use - source code gets re-used and refined over time at source level. I think part of my distrust of commercial RTOSs lies in the fact that they try to be all things to all people, a jack of all trades (and arguably master of none). I tend to prefer to adapt something that's proven and simple rather than buy in something that's unknown (to me and my application) and complex. Apart from anything else, the learning curve is easier - and there's plenty to bite you in a commercial RTOS (ask NASA ;)).
That's got me thinking - actually, my problem is not with commercial RTOSs per se - it's with 3rd-party code in general. I've just not had a lot of luck with it. It's that old code quality issue I keep wittering on about....
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.