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 : [EMAIL PROTECTED] 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
