protocol with 200us resolution

How bad is it if your program occasionally misses that deadline? If that would be unacceptable then you have a "hard" real-time problem which cannot be solved with plain Linux.

Rob

-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG

no, the program can occasionally miss the deadline, it's sufficient that this is not the normal case, i. e. most of the time it should get it.

thanks giammy

Stock linux will probably be fine then. I've measured interrupt latencies a couple of times on relatively slow embedded linux targets and I usually get sub 100 microsecond. But as a previous post says there is no guarantees.

If you google linux+interrupt+latencies+benchmark you might be able to pull up some actual data. A lot of the competing OSes usually publish their latencies versus linux to try to convince folks to buy their stuff. They usually are shooting for microseconds though.

-Clark

What kind of action? Is it an action that can be done at the low level - such as in an isr? Latency is pretty low for an isr.

Latency Benchmarks are designed to show what the designer wants to show. What was measured? Elapsed time from interrupt to displatch of the user level process? In any time critical process, that is not the way to go. The code will need to be much closer to the isr than user level. You can put the code in a tasklet or if it has other needs, a kernel thread.

There are ways to make it happen.

Bill

-- Posted via NewsDemon.com - Premium Uncensored Newsgroup Service ------->>>>>>

Yes, the relevant code will probably fit in the isr routine: I need to send 2 chars in a 00us slot:

I made some preliminaruy test: I have tested a isr connected to an ad hoc timer, to control a pin, and checking with the oscilloscope: the timing seems good, i.e the isr latency is tipically of some us, acceptable for the application. If some time the application misses its slot I can manage it, so I think it will be feasible.

thanks giammy