Alternative decoding solution

[alainman-krh]

I was unaware this library could detect the hex "code" representation from pulses - so I ended up writing my own solution.

NOTE: I also based my solution off of pulseio. It seems pretty responsive and relatively robust.

Feel free to take ideas from it if you want (or code, etc).

Where it resides

I outlined where to find code and upload on Adafruit Playground:
https://adafruit-playground.com/u/Alain_ManHW/pages/pc-media-remote

At the time of writing, the "media remote" example lives here:
https://github.com/alainman-krh/Projects_Circuits/blob/main/PCMediaRemote/pkg_install/MediaRemote_RP2040/main.py

And the library here:
https://github.com/alainman-krh/Projects_Circuits/tree/main/PCMediaRemote/lib_cktpy/CelIRcom

If you try out the "MediaRemote_RP2040/main.py" example, I think you'll find it pretty responsive and easy to customize.

Highlights/ideas that could be used here

Uses measured tick length (tickUSm, auto-detected from preamble period) to sample pulseio:

• Main detection algorithm: msg_sample(ptrainK_buf, ptrainUS, tickUSm, istart_msg, doneUS)
• Decoding is done in a separate pass. You can re-use the same sampling data and test/decode against multiple protocols.
• Nonblocking by default.
• Mimicks hardware/PLL-like algorithm that periodically re-centers sampling instant instead of using "fuzzy" range detection.
• NOTE: (space * 0.75) <= pulse_length <= (space * 1.25) is what I call "fuzzy" range detection.
• Though I have not benchmarked my code heavily, I believe mimicking hardware sampling this way reduces CPU overhead (more time to process other buttons, etc).
• I typically try to minimize "if" statements within dominant loops to reduce branch prediction workload.

Defines structure of "PDE"-based decoders in "Protocols_PDE.py":

• DecoderNEC(), DecoderNECRPT(), DecoderSamsung().

Defines structure of "PLE"-based decoders in "Protocols_PLE.py":

• DecoderSony20(), DecoderSony12().

Other ideas (less in-line with CircuitPython lib styles)

EasyIRRx.py is an experiment on applying event handling/"reactive" paradigm.
You can inherit from EasyRx classe to implement your own version of:

• handle_press(self, msg:AbstractIRMessage)
• handle_hold(self, msg:AbstractIRMessage)
• handle_release(self, msg:AbstractIRMessage)

I eventually wanted to support things like handle_doublepress() - but I don't yet have a need for that.

I am aware this doesn't line up with the coding style of most modules -- just something interesting to think about. I feel like it shouldn't be too difficult for people to use... especially since alot of the internal state of "is the button currently/previously down" (etc) doesn't need to be handled directly by the user. But I get that it is a more advanced (higher level) type of programming.