IR receiver/transmitter for ESP8266?

[pythoncoder]

@mmh As I suspected there is a hardware issue. The decoder chip sometimes emits a 200µs pulse with no obvious cause. The signal and power look clean on my scope. This pulse happens much more frequently with the ESP8266 than with the Pyboard. The test program art.py now produces an 'Invalid start pulse' message when this occurs.

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.

[Heavily edited]

[mmh]

I'm still unsuccessful getting your codes to work on my setup seems like I'm missing some of the async capabilities and haven't been able to circle back here yet. So this is still work in progress and at this time I have nothing to report other than the import uasyncio doesn;'t go well for me. I went searching for it and came up with an empty file. I struggled for a couple of hours and haven't been able to return, I really want to compare your async stuff which looks amazing.

[pythoncoder]

[EDIT]Reflecting a recent firmware fix.

I'm assuming your problem is that

Code: Select all

import uasyncio

is failing.

Get the most recent version of the source.

Unfortunately the asyncio library is large and needs to be installed as frozen bytecode. This is further complicated by the fact that the ESP8266 firmware is arranged to run, and provide a VFAT filesystem, on devices with only 1MB of flash. This leaves insufficient space so you need to make more space for firmware at the expense of a little VFAT space. Assuming you have more than 1MB you need to do the following.

Implement the changes I describe in my last message here https://github.com/micropython/micropython/issues/2700. This makes room for the frozen files.

Using the Unix build install the uasyncio library using upip (https://github.com/micropython/micropython-lib). Verify that in the Unix build you can issue

Code: Select all

import uasyncio

Go to ~/.micropython/lib and recursively copy the contents to esp8266/modules
Build and deploy. You should now be able to import uasyncio.

It is a bit technical; it's absurdly easy on the Pyboard (no need for frozen bytecode), but that's the resource constrained ESP8266 for you

[kgschlosser]

I know this is an older topic. I am trying to accomplish a similiar task. I do not want to decode the IR at all i want to be able to receive the IR and then send the RLC (raw timings) over the WiFi to a PC that will handle the decoding aspects. I also want to be able to receive RLC over the WiFi and blast it.

I would imagine that this would be able to be done with less issues with the timing when a GC happens. I do not know what would be the best way to be able to capture bursts and also the modulation of the bursts

[pythoncoder]

You might want to glance at my IR solution. I concluded that the ESP8266 is unsuitable for blaster applications. The ESP32 and all Pyboards can do this. The ESP32 is particularly capable because of the RMT hardware.

To anyone reading this thread my comments about uasyncio in my above post are out of date and don't apply to uasyncio V3.

[BabooMookerji]

So I've got an ESP32-S with two UARTS at 62.5 and 202Kbps, with a hopeful but likely unrealistic <1ms realtime requirement, to mux both of those serial channels into a third UART operating at 460800. But after reading your other thread about soft interrupt issues with ESP32-S, I then went down the rabbit hole of uasyncio with your fast_io v2 modifications.

So a uasyncio v2 fast_io platform get around FreeRTOS soft scheduling latency? Or should I still be looking at a PyBoard solution for what I am trying to accomplish.

[pythoncoder]

You may be misunderstanding what fast_io does. Incidentally I'm hopeful that the next release of official uasyncio will make it entirely obsolete.

The fast_io version enables uasyncio to handle continuous I/O throughput at a higher rate by testing the status of I/O on every iteration of the scheduler. Current official uasyncio only checks I/O when all other competing tasks have been scheduled (uasyncio V2 is even slower in this regard). The fast_io version has been used in applications such as I2S which require continuous uninterrupted throughput. However continuous throughput is not the same as latency.

It can't work miracles in terms of general realtime latency. ESP32 has poor interrupt latency, especially with SPIRAM, because its interrupts are soft IRQ's which cannot proceed if a garbage collect (GC) is in progress. All versions of uasyncio rely on cooperative scheduling. This implies that if a GC takes place in any task, that task necessarily blocks for that period. This can be minimised by running a task which periodically performs a GC: doing this reduces the blocking time by minimising the work that the GC has to do by doing it before MicroPython decides it is necessary. If RAM fragmentation is minimal, GC can take as little as 1ms on a Pyboard. Much, much longer on an ESP32 with SPIRAM. I have measured 100ms.

I haven't done a great deal with ESP32 UARTS, but I would assume that they are properly buffered and serviced by hard IRQ's in the C code. However my comments about the response of MicroPython to realtime events are general: latency is much lower on bare-metal hardware.

For any serious realtime work a Pyboard wins over hardware with an OS or other background processing because it has fast and deterministic response to interrupts: its hard IRQ's will pre-empt GC (requiring care in the ISR implementation). Further, the Pyboard D devolves WiFi to a separate chip which avoids overhead for WiFi processing.

That said, uasyncio in any form has its own limitations in terms of latency as discussed here.

[BabooMookerji]

Thanks so much for the reply, very enlightening.

[BabooMookerji]

Another question: so where does the ESP8266 fit into this equation? Is it also hampered with FreeRTOS under the hood in terms of software-driven interrupts?

[pythoncoder]

ESP8266 does not run FreeRTOS however its IRQ's are soft IRQ's for reasons connected with its internal architecture. This means it suffers from substantial latency, potentially of several ms if an IRQ occurs when a GC has just begun.