Page 4 of 4

Re: Esp32 port

Posted: Sun Mar 26, 2017 12:49 pm
by devnull
I think that there's only Damien and one or 2 more active developers that are working on the ESP32 port and of course all of this is voluntary and they have lots of other commitments too.

I don't know exactly how the 'joint development' works, but it appears that the only changes that are rolling into the ESP32 port are the ones developed by Damien and a few others, but I don't see any major functionality coming from the pycom port ??

Re: Esp32 port

Posted: Sun Mar 26, 2017 2:14 pm
by Roberthh
Since the ESP32 port does not support Pin interrupts, I tested it on a LoPy, just to find very digusting figures. Basically, the response varies by about 100 µs, but the whole time window of response travels in time between 50µ after the pulse up to 900 µs after the pulse in a periodic manner.
That looks like a serious problem.
I raise an comment on the Lopy board with pictures (easier to drop them there) https://forum.pycom.io/topic/936/pin-interrupt-latency

Re: Esp32 port

Posted: Sun Mar 26, 2017 4:25 pm
by pythoncoder
Thanks for testing, Robert. That latency is dire. Even worse than the ESP8266 :(

Re: Esp32 port

Posted: Mon Apr 03, 2017 7:18 pm
by Roberthh
@pythoncoder: Since with today's build the esp32 support Pin interrupts, I repeated the latency test. The figures are mostly consistent to the other tests:
- the irq latency varies between 20 and 380 µs, with the majority being less than 50 µs
- the response pulse is sometimes extended up to 220µs

Anyhow, I see that build positive:
- Pin IRQ is supported
- KeyboardInterrupt can be caught in an exception handler now. That was a bug, which also exists in the pycom builds.

Re: Esp32 port

Posted: Tue Apr 04, 2017 6:07 am
by pythoncoder
Progress, but 380µs is still dire compared to the Pyboard.

Re: Esp32 port

Posted: Fri Apr 07, 2017 12:12 pm
by Damien
As far as I could figure it out, the ESP32 will only ever support soft IRQ handling, with the associated variation in latency. That's because all IRQ handlers must be run from iRAM, and so the entire VM and runtime would need to be in iRAM to allow you to execute Python code on a hard IRQ. I don't see a way around this.

Sent from my GT-I9105P using Tapatalk