Archive for the ‘Windows CE: Real-time’ Category

Win CE : More graphs etc

April 3, 2005

Refined to code to allow for when ticks counter rolls ove (low part, ie increments high part)  between LPT2 interrupt ISR and IST.  This was creating superiously large results, actually very negative ones because the timing uses the lower part of the ticks counter only.

Added some more refned graphs and sorted latencies on size so that you can see teh distribution of IST latency.

Advertisements

Windows CE Real-time: Got it to work

April 2, 2005

ie I now can use LPT2 as the source of interrupts instead of timer ticks.

Can’t measure ISR latency (see previous discussion) by via CRO this is about 7 us.
Timertick ISR latency is about 2.5us from ilTiming.

LPT interrupt ISR to IST latency is about 58 us min, where as
Ticks latency for this is about 46 us.

ie There is about 12 us difference.  Possible reasons:

  1. The code in PeRP( ) that handles all ISRs initially takes longer to get the part for LPT2
  2. LPT2 requires further calliing down hardware chain from PeRP( )

See the attached graphs.

Of interest is there are clearly 3 to 4 interrupt scenarios each taking a different time ISR-IST

eg LPT2 58 , 64, 72 and 88us
Ticks has the same but shifted down by about 12 us.

Windows CE Real-time 4: Terminology

April 1, 2005

When a an interrupt occurs, there is a hardware source.  With  a PC system these can be:

Timer Ticks, LPT1 or 2, COM1,2,3,or 4, PIC2 etc 

See pc.h  I added LPT1, LPT2, COM1 and COM2 as #defines 6,5,4,3 respectively.
eg #define INTR_LPT2   5

When an interrupt occurs a handler called and ISR (Interrupt Service Routine) fires up.  Its latency is probably mainly hardware but also will depend upon how long thecurrent thread takes to yield.

When an interrupt is configured by sw for use, a thread, the IST (Interrupt Service Thread)  is created along with an event.  The thread is largely a loop; but blocks at start of the loop waiting for that event.  The event is triggred by the ISR.

This allows for the fast handling of interrupts at a high priority but the sw in configuringthe priority of the IST thread ultimately determines the priority of the repsonse to the interrupt.

Windows CE Real-time 3

April 1, 2005

I had posted a query related this on the Paltform Builder NG:
http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.windowsce.platbuilder
Do a search on
David Jones
and choose the topic "ILTiming: Interrupt Source …"

Steve Maillet indicated what I thought might be the situation:  The timing as measured by ilTiming., although actioned by CE software (albiet at a low level), does do an insitu measurement of of interrupt latencies and that the timings are same regardless of the interrupt source.  ilTiming uses system timing ticks as the interrupt source (1000 high speed timing counts which are running at about 1 MHz).  [iltiming in its report indicates the period of these ticks.]

Karel Danihelka indicated that timing ticks must be the interrupt source as ther is no other way to measure the ISR latency.  (I need to explain ISR and IST latency (later).

Mu intention is to compare the iltiming with real hardware timing.  I can now generate a a hw pulse at the start of the ISR and can do so at the start of the IST.  I can then compare both to the interrupt source (I intend using LPT2) on external hw, eg a CRO.

Windows CE Real-time 2

April 1, 2005

I now can "see" what is the interrupt source.

I set a bit on LPT1 depending upon the source, for a short period.

In the same function as previous.

Windows CE Real-time 1

March 31, 2005

I am intersted in real-time performance of Windows CE; especially when under load from .NET Compact Framework applications.  .NET is not hardware friendly; especially no Real-time.

 To access hardware from .NET you have to do platform invokes which requires marshalling of data, which puts a load on the system.  .NET runs as managed code which makes use of the .NET Framework, runs garabage collection in background, provides type checking at run-time, and provides common functionality such as debugging.  When a PInvoke occurs its runs as Unmanaged code.

Over the last few days I have have been checking out real-time supportin  Windows CE 5 (Platform Builder).  There are various tools in PB for investaigating RT performance.  One in particular is iLTiming application that uses system ticks to launch interrupts.  It times how long it takes for the interrupt to start and how long before the handler starts.  I have been checking out the code with a view to using INT 5 (LPT2) instead of timer ticks.  This way I can physically measure these times and compare to iLtimer.

I have been able to do this in part but some interaction with timer ticks.  I had to eventaully reinstall CE5 and I am redoing this so I will blog my progress.

So far I can genearte external signals on LPT1 when every the ISR starts.

– One version did a binary count over successive interupts
– The next vesrion just outputs a pulse on LPT.0

To code this I enter in-line x86 code in fwpc.c  <PB Root>\Platform\Coomon\SRC\x86\Common\intr (Source Files)  in Function: PeRP()

More later.