MicroPython Forum (Archive)

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 ?

"Soon"

Hopefully within the week.

Sent from my GT-I9105P using Tapatalk

OOooh 1.9 is released:

https://github.com/micropython/micropyt ... s/tag/v1.9


http://micropython.org/resources/firmwa ... 6-v1.9.bin

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.

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)"

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.

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.

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.

@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.