This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Hard-Realtime behaviour
- From: John Carter <john dot carter at tait dot co dot nz>
- To: R Vamshi Krishna <vamshi at cse dot iitb dot ac dot in>
- Cc: ecos-discuss at sourceware dot org
- Date: Mon, 19 Jun 2006 12:27:24 +1200 (NZST)
- Subject: Re: [ECOS] Hard-Realtime behaviour
- References: <Pine.LNX.4.61.0605291751420.14208@mars.cse.iitb.ac.in><"XFMail. 2 0060529195143.wk-list"@koebler.com> <20060530075335.GG2876@lunn.ch><"69dd805e0605300109k5dcf7986of596c0b5f796c6 b 4"@mail.gmail.com><20060530081637.GH2876@lunn.ch><"Pine.LNX.4.61.0605301431 51 0.22231"@mars.cse.iitb.ac.in><20060530111112.GK2876@lunn.ch><"Pine.LNX.4.61 .0 606031953120.6382"@mars.cse.iitb.ac.in><Pine.LNX.4.61.0606040253350.26447@m ars.cse.iitb.ac.in><"003401c6885d $23027ee0$070fe644"@EngAtPlayWS><Pine.LNX.4.64.0606191117470.3234@parore><P ine.LNX.4.61.0606190507480.4377@mars.cse.iitb.ac.in>
On Mon, 19 Jun 2006, R Vamshi Krishna wrote:
Thank you for the reply. But the fact remains that we would like to have a
"Hard" real-time OS irrespective of the processor/speed and ram/rom.
Let me give you a concrete, real life, happened several times, example.
If say some dumb user level code, in a non-safety critical part of your
code does a timer call back.
And in the call back calls some other code, that calls some other code
that does a wait of some form.
Since the timer call back is in an ecos DSR context, even though ecos
kernel is entirely well behaved, your user code will cause the kernel
to lock up until the wait is over.
Not the kernel's fault, ecos did exactly what was asked according to spec.
However, all kinds of even pretty soft deadlines got missed.
99% of the code in a usual app does not, should not have hard RT
deadlines. (If they do, you are designing it wrong!)
But in an RTOS like ecos, that 99% of the code can trivially screw up
the deadlines of the 1% time critical code.
Suggestion: If it is really "safety critical", use embedded linux with a
MMU and processes not threads.
PS:
If your project is just a very very thin smear of code that can be wired
direct to the hardware interrupts and doesn't need threads and
schedulers and mutexs and mailboxes etc, ignore the next paragraph.
If your project is seriously planning on "rewriting" an RTOS semi-from
scratch for your App just for the supposed benefit of MISRA_C.... This project
you are on is a one-way ticket to deathmarch hell.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
From this principle, all of life and physics may be deduced.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss