Till Harbaum

Thanks a lot. But as commented in your example i still see the manager thread receiving the ctrl-c and not the main thread.

I see this on two different ubuntu x86 machines and on a raspberry pi. On what kind of machin does this work for you?

If i replace the call to manager.run() by something trivial like a time.sleep() then the exception handling works as expected. So manager.run() somehow influences all this.

The closest thing i could come up with is this: https://gist.github.com/harbaum/db0a0928458fefc0793df66a5d377b16 But it e.g. requires the main thread to actively check for the manager thread to be still alive. Here...

This one also describes the same problem: https://stackoverflow.com/questions/28465611/python-dbusgmainloop-inside-thread-and-try-and-catch-block/28476630 The solution presented there also doesn't really solve the problem but rather works around it.

Please consider https://github.com/micropython/micropython/pull/7582 as a replacement for this one. The other one is more flexible as it exposes the PCNT API and implements the machine.Counter and machine.Encoder in Pyrhon which...

I would still like to understand why this PR is preferable over e.g. https://github.com/micropython/micropython/pull/7582 This one is IMHO significantly more limited than https://github.com/micropython/micropython/pull/7582 as it hides the underlying PCNT API...

IMHO there's a race condition in the current version. The hardware counter is reset immediately when the limits are reached, but it takes some time for the irqs to be...

I'll give your version a try. I have seen this race condiction on my version and I should be able to reproduce it with yours.

This needs further debugging. I have set the minimum and maximum limits to +/-32 and the hw counter actually behaves accordingly. But _wrap is not called at all. Has this...