I've done an update on aremote.py. It is now cross-platform, running on ESP8266 and Pyboard. Rather than opaque integers it produces data and address values as args to the callback, which also supports user arguments. Bugs fixed and legacy cruft removed. Validation now implemented, with support for 16-bit extended address mode.
aremote.py and the two test programs art.py and art1.py. are here https://github.com/peterhinch/micropython-async.
This code has the following issues when run on ESP8266 with my hardware:
- Occasional 'Invalid start pulse' events in response to the 200µs pulses from the decoder.
- Occasional error events when an IR code is sent.
Note that the measured maximum interrupt latency of 643µs at 160MHz exceeds the pulse width of 562.5µs. This results in missed edges and consequent bad blocks. Evidently an interrupt driven solution on the ESP8266 is pushing things a bit: the chip is redolent of a leisured era when the Red Flag Act was in force...
The test program art1.py controls an on-board LED from the remote. Running this has led me to conclude that the ESP8266 port is usable provided the user gets feedback that the button has been recognised. Such errors can always occur (remote nearly out of range, low on battery or pointed in the wrong direction). But on the ESP8266 they are, alas, a `feature`. I'd be interested to hear your results/views.