10 replies to this topic

[Frode]

Hi guys, 

I've got some sensors that I've written drivers for which use InterruptPort to notify whenever something happens.

 

The problem is that the very first time the event triggers it takes one or two seconds to fire. All subsequent events are raised instantly.

 

I assume that this has to do with the way .NETMF runs code, so I'm not sure if there is any way around it. I've tried to manually call the eventhandlers after my board has booted, just to warm up all the bits, but the first time the event is raised it is still very slow.

 

Is anyone else seeing the same? Is there anything to do about it?

[Chris Walker]

Hi Frode,

If you run MFDeploy, connect to your board via F5 and then trigger an interrupt, do you see the same issue?

Also: while debugging in Visual Studio: if you write out a statement via Debug.Print when your project starts, do you see the same issue?


Chris

[Frode]

Hi Chris, I've tested some more. Here is some simple code where it is slow the first time.

public class ProgramNetduino2
{
    static OutputPort blueLed = new OutputPort(Pins.GPIO_PIN_D9, false);
    static InterruptPort button = new InterruptPort(Pins.GPIO_PIN_D12, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);

    public static void Main()
    {
        button.OnInterrupt += button_OnInterrupt;

        Thread.Sleep(Timeout.Infinite);
    }

    static void button_OnInterrupt(uint data1, uint data2, DateTime time)
    {
        Debug.Print("Button interrupt caught.");
        blueLed.Write(data2 == 0);
    }
}

When testing it seems like the first interrupt is only slow when I debug from Visual Studio. If I disconnect from Visual Studio, and just power the board, it works as intended.

 

I also tried starting up MFDeploy, powered up the Netduino 2 (running 4.3), pressed F5 to connect, and then clicked the button to trigger the event. It was fast there as well.

 

So I'm beginning to think that this is a problem only when debugging from Visual Studio.

[Frode]

Here is an even simpler example - no external parts required. Just a Netduino 2 with 4.3.1 firmware.

 

The first time you press the onboard button the led doesn't react the same as the next times you press. But still looks like this only happens when debugging through Visual Studio (2013).

public class Program
{
    static OutputPort blueLed = new OutputPort(Pins.ONBOARD_LED, false);
    static InterruptPort button = new InterruptPort(Pins.ONBOARD_BTN, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);

    public static void Main()
    {
        button.OnInterrupt += button_OnInterrupt;

        Thread.Sleep(Timeout.Infinite);
    }

    static void button_OnInterrupt(uint data1, uint data2, DateTime time)
    {
        Debug.Print("Button interrupt caught.");
        blueLed.Write(data2 > 0);
    }
}

[Frode]

Perhaps someone else can try this simple code and confirm that they see the same...?

[Frode]

Anyone? It'll just take a couple of minutes to test the code above. No jumper wires etc required to test the simple code above.

 

It would be very nice to get a verification from someone.

[baxter]

Not VS 2013, but Using C# 2010 Express, MF4.2 and pushing the button on a Plus 2, yields nearly instantaneous debug output and led blink.

--> Button interrupt caught.

[Frode]

Thanks Baxter - I'm thinking it might be an 4.3.1 or a Visual Studio 2013 problem. Would be interresting to see if others could test as well.

[sfx]

Hi Frode,

 

I'm running VS 2013 with NETMF 4.3 QFE1, but I didn't find the interrupt port to respond slowly during debugging. I ran your code a handful of times and each time found the actuating latency to be largely uninhibited.

 

Hope that helps.

 

Nathan

[Frode]

Hi Nathan, thanks for testing. Just to be sure - after deploying to the Netduino I'm seeing a 1-2 second delay when I click the onboard button the first time. Your not getting the same?

 

On all the subsequent buttonclicks the LED responds immediately, but the very first time it is sluggish for me.

[sfx]

Hi Frode,

 

Yes, that's right. I just tested it again and found that the initial press after deploy was trapped by the debugger almost immediately.

 

Nathan