• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1218 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Latency between Hardware Interrupt and start of IST

MGun
Intellectual 895 points

Hi community

I'm not sure if this is really TI-OMAP35xx specific, but the numbers are easier to compare here than in the general WinCE Forum.
I used the GPTimers to measure the time between the interrupt has fired and the IST starts the processing.

Hardware: TI EVM3530
BSP: TI Omap35xx 06.15.00
WinCE started and no additional applications running

Here is what I did:
A) Setup a GPTimer with a period of 10000us (10ms)

B) Create an IST which waits for the event and reads the TCRR register, stores the difference of TCRR and TLDR in a big array in memory and clears the TISR interrupt flag

Below are the result for 10000 interrupts. As you can see the delay varies between 6 and 400us with a quite regular pattern.
The measurement was done twice with different thread priorities (15 and 0).

I also verified the latency with an osciloscope by setting up a GPTimer with 10ms period and toggling a GPIO pin in the IST thread.
Results for 5000 interrupts:
- Mean period: 10.00009534ms
- Minimum period: 9.58805ms
- Maximum period: 10.41973ms

As you can see the average is quite good, since the latency is quite a regular pattern. What is unacceptable is the min / max period time.

Question: What are the values i can expect from WinCE? Did you observe similar behaviour? Where is the problem?
Mike Hall posted an Article about Windows CE 5.0 for real-time systems, there is also a formula to calculate the IST latency:
http://www.embedded-computing.com/pdfs/Microsoft.Nov05.pdf

  • 0
    Intellectual 895 points

    Update:

    I changed for a quick test the OEM InterruptHandler and did a new sysgen.

    File: \WINCE600\PLATFORM\COMMON\SRC\SOC\OMAP35XX_TPS659XX_TI_V1\omap35xx\OAL\INTR\intr.c
    Function: OEMInterruptHandler
    At the end of the OEMInterruptHandler i storedthe difference of TCRR and TLDR into an array.

    After 10000 interrupts the results look like this:

    • Minimum latency: 0us
    • Maximum latency: 471us
    • Average latency: 242us

    Quite surprising, isn't it?
    Looks like the ISR itself does have a dynamic execution time.. But where does this jitter come from? If i look at the OEMInterruptHandler, the code there is quite straight forward..

  • 0 in reply to MGun
    Genius 5470 points

    I am not sure your numbers are too far off from what would be expected for a "non-tuned" build with power managment enabled.

    There are so many factors that go into the mix it would be hard to explane them all. The power managment is just one area that can be tuned to improve response time if the standard build does not meet your real time requirements. The BSP uses a lot of features to lower power consumption to improve battery life, usually at the expense of response time. You can look at the OEMIdle function to get an idea of just what is going on. If you are really serious about getting the absolute lowest response time (and do not mind the power consumption) you would start with a "tiny kernel" build with no drivers, no power managment and a basic OEMIdle that just stalls in a tight loop. You would profile and benchmark this then slowly add drivers and features as needed, tuning priorities and identifing bottlenecks along the way.

    Submicrosecond responses are not that hard to achieve even running in the 300-400mhz range.

  • 0 in reply to MGun
    TI__Expert 3710 points

    The jitter comes from (a) other interrupts in the system and (b) chunks of non-preemptible kernel code. I think most of it is because of (a)

    Atul

  • 0 in reply to DavidVescovi
    Intellectual 895 points

    Hi David

    <quote>I am not sure your numbers are too far off from what would be expected for a "non-tuned" build with power managment enabled.</quote>
    Did you mean the numbers are *not* too far from what would be exepected for a "non-tuned" build with power management enabled?
    I use the default EVM3530 BSP 06.15.00 with no major modifications.

    I modified ILTiming (see thread) and the results are similar to my hardware measurements:
    Results for ILTiming with 10000 Interrupts and default parameters

    ISR starts [us] IST starts [us]
    Min 701.9 0.0
    Max 1281.7 61.0
    Average 999.7 14.9

    My big problem is the big difference between the min/max latency, this produces an ugly jitter.. Power consumption is currently not a big concern, so i'll later have a look at the OEMIdle function.

    Could you please modify ILTiming as described in the other thread and execute ILTiming with 10000 interrupts
    a) on your reference board (to proove my results)
    b) on a "tuned" system?