micropython R1.9 ETA @@ released @@

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
User avatar
devnull
Posts: 344
Joined: Sat Jan 07, 2017 1:52 am
Location: Singapore / Cornwall
Contact:

micropython R1.9 ETA @@ released @@

Post by devnull » Mon May 08, 2017 2:02 pm

Hi;

viewtopic.php?f=16&t=2140#p19545
Changes in upcoming MicroPython 1.9:
upip: Optimized memory usage and error handling, should be much more stable now.
uasyncio: Both uasyncio.core (production) and uasyncio (preview) are shipped in the release builds as frozen bytecode and available for optimized use.
OTA support for MicroPython binary: viewtopic.php?f=16&t=3262
Improved documentation
Work on this release underwent for several months, so there're a lot of bugfixes and some improvements.
Just wondered when this is expected to be released ?
Last edited by devnull on Fri May 26, 2017 11:34 am, edited 1 time in total.

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: micropython R1.9 ETA

Post by pfalcon » Sat May 13, 2017 11:14 pm

"Soon"
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

Damien
Site Admin
Posts: 610
Joined: Mon Dec 09, 2013 5:02 pm

Re: micropython R1.9 ETA

Post by Damien » Mon May 15, 2017 10:20 am

Hopefully within the week.

Sent from my GT-I9105P using Tapatalk

User avatar
devnull
Posts: 344
Joined: Sat Jan 07, 2017 1:52 am
Location: Singapore / Cornwall
Contact:

Re: micropython R1.9 ETA

Post by devnull » Fri May 26, 2017 11:32 am


User avatar
ioukos
Posts: 33
Joined: Wed Oct 19, 2016 11:31 am
Location: Alsace, Europe

Re: micropython R1.9 ETA @@ released @@

Post by ioukos » Fri May 26, 2017 1:41 pm

Great job, I'm looking forward trying this new version !

Is it 100% compatible with code written for 1.8.7 ?

Thank you in advance.

User avatar
pythoncoder
Posts: 3496
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: micropython R1.9 ETA @@ released @@

Post by pythoncoder » Sat May 27, 2017 7:54 am

ioukos wrote:...Is it 100% compatible with code written for 1.8.7 ?...
The changelog is here http://micropython.org/resources/microp ... ngeLog.txt.

One thing that stands out is:
"machine.Pin high/low methods are renamed to on/off in esp8266 and zephyr (this is a backwards-incompatible change)"
Peter Hinch

jcea
Posts: 27
Joined: Fri Mar 18, 2016 5:28 pm

Re: micropython R1.9 ETA @@ released @@

Post by jcea » Sun May 28, 2017 12:28 pm

pythoncoder wrote:
ioukos wrote:...Is it 100% compatible with code written for 1.8.7 ?...
The changelog is here http://micropython.org/resources/microp ... ngeLog.txt.

One thing that stands out is:
"machine.Pin high/low methods are renamed to on/off in esp8266 and zephyr (this is a backwards-incompatible change)"
I think this change is a mistake because "on" or "off" depends of the external electronic components. "on" and "off" doesn't makes sense at all when you don't know if you are providing current to or sinking current from the external circuitry.

Another thing I don't like is that now "Timer" is a soft interrupt. That is a nice change if the timer has no real time needs or low latency is not a must. I have projects with 1ms timers where jitter should be lowest possible (and yes, I am fully aware that ESP8266 is not a real time system) and this change could push me to keep using 1.8.7 :-(. Would be far more convenient if "Timer" had an optional parameter to request "soft" or "hard" interrupt. I wouldn't mind if "soft" were the default, but I really need "hard" as a choice.

User avatar
pythoncoder
Posts: 3496
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Micropython R1.9 changes

Post by pythoncoder » Sun May 28, 2017 2:02 pm

jcea wrote:..."on" or "off" depends of the external electronic components...
I must admit I was surprised. There has been lengthy debate on GitHub on Pin and Signal method names. The solution of pins being "high" or "low" and signals being "on" or "off" was suggested early on and seems in accordance with reality.
jcea wrote:...Another thing I don't like is that now "Timer" is a soft interrupt...
That one had passed me by, but I think you are correct. I believe the pyb module still gives hard IRQ's only: the change affects machine. It looks like the intention is to make it user configurable, but this hasn't yet been implemented.

It would be interesting to quantify the difference in latency between "hard" and "soft" on the ESP series. On the Pyboard I'd expect a big difference as hard IRQ's are precisely that: they pre-empt everything barring higher priority hard interrupts. The key point is that they pre-empt GC which (a) leads to the allocation restrictions and (b) avoids the GC latency which can be a few ms.

On the ESP8266 the "hard" interrupt latency is truly abysmal - I've measured figures in the high hundreds of microseconds and that's with nothing happening on the WiFi stack. A true worst-case could be over 1ms. A "hard" IRQ may be little better than a "soft" one if you keep GC overhead down by periodically invoking it in code. Actual measurements would be interesting. It pays to be wary of code which relies on timing accuracy.
Peter Hinch

User avatar
deshipu
Posts: 1347
Joined: Thu May 28, 2015 5:54 pm

Re: micropython R1.9 ETA @@ released @@

Post by deshipu » Mon May 29, 2017 5:48 am

This version breaks pretty much all SPI device drivers, including all TFT display drivers. And we can't simply update the drivers, as they would then stop working with the other versions. Good job.

User avatar
pythoncoder
Posts: 3496
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

SPI problems?

Post by pythoncoder » Mon May 29, 2017 6:18 am

@deshipu This version breaks pretty much all SPI device drivers, including all TFT display drivers...
Could you elucidate what exactly is broken? I've looked at the official drivers drivers/nrf24l01.py and drivers/display/lcd160cr.py - neither of them have recent changes to their SPI handling. I've built today's source: the lcd160cr works perfectly with its own test program and with my own code.
Peter Hinch

Post Reply