I’m having problems with InterruptPort. I’m prototyping touchscreen driver (STMP610 via I2C) before trasferring in native C++ code and I need INT signal from the touchscreen chip that is tied to PA0, but when I try to assign event function to the InterruptPort I get an exception. Any other port/pin works fine.
The firmware is compiled by me on FEZCerb base. I’ve no other reservation or peripheral defined on PA0 … for what I know.
public TouchScreen()
{
touch_int = new InterruptPort((Cpu.Pin) 0x00, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
touch_int.OnInterrupt += touch_int_OnInterrupt; <-- Exception
//touch_int.ClearInterrupt();
touch_int.EnableInterrupt();
I2CDevice.Configuration i2c_config = new I2CDevice.Configuration( TouchAddress, 400 );
touchI2C = new I2CDevice(i2c_config);
}
static void touch_int_OnInterrupt(uint data1, uint data2, DateTime time)
{
// Touch interrupt
byte[] rbuff = I2CRead(0xd7, 4);
Debug.Print("Got Touch Interrupt!");
touch_int.ClearInterrupt();
}
///// Exception
Eccezione first-chance di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll
Eccezione first-chance di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll
Eccezione non gestita di tipo 'System.ArgumentException' in Microsoft.SPOT.Hardware.dll
Not sure if this limitation enforced by hardware or just by the PK only. If this is PK only then you should be able to fix this easily (you are compiling the firmware already).
You will need to change the size of the array that stores the interrupt handlers and use pin and port number for indexing instead of just pin number.
Let me know if you need help to track the exact spot for that.
Theorically if you don’t need to reflect native int to managed code, may be you have no problem. This is not a limitation of the SMT32F4 chip, it has 23 exti io mappable to pins …
Tomorrow I will check the code … this is a big issue becouse the board is wired and I can’t change pins. I wasn’t aware of this.
BOOL STM32F4_GPIO_Set_Interrupt( UINT32 pin, GPIO_INTERRUPT_SERVICE_ROUTINE ISR, void* ISR_Param, GPIO_INT_EDGE mode, BOOL GlitchFilterEnable)
{
UINT32 num = pin & 0x0F;
UINT32 bit = 1 << num;
UINT32 shift = (num & 0x3) << 2; // 4 bit fields
UINT32 idx = num >> 2;
UINT32 mask = 0xF << shift;
UINT32 config = (pin >> 4) << shift; // port number configuration
GLOBAL_LOCK(irq);
if (ISR) {
if ((SYSCFG->EXTICR[idx] & mask) != config) { <-- doesn't take correctly in account the port number
if (EXTI->IMR & bit) return FALSE; // interrupt in use
SYSCFG->EXTICR[idx] = SYSCFG->EXTICR[idx] & ~mask | config;
}
.....
It seems that the [em]STM32F4_GPIO_Set_Interrupt( UINT32 pin, GPIO_INTERRUPT_SERVICE_ROUTINE ISR, void* ISR_Param, GPIO_INT_EDGE mode, BOOL GlitchFilterEnable) [/em] function doesn’t take in account the port when check int register. But the things are not so easy …
If you read the STM32F4 manual, you’ll see that interrupts are multiplexed across pins. You can set PA0’s interrupt, but then you’ll lose PE0’s. This limitation has nothing to do with NETMF or how the port was written; it’s an actual limitation of the processor.
Yes, I know about SYSCFG_EXTICRx limitation for pins. This can be managed in many situations in c/c++ code, but not in this case where PE0 is INT for Ethernet ENC28. Thank you in any case …