Main Site Documentation

RLP Interrupt


Hi there,
I’m trying to make a “stopwatch” based on USBizi. I want to know when a pin change happend very accurately. That’s why I decided to use timer capture pins, which can get the timer value in the moment of that pin change. I’d like to use RLP to handle this task, but I wasn’t able to find enough information how to do that.

  1. Which timers are used by .NETMF? Is there any additional timer used by GHI?

  2. What is exactly the first parameter Irq_index in Interrupt.Install()? Is it a number from 0 to 31? I’ve read somewhere here in the forum that somebody used the hex mask. Let’s say TIMER1 has VIC channel 5 and hex mask index is 0x20. What is correct?

  3. Is it enough to call Interrupt.Install() and Interrupt.Enable() at the RLP side? Is there anything else to call?

  4. What must be included in the RLP_CALLBACK_FPN ISR? Am I responsible for clearing the interrupt flag or is it done by GHI?

  5. Is it possible (and smart) to call RLP->PostManagedEvent() in the ISR? How long might the PostManagedEvent take? Is the function implemented like a non blocking linked list (using atomic operations) or is it needed to call GlobalInterruptDisable to avoid some synchronization problems?

It would be very helpful to have somewhere in the documentation or samples a piece of code, where Interrupt.Install() is used…

Btw, thanks GHI guys for their great products…


Hi Martin,

actualy You don’t need RLP for this task at all. Managed interupts will do the job.

Interupts has timestamp in it’s definition. The time is acurate even if interupt is handled some time later.
For example of interupt usage take a look and this project–panda/


Hi Rimvis,
thank you very much for your response. It’s good to know that the time in the interrupt handler works this way… Unfortunately I’d need higher resolution 1/10msec, According to the GPIOInterruptEventHandler documentation: [quote]A value that specifies the time interval between invocations of the methods referenced by the callback method, in milliseconds[/quote].
Moreover I’d need to provide a temperature compensated crystal as an external clock source. That’s why it seems to me that the RLP is the only solution. Or am I wrong?


The timestamp is stored at the time the interrupt happens so even though you may receive the event few ms later, the timestamp of when the pin actually did interrupt is very accurate. I have seen developers decode TV remote signal using this timestamp




Ok, so according to the infrared s/r sample it seems that the interrupt event time has higher resolution than 1ms…

Even if so, I need a very accurate source of clock signal to measure a difference between two events within tens of hours… The accuracy is dependent on the stability of the crystal that used by the MCU. If I used gpio interrupt, I’d need a replacement of the main crystal in order to generate more accurate timing. I wonder if there is a possibility to have i.e. a 10MHz TCXO instead of the commonly used 12MHz crystal at USBizi…

Anyway, I’m still wondering if there is (will be) a more detailed documentation about how to use RLP interrupts… :wink:


Let me try one more time :slight_smile:

DateTime in interupt handler has property Ticks, wich is

Its accurate. I used it for timing remote control.

Changing crystal from 12 to 10 will change nothing. The way the ARM runs is:
It takes base crystal frequency. Then multiplies it to around 300-500MHz (PLL0) and then divides this fast clock (PLL0) down to core frequency wich is exact 72MHz. Timers get their time of the core clock.
If you change crystal, core clock will not change.

And I don’t know how to handle interrupt in RLP :-[ sorry

Edit: and there is Real Time Clock for long periods of time, wich is using own very acurate crystal :wink:


Rimvis: I’m coming from the PIC32 world, but I expected the crystal settings work the same way. If I change the crystal frequency, something would have to be changed in the USBizi firmware, right? Otherwise, timing of all peripherals could be wrong, since the internal frequency dividers and multipliers are set according to the crystal frequency.

You are right, those 32.768khz are accurate crystals, but not enough :stuck_out_tongue: At least not as much as temperature compensated voltage controlled crystal.

Thank all for the replies. Still it seems to me, that in case of using TCVCXO crystal I would need to let make changes in USBizi firmware or use it as an external timer source which tends to RLP.


The crystal use on USBizi is off by about 100 ticks per minute! That is 12000000 per second, that is 100 over a million error. Do you really need more accuracy? IF so I really want to learn about what you are doing as USB and CAN require very accurate crystals and they run perfectly on our devices!


Maybe I didn’t go into details enough and probably I should have used the word stability instead of accuracy. I’m sorry for that.
I’m talking about the stability over time, not the resolution. For example a ±20ppm crystal can make a difference of 720ms after 10 hours… That’s why if I want to measure a time difference between two events within few hours very precisely, then it doesn’t matter whether I have a 12Mhz crystal or 30kHz crystal. The only thing that matters is as little ppm as possible…


What is the stability of the oscillator you plan to use ? Becasue I know there are TXCO with 0.5ppm and that will lead to 18ms of error within 10 hours…

I think it could be done using .NETMF or RLP using TXCO as an external clock source using the XTAL2 input. You can have up to 2 crystals in your system, usually 12Mhz and 32.768 Khz, so you can replace the 32.768 Khz to your needs.


The right way to do this is by synchronization instead of trying to find the most stable (and expensive) crystal on earth :slight_smile: Of course may not be an option in your application but something to think about at least.


Well, there will be two scenarios, one with GPS 1pps sync and the other without it… I am aware of the fact, that even with 0.5ppm it’s quite unstable, but in such case I have the argument, that I reached the limits of commonly available parts…
Nevertheless, Pablo, you are saying that I can use an external clock source on XTAL2 input. But how can I use a i.e. 10MHz TCXO on XTAL2 without a change of firmware or RLP? If the answer is that it’s not possible without RLP or firmware change, then we are (at least partially) back at my very first questions :slight_smile:


You can’t change the crystal/clock from 12Mhz. You can contact GHI directly for custom firmware but for the cost/work needed, it makes more sense to just use 12Mhz.


Sorry I though that RTC oscillator could be used as a general one but it seems not.

Maybe you could use your own firmware without using NETMF or contact GHI to modify the firmware to fit your needs.


You can but I do not think the micro is set to take high frequency on the RTC clock pins.

You can although use an oscillator to click an internal timer. This is very easy to do.


Why not use an external spi or I2C RTC chip with Sopwatch function ?

By the way could you tell why you need to meassure that with such accuracy ?


Pablo: Thanks for your suggestion. Unfortunately I wasn’t able to find RTC with such accuracy, moreover with an option being sychronized by GPS pulse. Do you know about such IC? By the way, we already have such solution based on PIC32, there are just new requirements to extend communication interfaces. That’s why we are planning to move to .NETMF platform, because everything is so easy there. And I asked myself why having more chips if you can everything in one. :stuck_out_tongue:

Nevermind. After spending few days by testing, I can answer my first questions now :slight_smile: I guess it might be very helpful. All answers assume using USBizi… At the bottom you can see functional example of using TIMER1 in LPC2387.

It seems that only TIMER0 is used by .NETMF.

Irq_index is realy the irq index :slight_smile: <0;31> In other words, TIMER1 uses VIC channel 5 and therefore Irq_index must be 5 as well. Using hex mask index is not correct.

It is enough to call these functions at the RLP side. Of course, you need to write additional MCU specific registers to enable and configure the peripheral you want to use. For example writing PCONP.

Yes, you are responsible for clearing the interrupt flag. Otherwise the whole system stops working. Not doing this leads to neccesity deleting the deployment via TerraTerm in bootloader mode. (“D”)

Yes, it is possible. You can call it directly from the ISR. Unfortunately I don’t know which way the PostManagedEvent() is implemented. Since I’ve read somewhere in the forum, that the post managed event queue has limitation of 15 items, it seems that non blocking linked list is not very probable… (maybe a ring buffer?) Either way, there is no need to call GlobalInterruptDisable. Until now I didn’t gathered enough information about nested interrupts etc…

volatile int Test;

void Intr(void* arg)
	Test += 1;
	T1IR = 1;

int FunctionD(unsigned int *generalArray, void **args, unsigned int argsCount, unsigned int *argSize)
	Test = 0;

	PCONP |= 0b100;

        // this is partially copied from NXP App note.. I can imagine better approach to reset TC and PC ;)
	T1TCR = 0;
	T1TC = 0;
	T1PR = 4;
	T1PC = 0;
        // fire interrupt every 1/2 sec..
	T1MR0 = 2250000;
	T1MCR = 3;

	int val = RLPext->Interrupt.Install(5, Intr, 0);

	T1TCR = 1;

	return val;




I have used Posted events from RLP on a 50ms basics with no problems on a data adquisition system where I send 100 to 600 bytes of data from AD to the PC over USB cdc every 50ms.