Open jkristell opened 4 years ago
Hi!
Interesting. I have to look into this a bit more. Could you send me a log of the raw elapsed_us values?
@riskable I found this issue a hard way. In my device I using internal MCU oscillator(too much ppm's) as system clocks and NEC command parsing become really unstable.
FYI: I was looking for a workaround to the inability to control this very thing (tolerances) and came up with this:
...and it works surprisingly well! Like, flawlessly. Basically, I've got the IR pin tied to IO_IRQ_BANK0 and triggering on High and Low (just like in the RP2040 example I wrote a while back). The value that gets passed to
ir_recv.event_iter()
seems to be the key part.Basically, when I first started this code the IR remote worked OK-ish... Had to re-press a button about 25% of the time. However, as time went on and the project grew the IR events became more and more unreliable to the point where they would only work like 10% of the time. I knew why: I had too much simultaneous crap going on! haha. This was messing with the very precise timing required by
infrared
. I haddefmt
print out theelapsed_us
value with each call of my interrupt-bound function and did theexport DEFMT_LOG=trace; cargo run --release
thing and that's when I had my "Aha!" moment.Here's the full function code in case you need more context:
I haven't had the chance to test it with other kinds of remotes yet. NEC is the one I'm planning on putting my full support behind regardless.