PROS Interrupt Questions

mkirouac · December 18, 2014, 11:30pm

I have some questions related to interrupts in PROS…

Has anyone measured the interrupt latency (i.e. the time from the input signal edge to when the user’s InterruptHandler() begins?
While inside the InterruptHandler(), are further interrupts disabled?
Is there a way to enable/disable interrupts (including OS interrupts)?

I realize the third question would depend on some undocumented PROS functionality (perhaps something within the underlying kernel?)

Thanks!
Mike

jpearman · December 19, 2014, 8:16am

Never done that. PROS uses FreeRTOS underneath, perhaps google interrupt latency for FreeRTOS running on a 72MHz STM32F103 processor.

Depends on the interrupt handler, it’s priority and whether the handler chooses to enable interrupts.

Usually with FreeRTOS you would use taskDISABLE_INTERRUPTS and taskENABLE_INTERRUPTS. These map to code specific for the processor, you could duplicate this code.

What are you trying to do?
It sounds to me like you would be better of using ConVEX where all of this functionality is exposed to the end user.

mkirouac · December 21, 2014, 1:00am

I do have an oscilloscope…if I can get around to measuring it, I’ll be sure to share the results.

I would like to try making my own VEX sonar driver. Since it takes roughly 30 usec for sound to travel 1 cm, I’m curious how significant the interrupt latency would be as a source of error.

I will definitely check it out. Thanks for your work on that!

jpearman · December 21, 2014, 9:10am

Don’t forget you need to measure the time to and from the object so an object 1cm from the sonar has 2cm of travel for the ping. I use 58uS/cm.

The interrupt latency is a variable but I would expect it’s less than 2uS. I didn’t worry about it too much and assumed 1mm theoretical accuracy was enough for all practical purposes (ie. 6uS).

Edit:
So I measured the sonar interrupt latency in ConVEX, from falling edge of the received echo to the interrupt is about 3uS with less than 1uS worst case jitter. Here is scope capture showing echo (yellow trace) to a pin set high then low in the interrupt code (blue trace). Obviously harder to do with PROS as you do not have access to the interrupt function. I time to uS accuracy, an interrupt is caused when the ping is sent (rising edge of the yellow trace) so the 3uS offset is effectively added to both start and end of the timing, ie. the only error left is the 1uS jitter, so the error in measurement will be 1/58 cm or 0.17mm. There’s probably going to be more noise, that is variation in echoes, than this.

[ATTACH]8837[/ATTACH]

Here’s the modified ConVEX irq callback, I was toggling digital out 2.


/*-----------------------------------------------------------------------------*/
/*  Callback for echo receive pulse                                            */
/*-----------------------------------------------------------------------------*/

static void
_vs_echo_cb(EXTDriver *extp, expchannel_t channel)
{
    (void)extp;
    (void)channel;

    chSysLockFromIsr();
palSetPad( VEX_DIGIO_2_PORT, VEX_DIGIO_2_PAD );

    if( palReadPad( vexSonars[nextSonar].pb_port,  vexSonars[nextSonar].pb_pad ) )
        vexSonars[nextSonar].time_r = sonarGpt->tim->CNT;
    else
        {
        vexSonars[nextSonar].time_f = sonarGpt->tim->CNT;
        nextState = kSonarStateDone;
        }

palClearPad( VEX_DIGIO_2_PORT, VEX_DIGIO_2_PAD );
    chSysUnlockFromIsr();
}

mkirouac · December 21, 2014, 9:54pm

OK, I was able to measure interrupt latency for PROS using an oscilloscope and the following code:

void myhandler(unsigned char pin)
{
	digitalWrite(1, 0);
	return;
}

void mytask() {
	ioSetInterrupt( 2, INTERRUPT_EDGE_RISING, myhandler);

	while (1)
	{
		digitalWrite(1, 1);
		taskDelay(39);
	}

}

I don’t have a scope trace to show, but the display showed a very consistent 2.5 usec pulse, which I believe is a pretty good measure of the best-case latency.

I found a statement in the PROS API reference that says “the [handler] function will run in an ISR where the scheduler is paused and no other interrupts can execute”.

Interestingly, the same section (describing ioSetInterrupt) also says “Enabling pin-change interrupts consumes processing time”. I wonder why that is?

jpearman · December 21, 2014, 10:38pm

25uS is really slow, there must be other processing going on before you get into your handler. I didn’t even know that PROS had that function, guess I learn’t something today. As I said before, PROS is based on FreeRTOS. Usually when using FreeRTOS only certain calls are allowed in an interrupt, they usually end with “FromISR”, for example, to send to a queue you would use xQueueSendFromISR. I’m not sure what PROS allows in interrupts, I wonder if there is some glue code that wakes a high priority task or something rather than calling the irq handler directly, that may account for the long latency. Are you sure it was 25uS and not 2.5uS?

mkirouac · December 21, 2014, 11:31pm

You are correct. I edited the post to read 2.5uS.

mkirouac · January 2, 2015, 2:23am

Thanks! I was able to find the definition of those macros in the FreeRTOS distribution. I think I may not need it, but if I test it anytime soon I can update the thread (if anyone cares to know).

For the sake of those following this thread, the only time you might need this is if you write your own Interrupt Handler, and then only under very specific circumstances. One case I can imagine is if the Handler updates multiple variables that it shares with another task. That task may assume the variables were updated at the same time, but in fact there is always a remote possibility of the Handler running again between the time you read one of the variables and the time you read the other. The following mechanism can prevent this:

// Enter critical section
taskDISABLE_INTERRUPTS;

// Perform an uninterruptible operation
v1 = firstDataValue;   // set in Interrupt Handler
v2 = secondDataValue;  // set in same Handler

// Exit critical section
taskENABLE_INTERRUPTS;

// Continue processing
result = compareValues(v1, v2);

Keep in mind, disabling interrupts for too long can mess up system performance, so make it short and sweet. Or better yet, synchronize task/handler access using semaphores (http://en.wikipedia.org/wiki/Semaphore_%28programming%29). I think that’s what I’ll end up doing with my Sonar driver.