Interrupt on Input Ports not thrown when initializong the RS232

Archive
1

ussied from this thread : http://www.tinyclr.com/forum/topic?id=10574&page=6

I had a problem with some input interrupts, and try to find why : I found that if I remove theses lines in the InitializeMOdules() method of my mainboardapplication :


rs232 = new GTM.GHIElectronics.RS232(5);
 rs232.Initialize(230400, Gadgeteer.Interfaces.Serial.SerialParity.None, Gadgeteer.Interfaces.Serial.SerialStopBits.One, 8, Gadgeteer.Interfaces.Serial.HardwareFlowControl.NotRequired);
rs232.serialPort.DataReceived += new GT.Interfaces.Serial.DataReceivedEventHandler(serialPort_DataReceived);

The interrupt comes back normally on all the input ports !

Can someone explain what would be the influence between RS232 and InterruptPort ? Does it mean both can not be used ?

2

Hi Andre,

I made some tests more, and found that ‘‘some’’ of my inputs do not throw interrupt when initializing the rs232 module.

The instruction that inhibate this is

 rs232.Initialize(...);

If I only do the ‘new’ or even comment all, it is ok.

Now I’m invastigating in the gadgeteer module to see if I can find some reasons to explain why, and my question was : Does anybody already encounter such problem on Interrupt when using the rs232, and did they find any solution ?

But I recognize this could not be clear as well when reading the subject…

3

If I have a look in the Serial Interface of Gadgeteer, the new is like this :


            this._serialPort = new SerialPort(portName, baudRate, (System.IO.Ports.Parity)parity, dataBits, (System.IO.Ports.StopBits)stopBits);

How does it make the link between the portName and the given socket ?

4

Also tried :

  1. with [SynchronousUnsafeEventInvocation = true] on the InterruptInput and no changes !
  2. by ovvreding HardwareProvider to enforce the GetSerialPins with the right pins values…no changes !

Does anyone have an idea on what is happening ?

Please :’(

5

@ LouisCpro

What are the processor pin assignments for the interrupts that are failing when RS232 is enacted and what are the processor pin assignments for the RS232 interrupts?

6

@ Aron,

Interrupt Pins that fails are E8, E9 and E11.

For the RS232, I use D8 (TX) and D9(RX).

7

@ LouisCpro

I believe that this issue is due to the STM32F4 interrupt limitation. The GPIO interrupts share 16 channels which are multiplexed to the same port number such as PA3, PB3, …, and PE3, etc. If you need both the RS232 and the interrupts, a suggestion would be to use a different port number for the interrupts and see if this will clear up the issue.

This information is now up on the Wiki found here: http://wiki.tinyclr.com/index.php?title=Cerb-Family#STM32F4_Interrupt_Pin_Limitations

8

@ Aron,

Thanks for your feedback ! For PE11, I only have USBD- (USB to PC) on PA11, no other multiplex… Do you think it also uses INT ?

9

@ LouisCpro

I am uncertain, but judging that the pin ports are the same, it is possible that they are indeed multiplexing the same port.

10

@ Aron -

OK. I imagine what a problem it has been to put 8 sockets on the Cerberus without doing the same error I did !

In some case it sounds like we should prefer using external chips such as PCF8575 with INT instead of charging the CPU interrupt Pins…

Is there any limitation like this on the G120 ?..or others I should take care of before switching ?

11

@ LouisCpro

To the best of my knowledge G120 does not have such constraints; however, only ports 0 and 2 have interrupt capable pins. These pins may be shared with other peripherals but not with other interrupts.

12

OK Aron

I’m going to re-invoke my G120HDR with some addins, and try to achive the goal !..

13

I’ve just run into the same issue with the Fez Hydra, was about to create a new post but found this one.

I have 4 UARTs that I open:


void InitUARTs()
{
	_rockwellComPort = new Serial(GetSocket(6), 115200, Serial.SerialParity.None, Serial.SerialStopBits.One, 8, Serial.HardwareFlowControl.NotRequired, null);
	_bluetoothComPort = new Serial(GetSocket(7), 115200, Serial.SerialParity.None, Serial.SerialStopBits.One, 8, Serial.HardwareFlowControl.NotRequired, null);
	_pcComPort = new Serial(GetSocket(5), 115200, Serial.SerialParity.None, Serial.SerialStopBits.One, 8, Serial.HardwareFlowControl.NotRequired, null);
	_telemetryComPort = new Serial(GetSocket(4), 115200, Serial.SerialParity.None, Serial.SerialStopBits.One, 8, Serial.HardwareFlowControl.NotRequired, null);

	_rockwellComPort.Open();
	_bluetoothComPort.Open();
	_pcComPort.Open();
	_telemetryComPort.Open();

	_pcComPort.DataReceived += new Serial.DataReceivedEventHandler(_pcComPort_DataReceived);
	_bluetoothComPort.DataReceived += new Serial.DataReceivedEventHandler(_bluetoothComPort_DataReceived);
	_telemetryComPort.DataReceived += new Serial.DataReceivedEventHandler(_telemetryComPort_DataReceived);
}

I also setup a digital input with an interrupt handler.


void SetupDigitalInputs()
{
	Gadgeteer.Socket socket3 = GetSocket(3);

	_eventMarkerInput = new InterruptInput(socket3, GT.Socket.Pin.Three, GlitchFilterMode.On, ResistorMode.PullUp, InterruptMode.FallingEdge, null);
	_eventMarkerInput.Interrupt += new InterruptInput.InterruptEventHandler(EventMarkerInterrupt);
}

What I’ve just noticed is that if I have the Bluetooth module physically plugged into socket 7 then the interrupt on socket 3 pin 3 doesn’t fire. I can still read the state of the digital pin but the interrupt doesn’t fire.

If I simply unplug the Bluetooth module, but leave the code in to create a Serial object for socket 7 and call Open on it then the interrupt on socket 3 pin 3 does fire.

So it looks like there is also some similiar constraint on the Fez Hydra?

Thanks

14

@ Sean -

To be sure, look at wat PIN is behind the Socket 3, P3, and then if it is also used on socket 7…

I don’t know if ARM9 has the same MULTIPLEXING limitations indeed…

15

@ LouisCpro -

Yep I’ll take a look.

I guess I was a bit suprised, I sort of assumed given it was a gadgeteer system as opposed to a plain netmf system that I shouldn’t need to worry and have to double-check cpu pins for possible clashes. I assumed that given the available sockets exposed and as long as I used them given their supported socket types that I wouldn’t run into this sort of issue.

16

Had a look at the pin mappings between socket pins and CPU pins for the Fez Hydra.

Socket 3 Pin 3 – PB8/PWM0

Socket 7 Pin 7 – PWM0

So there is a shared CPU pin between the 2 sockets.

However socket 7 is a U/P type socket and the Bluetooth module requires a U type socket and for a U type socket pin 7 is supposed to be unconnected.

So in this case since I’m only using socket 7 as a U type socket for the Bluetooth module shouldn’t socket 7 pin 7 remain unconnected and therefore not intefere with me receiving interrupts on socket 3 pin 3?

17

@ Sean -

Right, but also be careful that sockets can have multiple types on each, and for example 2 I type sockets, does not mean there is 2 I2C on the CPU, but just that you can choose betwen both to plug you I2C module…

In the same way, if you look at a board which has 12 sockets, it can not mean that there are 120 PINS avaiable on the CPU…

Gadgeteer almost simplify the hardware considerations by abstracting PINS to socket types, and provide fully implemented module drivers for you to play with, without having to develop all the drivers.

I also learned recently how to build a module from scratch, and it is very powerful if you want to desing your own driver and hardware, but a good thing is starting with existing one to understand well how all of these stufs operate !

18

Bluetooth pin 7 is unsoldered, so that it can not interfer ! but something strange is PWM that you use as an interrupt port ? PWM is generally an output !
Did you try the interruptport on another Y socket ?

19

@ LouisCpro -

I was about to say that given the socket 3 pin 3 works as an interrupt pin as long as the Bluetooth module isn’t physically plugged into socket 7 that there must be some electrical connection being made by the Bluetooth module on socket 7 pin 7 even though it’s listed as a U type module and so pin 7 should be unconnected.

At the time when I chose socket 3 pin 3 I didn’t look up in the schematic to see that it was also a PWM pin on the CPU. I simply looked at socket type for socket 3 which is S and Y and pin 3 on a Y socket is listed as being a GPIO pin with interrupt capability G!, and everything was working fine with the interrupt firing until I physically plugged the Bluetooth module in.

20

@ Sean -

I checked the AT91 datasheet and seems to be 4x32 channel GPIO with interrupt on each…

Maybe it is more a problem on code side… DId you have a look on the gadgeteer modules source code ? It is also possible that even if not implmented physically, the socket PINS are however initiated by the Gadgeteer Core library …