Interrupt on Input Ports not thrown when initializong the RS232

@ LouisCpro -

I did look at the source code for the Serial class, in particular to see if it was doing anything with the RTS/CTS pins which would also overlap.

http://gadgeteer.codeplex.com/SourceControl/changeset

However it only reserves pin 7 if hardware flow control is requested which I’m not requesting for socket 7.

Plus it should throw an exception if I did request hardware flow control since socket 7 on the Hydra is of type U and not K which is the type needed for hardware flow control and the code in the Serial class explicitly checks to see if the socket type of of type K if you request hardware flow control and throws an exception if it isn’t.

@ Sean - OK

DO you use your interruptport from a module or directly in you main application ?

Same question for the UARTS ?

Directly, see my one code snippet I posted originally.


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);
}

@ Sean -

OK, but the snippet can be performed anywhere in you code, and I do not have you project full view…

Did you search on the thread side of the code ?

I mean that perhaps, the way you manage your several modules is not well done for thread compliance of the interrupts ?

If you try to progress in using Hydra, I should engage you in using Gadgeteer module and mainboard templates, that produce all the plumb to manage threads and instanciations correctly for you, using the Gadgeteer Core lib…

@ LouisCpro -

Yep, but the snippet does show that I’m creating the InterruptInput directly as opposed to using a module like GHI’s button module.

Remember the exact same code running without the Bluetooth module physically plugged in has no problem with the interrupt firing on socket 3 pin 3.

The main thread at startup creates the InterruptInput and the Serial instances and then creates a single thread which sits in a loop reading from one of the Serial instances and sampling some analog inputs and digital inputs and writes out a packet of data to one of the other serial instances.

So I don’t see any obvious threading issues.

Can you provide you full Main() so that we can see how you play with threads.

Generally it is better to only use Main to start building threads instead of creating direclty things in Main, and invoke Sleep() in Main to keep instance alive.

@ LouisCpro -


void ProgramStarted()
{
	InitDateTime();

	_data = new Data();
	_startupTime = DateTime.Now;
	_eventMarkerButtonLastInterrupTime = DateTime.Now;

	InitStorage();
	SetupLEDOutputs();
	SetupDigitalInputs();
	SetupAnalogs();
	InitUARTs();

	_loggerThread = new Thread(new ThreadStart(StartLogging));
	_loggerThread.Start();
}

So basically the main thread in calling ProgramStarted creates the serial instances and the digital inputs and then creates a logging thread which reads from the serial ports, samples the analog inputs and digital inputs and writes some data to some of the serial ports.

The main thread returns from ProgramStarted to run the main dispatcher loop, so no need to call Sleep().