Interrupt response time

My main question is: if I handle an input signal through interrupt, what is the minimum interrupt time needed to handle it ? I am expecting to be less than 12 microseconds. Is this possible ?

My application is to build a data logger capable of:

  • every second read 6 analogic inputs (I don’t see any problems)
  • count in interrupt a random signal (from a radon detector), normally high, whose length is 12 microseconds low, with a maximum count rate of 1000 pulses/second, where the pulses are randomly received (for example a ‘train’ of pulses 12 microsec low, 2 microseconds high followed by a long idle time)
  • via Ethernet or Wifi download the accumulated data to a PC

Now, by reading the FAQs, it seems that I can expect a response time from 1 to 10 millisec, even in interrupt, since, if I understood correctly, the interrupt handler is returning the time stamp (reading the RTC) and then it disables all threads (or I should do it, to avoid loosing time)
More, application software is INTERPRETED, so execution time is slowed down by line parser.

So, can I expect a total execution time less than 12 microseconds in an interrupt routine ?

Thank you for the help

Like explained in FAQ, netmf is not real time. But you can use rlp to write code the will run in microseconds like you need

I don’t think you have a “read-time” requirement.

The actual interrupts, at the hardware level, are handle in unmanged code, which is fast. MF queues interrupts with an accurate timestamp, and dispatchs a managed thread to pass the interrupt to your handler. it can take a couple of ms before you get to process the interrupt. But, you are only counting the pulses, you should not care about the delay.

You only need to count falling edge interrupts.

There is the issue of how many pulse appear in a burst. Each interrupt is stored in memory, usage would grow during the burst time. If there are dozens of pulses, I don’t think there would be a problem.

Thank you very much for the very fast reply.

In fact I have to count the number of pulses every second, it is not important the delay, the important thing is NOT TO LOSE any pulse.
Like I already mentioned in my request, I have to ‘count’ pulses up to 1000 per second. In practice, I have to increment a selected counter. No matter if, due to the delay, the pulse is counted into ‘next second’ counter, it is important to be able to count up to 1000 pulese per second not losing any pulse.
I imagine, therefore, that my ‘interrupt handler’ should execute in much less than 1 msec. If I can easily write it using ‘rlp’ for it (I do not know what ‘rlp’ means), and writing all the rest of the code using the framework, that will be the final solution.

Thank you for the help.

If this is a professorial application, why not add a $0.50 micro that counts the pulses and pass the count onto FEZ Cobra once a second?

RLP is writing unmanged code in c/c++. Not as easy as C#.

You said that you would be getting a burst of pulses then a long quiet time. Your interrupt routine processing does not need to be less than 1ms/per interrupt. You just need to be able to process all the queued pulses/interrupts that were in a burst before the next burst occurs.

Remember, you are not acutally doing interrupt processing. MF handles the interrupt, and places the interrupt information into a queue. A MF thread then takes the interrupt information off the queue and passes it to your interrupt code.

If you do not process the interrupts fast enough, the queue grows in memory. You will not lose an interrupt if you do not keep up with the actual hardware interrupts. Of course, at some point you could run out of memory. With about 96MB, the Cobra has plently of memory.

So, the only processing constraint you have is that you must process all the pulses in a burst before the next one occurs. If you get a 1000 pulses in a burst, and the next burst occurs in 10 seconds, you have up to ten seconds to process the 1000 pulses.

I think the Cobra will be able to handle your requirements without RPL.

Thank you for your quick reply.

I am sorry, I did not explain myself correctly.
I will receive a maximum of 1000 pulses per second, every second, in a very radon-pollutted environment, but they will not be ‘evenly’ spaced pulses, they could come in bursts. Anyway, the maximum count should be no more than 1000 per second. This is why I was guessing that my ‘interrupt handler’ should execute in less than 1 msec…

Thank you for the help.

I have to agree with Gus. There is no shame in adding and external circuit to do the counting. Even a small PICAXE 08M chip has the capability to count pulses for 1 second and transmitting it to the FEZ. You could even program the PICAXE so that it only sends the count if the number is bigger then 1000 that would give you less interrupts on the UART to handle.

It doesn’t even need to be a pic axe!

I do this with a small pic12f675 … It sits at 4Mhz polling ( No interrupts ) Its a quadrature counter so its very accurate and never looses count… I use it to measure payout of an umbilicle cord on a geoscience’s submersable ( up to 1152 counts per second ).

I have also tried to read a port pin on the cobra at speed… It can do it! but you need a catch up delay every now and then.

Cheers Ian

You could probably use a lot of different stuff.
The reason for mentioning the PICAXE is that it has a built in counter so you issue the command
count 1,1000,w1 then it would count pulses on pin 1 for 1 second and store the value in word 1 (w1). Then you could decide to send the value over regular serial to FEZ.
It’s dead easy to program and you can even have this 8pin dip as a SMD.
No external components like crystals or anything, just power a pin to read and a serial line.

Is this something that GHI can add to FEZ? Why would you need such command? I am assuming this command is blocking so is this a problem? I mean can this command block the whole system till it is done?

Yes Gus, it will not do anything else until the counting is complete. But for this use it will be perfect. I have used this function to measure RPM of a motor with a LED (of course :)) an photo transistor plus a rotating disc with a hole.

I would love it as a FEZ feature with a callback when it’s complete, or as an encoder counter that your could start, stop, reset, set a trigger count etc.

Hello gentlemen,

I had a look to the LPC2478 data sheet and it seems that it contains 4 independent internal counters/timers, that can be clocked by external clock signals.

Is there any way to use one of them ? it would be perfect, if there is a way to read through software its content every second. No need to clear it, I can make the difference (with wrap around) with previously read value to know the number of input pulses. A ‘pulse accumulator’ would be achieved, with no hardware added …

Yes you can use them using the “register” class.

Hello Gus,

that’s great ! Could you simply tell me which GPIO over COBRA can I use as clock signal to which internal timer/counter ? Are all 4 timer/counters free or are they used by firmware/framework ?

I do not know on top of my head but this info can be found using the EMX brochire and the datasheet you have already looked at.

See pinout here http://www.ghielectronics.com/downloads/EMX/EMX_Broch_Pinout.pdf

This would be a fun thing to see working and share info with FEZ community, for some experience points :wink:

According to the datasheet you can use the PWM to count

[quote]
7.23.1Features
• LPC2478 has two PWMs with the same operational features. These may be operated
in a synchronized fashion by setting them both up to run at the same rate, then
enabling both simultaneously. PWM0 acts as the master and PWM1 as the slave for
this use.
Counter or Timer operation (may use the peripheral clock or one of the capture inputs
as the clock source).

• Seven match registers allow up to 6 single edge controlled or 3 double edge
controlled PWM outputs, or a mix of both types. The match registers also allow:
– Continuous operation with optional interrupt generation on match.
– Stop timer on match with optional interrupt generation.
– Reset timer on match with optional interrupt generation.
• Supports single edge controlled and/or double edge controlled PWM outputs. Single
edge controlled PWM outputs all go HIGH at the beginning of each cycle unless the
output is a constant LOW. Double edge controlled PWM outputs can have either edge
occur at any position within a cycle. This allows for both positive going and negative
going pulses.[/quote]

I may give this a try

Cheers Ian

Hello Gentlemen,

by cross-analyzing the manual of LPC2478, the pinout of EMX and the exposed pins of COBRA over the Cobra brochure, it seems to me that there are no signals directly available over COBRA pinout for clocking PWM0, PWM1.

Instead it seems there are at least 2 signals available for timer/counter clocking:
CAP3[0] = P2.22 = Cobra IO19 timer/counter 3
CAP0[1] = P3.24 = Cobra IO14 timer/counter 0
Now, the question. Is firmware or framework using any of these timer/counter 0 or 3 ? Which one can I use freely ?

Thank you.

I may test this later when I get a chance. I only write this incomplete code to get you started.
Please let me know how it goes…
You need these files
Manual: http://www.keil.com/dd/docs/datashts/philips/lpc23xx_um.pdf
Datasheet: http://www.nxp.com/documents/data_sheet/LPC2478.pdf
EMX pinout: http://www.ghielectronics.com/downloads/EMX/EMX_Broch_Pinout.pdf

First, select a free timer. I know GHI used timer0 and possibly timer1 so 2 and 3 should be free. I will just use 3 and leave 2 for a sec.
Now, we need to select what pin on the processor to use for timer3 pin capture feature. According to datasheet, the pins are same as analog0 and analog1 but these are used for touch screen on FEZ Cobra(EMX). These pins would be perfect for Domino so maybe keep 2 options in your class where the user will select to use these pins on those devices.
Now for cobra, we will need to check timer2 which looks like it is connected to P0.4 and p0.5. What a good luck we have as P0.4 (IO0) is connected to the down button on FEZ Cobra. This means I can use the button to test what I am writing.

Here is some sample code and also take a look at datasheet please

Before you do anything, you need to enable power to the timer you are suing. I would say just enable both timer2 and timer3 anyways.

Register PCONP = new Register(0xE01FC0C4);
PCONP.SetBits((1 << 22) | (1 << 23));//enable timer2 and timer3

Timer Control Register

Register T2TCR = new Register(0xE0070004);
// To enable timer/counter
T2TCR.Write(1);
// to reset the counter
T2TCR.SetBits((1 << 1));
T2TCR.ClearBits((1 << 1));

Count Control Register

Register T2CTCR = new Register(0xE0070070);
T2CTCR.Write((0<<2) | (2<<0));//count on falling edge and use CAPn.1

if you want o use rising edge then change it to

T2CTCR.Write((0<<2) | (1<<0));//count on rising edge and use CAPn.1

So timer is powered on and configured but we still need to map the pin to the timer function. Note that this code now is directly related to what processor pin is used. We are using P0.4 and we want to set it to CAP2.0

Register PINSEL0 = new Register(0xE002C000);
PINSEL0.SetBits((3<<8));//set bits 8 and 9

We are done but where do we read the count?

Register T2TC = new Register(0xE0070008);
uint count = T2TC.Read();

================
Again, I only explained this while looking at datasheet but I never tested any of this code and possible put the wrong register address so double check everything please.

Waiting to hear how it went … :slight_smile:

Hi Gus,
thank you for the example code.
Let me explain that, at present, I have not yet bought the development kit, nor the COBRA board.
I am trying to understand, before starting my development and buying whatever is necessary, if EMX/COBRA is suitable for me. At present it seems so with some limitations.
At the beginning of the forum question, I said that my final needs are to count every second the input pulses (solved with internal counter/timer) and get the values of up to 6 analog inputs (not really directly possible, since 4 ADC are exposed over pinout of COBRA and 1 ADC over JST connector). Read values should be cumulated in memory and then sent via WIFI or Ethernet.
My last question (I hope…) is the following: is there any way to trigger an interrupt using RTC, every new second (so to acquire the required data) ?
Thank you.