Real-Time Measurment Tools

Quote

I would like to run that for measuring interrupt latencies in my platform

Why is the mere interrupt latency so important for you? Why don't you look at the board (including WinCE) as a black box? I believe it is important how fast the whole system can respond to some incoming signal. That is how fast a signal can be output from the board after some other signal came in. This is the response time and can easily be measured with any oszilloscope by looking at the IN and OUT signals. But it is *not* important how fast the software knows about some incoming information.

For example if the input signal tells some critical situation, it is important how fast the system can react and switch something off. But it is completely irrelevant how fast the software can set a variable according to the incoming signal, because that variable does not help the situation.

The size of the code, the algorithms that you use, the optimizations that you put into the software, all these factors have much more influence on the response time than everything else. Your final software will definitely take a significant time to analyze the incoming signals and call code to react to them. Compared to this, the mere interrupt latency is marginal. And you probably even might want to implement the software without any interrupts at all, for example like an SPS in a quick polling loop.

What do you gain by measuring the latency time? Everything you do on the board has in turn influence back on the board. Even the measurement tools have influence on the measurement. For example some profiler must store information that would not have to be stored if the profiler was not running. The Kernel Tracker assembles information and sends them to the controlling PC, generating traffic that would not be there if no measurement takes place. Therefore all measured firgures are not exact either.

And you have to accept that such a board is a dynamic thing. There is *always* something going on and some execution times simply can not be measured or even predicted precisely. For example if you measure two times, and the second time there was some ethernet traffic, the times may already be significantly different, because the ethernet driver was also executing during the measurement.

So why doing such complicated measurements when the result does not help much at all?

Regards,

H. Keller

Quote

I have to know for real-time application something such as "maximum delay in scheduling interrupt service routines(ISRs)".

I think you still don't fully get what I'm trying to say. The maximum time depends on what is going on on the board.

Let me do a simple example:

Your board is connected to a serial line and a digital I/O line (DIO). On both lines something can happen at any time. Now assume you are getting something over serial line. If the board is currently idle, you will for example get a latency of 200µs (just some wild guess). But if there was also a signal on the DIO immediately before the serial signal, and the board is currently still servicing this DIO task, then the latency for the serial line may be 2ms or even worse. You just can't tell. Or if both signals happen exactly at the same time, which one should go first? The other one will automatically have a longer delay.

The actual time depends on

• The number of possible tasks. In this example there are only two: serial and DIO; but in reality there are quite a lot more, like device drivers and all other interrupt sources of your own application.
• The priorities of all these possible tasks.
• The time when any other events happened earlier and how long their service still takes.
• The overhead for switching between tasks.
• There might even be short periods of time when interrupts are completely disabled on the CPU, e.g. when handling some critical sections. During these times you also don't get any response.

In a way you have to decide yourself which tasks are more important and which tasks are less important. And by assigning appropriate priorities you have influence on how fast the reaction will take place.

All the "maximum latencies" given in the specifications of real time OSes are meant when the corresponding service routine has the highest priority possible in the system and there is no other task with higher priority. But this is just a theoretical value. As soon as you have other tasks with the same or higher priority, you cannot give any upper limit on such latencies anymore unless you know exactly how long all these other tasks can take in the worst case. But nobody can give you these numbers for all the device drivers active in WinCE, that's simply impossible.

Or just imagine the case that your own DIO handler disables all interrupts and then waits for 20 seconds in a busy loop. Then your latency is several seconds (!) if this part of the program is currently active when your serial interrupt occurs. Therefore how can anyone give any absolute numbers if your own program can have such an impact on all the timings?

Regards,

H. Keller