I’m seeing a pattern where, when I attempt to get the signal from an IR remote control, if I have a buffer that is larger than the size of the IR command pattern, and I do not shorten it by using the overloaded Read method of SignalCapture, like so:
int edges = irSignal.Read(false, signal, 0, 100);
to only capture the first x number of transitions (where x is shorter than the full length of the IR command), then the program appears to hang. Additionally, if I stop debugging in Visual Studio, and try to restart, the debugger will not attach unless I restart the board, suggesting there’s a tight loop taking place somewhere in the SignalCapture code.
As long as the last argument to Read is shorter than the actual signal, it works. If I use this syntax, however:
int edges = irSignal.Read(false, signal);
Or if the last argument to Read is larger than the number of transitions in the signal, it appears to hang the board. No exceptions, just no response. Another symptom is that the IDE bogs down as well. For example, it takes many seconds to set or unset a breakpoint, once the issue arises, and it takes longer than usual to stop debugging.
@ devhammer - The read methods block internally until it has as much data as you asked for. When you don’t pass the length, we pass the length of the array you pass. Since you are only filling part of that array, the code blocks internally waiting for more data which will never come. If you know exactly how much data will arrive, I would resize your buffer or send that in the overload. Alternatively, the ReadTimeout property will let the method return eventually, with potentially incomplete data if you set it too short.
@ devhammer - I believe it is in ms, and that is correct. I do remember any major changes occurring since 4.2, so it should have functioned the same. I think I just moved the timeout parameter to a property.