From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30581 invoked by alias); 29 May 2006 21:16:30 -0000 Received: (qmail 30571 invoked by uid 22791); 29 May 2006 21:16:29 -0000 X-Spam-Check-By: sourceware.org Received: from lmfilto03.st1.spray.net (HELO lmfilto03.st1.spray.net) (212.78.202.217) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 May 2006 21:16:25 +0000 Received: from lmfilto03.st1.spray.net (localhost [127.0.0.1]) by lmfilto03-10027.st1.spray.net (Postfix) with ESMTP id F2D487B5B0; Mon, 29 May 2006 19:16:42 +0000 (GMT) Received: from lmfilto03.st1.spray.net (localhost [127.0.0.1]) by lmfilto03-10026.st1.spray.net (Postfix) with ESMTP id 4537A9401E; Mon, 29 May 2006 19:16:20 +0000 (GMT) Received: from lmsmtp02.st1.spray.net (unknown [212.78.202.112]) by lmfilto03.st1.spray.net (Postfix) with ESMTP id B9C4294028; Mon, 29 May 2006 17:45:54 +0000 (GMT) Received: from localhost (p549B3B63.dip0.t-ipconnect.de [84.155.59.99]) by lmsmtp02.st1.spray.net (Postfix) with ESMTP id 22E79DB; Mon, 29 May 2006 17:45:54 +0000 (GMT) Message-ID: X-Mailer: XFMail 1.5.5 on Linux Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 In-Reply-To: Date: Mon, 29 May 2006 21:16:00 -0000 From: Wolfgang=?iso-8859-1?Q?_K=F6bler?= To: R Vamshi Krishna Cc: ecos-discuss@ecos.sourceware.org X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Hard-Realtime behaviour X-SW-Source: 2006-05/txt/msg00230.txt.bz2 Hello, I am also interested in using eCos for hard realtime applications. So just some thoughts about hard realtime and eCos: I think that simple hard realtime applications are already possible with eCos, if you are carefull enough. With eCos I know all the software that is running on my system. I can strip it down to the absolute minimum and review the code I use (when necessary). When creating a hard realtime application I need to make sure I always meet my deadlines. This means 1. I have to write my time-critical code so that it has deterministic behaviour (Very few, well known, things should affect its worst-case execution-time). 2. I have to make sure that no other code disturbs my time-critical code. With RTAI and Linux there is usually a whole lot of code that may not disturb realtime code and is unknown. With eCos usually the whole system is known and so the problem is much smaller. So what do we need (or want) for a hard realtime system: 1. Anything that is called by realtime code needs deterministic behaviour itself. This is probably what you are talking about here: > I am currently working on making eCos hard-real time. As the developers o= f=20 > RTAI claim that RTAI is hard-realtime, I have been comparing the code of= =20 > RTAI and eCos w.r.t the interrupt handling, kernel primitives, system=20 > calls etc. 2. Something to control DMA-transfers, as they may unexpectedly reduce memo= ry bandwidth and so slow down realtime code execution. But usually this is ignored. 3. Something to control interrupts, including special interrupts such as NMI and SMI on PCs. They may not unexpectedly interrupt realtime code. If you only want hard realtime in some IRQs, propper interrupt priorities might be enough. If you want realtime in tasks you need to=20 - know the high priority interrupts and - bound the time needed by low pritority interrupts RTAI does some interrupt virtualization and thus makes it possible to run realtime-threads that have a higher priority than the non-realtime-interrup= ts. This would certainly be a nice feature for eCos, too. 4. One important point is to make sure that no "normal" code can disable interrupts, as this could add unpredictable additional latencies to interru= ps (and the scheduler). Therefore RTAI replaces all cli-commands in the Linux kernel with its own code. 5. If you want hard realtime in tasks, you need a scheduler that does what you want. Usually you want a scheduler that only executes the task with the currently highest priority instead of giving cpu-time to all tasks. (Or you might even want an EDF scheduler) 6. It often helps if you have inter-task-communication mechanisms that support things like priority inheritance and priority ceiling.=20 7. A realtime TCP/IP stack (or rather UDP/IP) would be nice. 8. ... I have not checked which of these wishes are already fulfilled by eCos. And I do not claim that the above list is complete. Bye, Wolfgang -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss