InterruptPort interrupt event "port" parameter

NETMF & Gadgeteer
1

I am using a FEZ Spider II (G120E) with NetMF (no Gadgeteer). I noticed that the event generated by an Microsoft.SPOT.Hardware.InterruptPort provides a “port” parameter (the first parameter) that has a different value than the Cpu.Pin that is used for creating the InterruptPort object.


InterruptPort interrupt_pin = new InterruptPort(GHI.Pins.FEZSpiderII.Socket4.Pin3, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
interrupt_pin.OnInterrupt += GPIO_OnInterrupt;


private static void GPIO_OnInterrupt(uint port, uint state, DateTime time)
{
  if ((Cpu.Pin)((port & 0x1F) | 0x40) == GHI.Pins.FEZSpiderII.Socket4.Pin3)
  {
    // this is surprisingly true
  }

  if ((Cpu.Pin)port == GHI.Pins.FEZSpiderII.Socket4.Pin3)
  {
    // this is surprisingly not true
  }
}

Is this normal behaviour? Or should the value match?

2

Create an inputport object first and then pass this to the interruptport.

3

I might not have clearly expressed the problem in the OP :slight_smile:

I want to use one event handler for multiple interruptport events but I have to know which pin caused the event to fire.

I believe that the first parameter to the event handler for an interruptport gives the Cpu.Pin that raised the event. The MSDN documentation is not at all clear about the parameters because they only describe the event handler as a generic NativeEventDispatcher.

The first parameter is almost the right value (see my example) but I don’t understand why it differs or what it actually means because I cannot find documentation about it. Tutorials about interruptports generally seem to ignore all parameters except for the “new state” (so does the Gadgeteer source btw.)

4

I think you are right and this maybe a bug that we need to investigate.

5

@ jjs -

This is a bug. Correct should be (on G120E or G120):


private static void GPIO_OnInterrupt(uint port, uint state, DateTime time)
{
           if (port >=32) 
                      port +=32;
           Debug.print("Correct pin is: "+port);
 }
1 Like
6

Thank you for investigating the issue! I suppose this will be fixed in a future SDK version? Then I have to keep this in mind because the workaround will break the functionality if this is fixed.