From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6188 invoked by alias); 30 May 2006 12:48:11 -0000 Received: (qmail 6180 invoked by uid 22791); 30 May 2006 12:48:11 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.iitb.ac.in (HELO smtp1.iitb.ac.in) (59.163.25.49) by sourceware.org (qpsmtpd/0.31) with SMTP; Tue, 30 May 2006 12:48:06 +0000 Received: (qmail 5385 invoked from network); 30 May 2006 18:17:46 +0530 Received: from unknown (HELO ldns1.iitb.ac.in) (10.200.12.1) by smtp1.iitb.ac.in with SMTP; 30 May 2006 18:17:46 +0530 Received: (qmail 26148 invoked by uid 509); 30 May 2006 12:47:46 -0000 Received: from 10.105.1.1 by ldns1 (envelope-from , uid 501) with qmail-scanner-1.25 (clamdscan: 0.88/1499. spamassassin: 3.1.0. Clear:RC:1(10.105.1.1):. Processed in 0.046514 secs); 30 May 2006 12:47:46 -0000 Received: from unknown (HELO cse.iitb.ac.in) (10.105.1.1) by ldns1.iitb.ac.in with SMTP; 30 May 2006 12:47:46 -0000 Received: (qmail 6402 invoked by uid 11940); 30 May 2006 12:53:49 -0000 Received: from 10.105.1.11 by jeeves.cse.iitb.ac.in (envelope-from , uid 11926) with qmail-scanner-1.25 (clamdscan: 0.87/1499. spamassassin: 3.1.0. Clear:RC:1(10.105.1.11):. Processed in 0.0495 secs); 30 May 2006 12:53:49 -0000 Received: from mars.cse.iitb.ac.in ([10.105.1.11]) (envelope-sender ) by cse.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 30 May 2006 12:53:48 -0000 Date: Tue, 30 May 2006 12:48:00 -0000 From: R Vamshi Krishna To: Luis Friedrich cc: =?ISO-8859-1?Q?Wolfgang_K=F6bler?= , ecos-discuss@ecos.sourceware.org In-Reply-To: <447C2A98.4050309@inf.ufsc.br> Message-ID: References: <447C2A98.4050309@inf.ufsc.br> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1762265857-135434214-1148993063=:30111" 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/msg00252.txt.bz2 --1762265857-135434214-1148993063=:30111 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Content-length: 5265 On Tue, 30 May 2006, Luis Friedrich wrote: > Wolfgang Köbler wrote: > > Hi, > > Most important of all in hard real-time systems is predictability which means > you are able to > calculate the execution time (WCET) of your system and so you can predict it. > > Also important is to be able to describe your application to the system, like > period, deadline, priority and all the parameters that describe the temporal > behavior of tasks (or threads). > > Finally, the scheduler or the scheduler mechanisms that are available are > also important to have flexibility enought to use different scheduling > policies. > > How you define for example the temporal paremeters of a thread on eCos? > - the function /cyg_thread_create/ has no arguments about the temporal > behavior of the thread Although we cannot define the temporal behaviour of a thread during thread creation, I believe that alarms/timers exist to help is in doing that. > > RTAI provides an API with functions like /rt_task_make_periodic/ which allow > the manipulation of temporal information for the tasks. > This is important for the scheduler to be able to schedule hard real-time > threads or tasks. We can actually emulate the RTAI thread constructs by associating an alarm with every task. The following pseudo-code would make my point clearer. cyg_user_start(){ /* Create Thread */ /* Create Alarm and associate it with the thread such that the alarm handler is invoked once every period starts. */ Alarm handler is invoked with thread's thread id as parameter. } func(..) { .... while(1) { /* Do Your Stuff */ .. .. .. sleep(); } } alarm_handler( threadid as parameter) { wakeup the thread } > > > Friedrich > > > >> 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 of >>> RTAI claim that RTAI is hard-realtime, I have been comparing the code of >>> RTAI and eCos w.r.t the interrupt handling, kernel primitives, system >>> calls etc. >>> >> >> 2. Something to control DMA-transfers, as they may unexpectedly reduce >> memory >> 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 - 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-interrupts. >> 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 >> interrups >> (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. >> 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 >> >> >> >> > > > -- Regards, Vamshi ------------------------------------------------- R.Vamshi Krishna, M.Tech. CSE (II year), IIT Bombay Room no. 320, A-wing, Hostel-12 Mobile : +919869781633 ------------------------------------------------- Yesterday is a past, tomorrow is a future , today is a gift that's why it's called 'present' --1762265857-135434214-1148993063=:30111 Content-Type: text/plain; charset=us-ascii Content-length: 148 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss --1762265857-135434214-1148993063=:30111--