Asynchronous interrupt trigger usage clarification

[venil7]

I'm trying to use this library to receive signals with generic 433mhz receiver (sender is a door sensor operating on the same freq). it seems like set_async_interrupt runs a lambda on another thread and will reset interrupt handler back to none, so that next interrupt doesnt trigger any lambda.

However radio receiver will trigger many interrupts, so I was wondering if you could provide a useful example of how to handle these signals

[golemparts]

Thanks for giving rppal a try! I'm not sure I correctly understand the issue. Normally you would call set_async_interrupt only once to configure the appropriate trigger and handler, after which the handler will execute on another thread any time the interrupt triggers. Are you calling that function multiple times instead?

Alternatively, you can use synchronous interrupts instead and block the current thread if that's more appropriate for your situation. In that case, you would call set_interrupt once to configure the interrupt trigger, and then call poll_interrupt any time you would like to block until it's triggered.

If I'm misunderstanding the problem, please include a snippet of the code you're currently using and a description of what you expected to happen, and what is actually occurring.

Thanks!

[venil7]

Thank you for a quick reply. I refer to this snippet in the documentation:
Any previously configured (a)synchronous interrupt triggers for this pin are cleared when set_async_interrupt is called, or when InputPin goes out of scope. - which gave me the impression that interrupt trigger would only be called once, then cleared, and so if I want it to continuously keep getting it triggered - I need to call set_async_interrupt again and again after each trigger.. maybe I'm misunderstanding API ?

[golemparts]

Ah I understand your confusion now. Perhaps I need to rephrase that part of the documentation to make it more clear.

You only need to call set_async_interrupt once to configure the interrupt trigger. After that, it will keep getting triggered and execute the callback until clear_async_interrupt is called or the InputPin goes out of scope, so you don't have to call it again yourself.

[venil7]

Thank you for your explanation, I'm happy to close the issue, or keep it open until you update documentation.

[golemparts]

Let's keep it open for now as a reminder to update the documentation. 😁