X-No-Archive:yes

A certain Guy Macon, of comp.arch.embedded "fame", writes :

>"RTAI's microkernel approach guarantees that the data-acquisition
>task will take place on schedule, even while the previously acquired
> and calculated result is written to disk."
>  -http://www.elecdesign.com/Articles/Index.cfm?ArticleID=3816&pg=2

http://www.aero.polimi.it/~rtai/documentation/articles/guide.html

"What is RTAI?

RTAI means Real Time Application Interface. Strictly speaking, it is not 
a real time operating system, such as VXworks or QNX. It is based on the 
Linux kernel, providing the ability to make it fully pre-emptable. "

Your serve.

[BTW, isn't RTAI a kernel - a microkernel - all by itself ? You could 
say that this isn't actually Linux. Linux runs essentially as a process 
above RTAI. This isn't necessary in an OS such as, for example, 
Greenhills Integrity, which provides guaranteed latency and other 
goodies.]

-- 

"Jokes mentioning ducks were considered particularly funny." - cnn.com

Chesney Christ <thegreatsuprendo@hotmail.com> says...
>
>A certain Michael Schnell, of comp.arch.embedded "fame", writes :
>
>>> Supposedly the low-latency patch can give worst-case latency of around
>>> 150us, but you'd need to check out how this fits on your architecture.
>>
>>Nope. Linux can't guarantee any worst-case latency at all (I did find
>>more than 100 msek with the low-latency patch in very rare instances).
>
>That's why I was quite careful not to use the word "guarantee".
>
>Clearly if you need hard real time performance, you need to look at 
>another OS.

"Hard real-time means no surprises or silent failures as system
 configuration changes or load increases. Deadlines will still
 be met. For example, the worst case delay on a 1 millisecond
 thread on the HP Pavilion Notebook (AMD K7) is 12 microseconds. 
                     -http://www.fsmlabs.com/products/rtlinuxpro/


"RTAI's microkernel approach guarantees that the data-acquisition
task will take place on schedule, even while the previously acquired
 and calculated result is written to disk."
  -http://www.elecdesign.com/Articles/Index.cfm?ArticleID=3816&pg=2


"Lineo Solutions, Inc. (Lineo) demonstrated ... hard real-time 
support with Linux .... Deterministic time metrics of the systems
demonstrated ... is as follows.

Interrupt Response Time 5 microseconds 

Task Latency Time 4 microseconds 

Periodic Task Latency Time 20 microseconds 

Timer Clock Accuracy 1 microsecond, Jitter 1 microsecond)"

- http://www.lineo.co.jp/eng/news-events/press-release/20040109.html


"RTAI - the Realtime Linux Application Interface for Linux ... lets
you write applications with strict timing constraints for your
favourite operating system."
                                    -http://www.aero.polimi.it/~rtai/

"KURT-Linux: Kansas University Real-Time Linux: Microsecond timing
resolution and event-driven real-time scheduling..."
           -http://www.ittc.ukans.edu/kurt/documents-noframes.html



-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

X-No-Archive:yes

A certain Michael Schnell, of comp.arch.embedded "fame", writes :
>> Supposedly the low-latency patch can give worst-case latency of around
>> 150us, but you'd need to check out how this fits on your architecture.
>
>Nope. Linux can't guarantee any worst-case latency at all (I did find
>more than 100 msek with the low-latency patch in very rare instances).

That's why I was quite careful not to use the word "guarantee".

Clearly if you need hard real time performance, you need to look at 
another OS.

-- 

"Jokes mentioning ducks were considered particularly funny." - cnn.com

> Supposedly the low-latency patch can give worst-case latency of around
> 150us, but you'd need to check out how this fits on your architecture.
> 


Nope. Linux can't guarantee any worst-case latency at all (I did find
more than 100 msek with the low-latency patch in very rare instances).

-Michael

"Mad@Spammers" schrieb:
> 
> I want to synchronize a user space thread to an external event that
> generates an interrupt. 

Look at rtc.c in the Kernel source. They provide a blocking read to the
application to have it wait for an event. Her some data is provided to
the application, too.

-Michael

X-No-Archive:yes

A certain Mad@Spammers, of comp.arch.embedded "fame", writes :
>Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote in message
>
>> Look twice at this approach! This is the UNIX way - everything is a file.
>
>Is it a good or a bad thing?

Keeps everything nice and simple. There is a consistent way of dealing 
with hardware.

-- 

"Jokes mentioning ducks were considered particularly funny." - cnn.com

X-No-Archive:yes

A certain Mad@Spammers, of comp.arch.embedded "fame", writes :

>> What kind of time resolution do you need?
>>
>I presume this question was asked to me.
>
>I am just evaluating how well would Linux (either 2.4 with preemption
>and low latency patches or 2.6 with preemption enabled) perform for my
>application. Worst case interrupt latency of 400us and thread
>activation latency of 4ms are more than acceptable in my application.

Supposedly the low-latency patch can give worst-case latency of around 
150us, but you'd need to check out how this fits on your architecture.

-- 

"Jokes mentioning ducks were considered particularly funny." - cnn.com

X-No-Archive:yes

A certain Mad@Spammers, of comp.arch.embedded "fame", writes :

>I would appreciate having hints on how to do it or pointers to
>documentation and example code if available.

What you'll need to do is create a device driver with an entry in /dev, 
and then set up a poll()/select() call within it. These can be used to 
inform a user space application that some data has arrived to be 
processed.

Your user space code can open the device and use the above functions 
which among other things provide the ability to block a thread until an 
interrupt is received, etc. Much more elegant than signal processing.

The free book "Linux Device Drivers" covers this subject in detail.

-- 

"Jokes mentioning ducks were considered particularly funny." - cnn.com

Wolfgang M�es wrote:

> - Let your driver register a character interface
> - from your user space thread, do a synchronous read.
> - in your interrupt routine, copy the data and wakeup the
>   waiting thread.

This method would get my vote.  The "send a signal" approach is 
workable, but it can be difficult to get right.  This is especially true 
if your application is already using a number of signals for other things.

YMMV...

John
-- 
John W. Linville
linville@tuxdriver.com

Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.ac.be> wrote in message news:<Pine.LNX.4.44.0404291542290.9591-100000@srv04.mech.kuleuven.ac.be>...
> On 29 Apr 2004, Mad@Spammers wrote:
> 
> > I want to synchronize a user space thread to an external event that
> > generates an interrupt. 
> 
> Maybe the ongoing work about D-Bus can give you inspiration:
>   <http://freedesktop.org/Software/dbus>
> One of its motivations was/is exactly to be able to do more driver stuff in
> user space, and I got the impression that that was what you are looking
> for...
> 
> Herman

I had a quick look at it. My requirements are much more modest and I'd
rather use native linux resources instead. Still I will look at its
code for some tips.

Elder.