I have a simple bit of code that firstly registers a button handler on the main thread, and then creates a SignalCapture class on a new thread and subsequently calls the signalCapture.Read(…) method. I do have some other code that generates a signal, but for the purposes of this issue, I have narrowed it down to the following.
When I press the button, the handler does not get called, and it seems to me that that the signalCapture.Read(…) is blocking the main thread - I have confirmed that the SignalCapture thread has a separate ID to the main thread. Only once the signalCapture.Timeout expires, does clicking the button call its handler.
I am guessing that all pin reads are done on the main thread, hence the reason my SignalCapture thread is blocking on Read(…). If this is the threading model for Gadgeteer, is there anyway to marshal the pin input onto another thread so my main thread does not get blocked?
@ Mike - Thanks. I thought that might be the case. I’ll keep the GHI API ref bookmarked in future!
Is it the case then that there is no way to do asynchronous read/writes on separate pins then? The application I am writing is generating a signal on a pin using RLP, but I’d like to be able to run an asych SignalCapture to double-check that what I am writing out to a pin is actually being Tx.
@ Mike - Thanks, good to know that, so I don’t waste anymore time on the impossible! Seeing that I don’t have a spare board to hand (it might be my only option to buy one), I’ve got a few other things to try first. Working out the timing of an RLP call might allow me to fix my issue, but as its off topic I’ll do a new post. Thanks.
I found this Codeshare - ‘RLP Serial Debugging’ https://www.ghielectronics.com/community/codeshare/entry/268
I hooked it up to COM2 on my FEZ Spider, and I can see data being Tx from my RLP (I am working with a serial signal, so works nicely).
