I’m reading in PWM signals from my RC controller, the pulse width is from approx 1 to 1.85 ms, so it has to be pretty fast. I’m using the interrupt pin for reading signals in and the PWM pin for the outputs. It all works fine, but to make the interrupt handler fast enough I had to set the SynchronousUnsafeEventInvocation to true. I don’t truly understand what this is doing to my application, thread handling and such.
According to the docs:
“An interupt may occur on a thread other than the application thread. When SynchronousUnsafeEventInvocation is false (the default), the Interrupt event, which is raised in response to the interrupt on the interface, is marshalled to your application thread and raised asynchronously; whenSynchronousUnsafeEventInvocation is true, the Interrupt event is raised synchronously on the same thread that generated the interupt.”
Anyone out there with a deeper understanding on this that could shed some light on this? It seems to me not to mean much as the application is running now, but if I have other threads running etc, I’m wondering how it would work. It’s hard to debug these things as well, so I guess the best way about it is to truly understand this.
I did by the newest book on .NET 4.1/4.2 from Annabooks, but I did not find much on this.
I have some more detailed information and code in my blog
I never tried this myself and never heard of anyone trying it. The only way to find out is by getting an answer from mirosoft directly. www.netmf.com or by digging into the source codes (which will be a nightmare )
Thanks, I’ve tried the gadgetdeer forum, but it’s not very active, so tweeted them and maybe someone can help me out.
Problem now is that my question isn’t that clear, things does work now when the property is set to true, it is just that I don’t know what it does or if it will work properly with multiple threads. I guess I will need to do some experiments with multiple other threads doing some work and see if it still works. Shouldn’t be hard to test a few different cases.
It sounds like your interrupt routine is being called directly from the internal interrupt handler rather than having the interrupt queued for processing.
I suspect that while your interrupt handler is being called directly other interrupts are disabled. This means you could be losing interrupts if your processing takes too long.
Ok, thanks, I’ll stick with that explanation for now.
That means it should only affect the other PWM input I am planning to hook up, and not the other, lower priority threads. It should be possible to work around that, as I know that if one PWM signal is lost, I know approx. at what time I lost it, and I’ll use the timestamp from the other pin.
If I’m really lucky, the RC receiver is sending the signals with some delay between - I’ll hook the logic analyzer back up again to look more closely on the signals.
if (this.SynchronousUnsafeEventInvocation)
{
try
{
this.Interrupt(sender, value);
}
catch
{
}
}
else
{
if (this.onInterrupt == null)
{
this.onInterrupt = new InterruptEventHandler(this.OnInterruptEvent);
}
if (Program.CheckAndInvoke(this.Interrupt, this.onInterrupt, sender, value))
{
this.Interrupt(sender, value);
}
}
I’ll try to dig into the NET MF source to find out what really happens in this Interrupt routine… Having some issues with the codeplex-server right now.
And I think an PWM input device would be a cool idea for a Gadgeteer module, complete with standard connectors to connect it straight into RC receivers.
)