InputCaptureEx oddity

[GTBecker]

I'm using InputCaptureEx to measure the high and low periods of a '555 output cycle, usually correctly. Maybe 1% of the time, however, I see an entire cycle, not just a high or low period, in the high (first) count. For example:
ZX-24n:

[spamiam]

The only thing that I can think of is that another task is blocking interrupts at just the wrong moment. Does your application have other tasks that might interfere with input capture interrupt servicing?

You might try to strip down your program so that it only records the input capture, but does nothing else at the time. That might eliminate the possibility of another task interfering with the input capture.

-Tony

[GTBecker]

I am using three simple tasks (sampling, display and command receipt) but I'm not deliberately blocking interrupts anywhere. I found, though, that placing a pair of Locktask/Unlocktask functions around the capture served only to prevent remote downloads via AtnChar (the project is in a box at the wellhead and talks via Bluetooth). They had no effect on the capture.

I'm leaning toward a dirty signal so I'm going to try slowing the risetime of the '555 a little - and substitute a clean bench-generated squarewave - to see what that does.

[GTBecker]

As should be the case, a clean 400Hz squarewave is measured accurately by InputCaptureEx. I also tried capturing four periods so I could use the third and fourth periods to avoid the first two suspect periods; the result was the same as capturing two periods. I guess the '555 and processor breadboard is sufficiently noisy to cause the '555 to trigger irregularly.