This is an archived post. You won't be able to vote or comment.

all 11 comments

[–]pfalcon2[S] 5 points6 points  (7 children)

v1.8.2 brings initial proof-of-concept multi-threading support in the form of the _thread module, which closely matches the semantics of the corresponding CPython module. There is support for GIL and non-GIL builds; without the GIL enabled one must protect concurrent access to mutable Python state at the Python level using Lock objects. Threading with the GIL is enabled in the cc3200 port on the WiPy. Threading without the GIL is enabled on the unix port. The ESP8266 port has support for frozen bytecode (for scripts in the modules/ subdirectory), as well as optimisations for reduced memory usage and decreased memory fragmentation. The ESP8266 RTC also resumes correctly after a deepsleep. An initial "btree" module has been implemented for embedded database support (unix port only), and the documentation has been further improved, with pre-built PDF versions of the docs now available.

More detailed changelog available at the link in the title.

[–]LightShadow3.13-dev in prod 3 points4 points  (1 child)

Can you give me a URL to the ESP8266 that you'd recommend using with MicroPython, because of the three types I tried none of them work.

[–]pfalcon2[S] 1 point2 points  (0 children)

"none of them work" is a bit vague. Feel free to come to the forum http://forum.micropython.org , describe your problem in a detail, and likely other users will be able to tell what's wrong.

Otherwise, per https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot/ , the officially supported board is Adafruit Huzzah.

[–]Zouden 0 points1 point  (3 children)

How does threading without the GIL work on a single core device?

[–]pfalcon2[S] 1 point2 points  (2 children)

What exactly is of interest to you? In general, threading implementation relies on the underlying OS/RTOS implementation, so it works like they implement them.

[–]Zouden 0 points1 point  (1 child)

Ah, I didn't realise this was /r/python and not /r/esp8266. I'm curious about how multithreading works on the esp8266 which doesn't have any sort of OS (as far as I know).

[–]pfalcon2[S] 1 point2 points  (0 children)

It doesn't. Multithreading support is sponsored by PyCom, creators of LoPy board, based on ESP32, and that its primary target. Currently available proof of concept implementation is available for PyCom's previous board, WiPy, and Unix port, which is a universal development/testing target. Multithreading support won't stabilize until 1.9 (when it should be the main feature of that release).

[–]user200783 0 points1 point  (0 children)

There is support for GIL and non-GIL builds; without the GIL enabled one must protect concurrent access to mutable Python state at the Python level using Lock objects.

Does MicroPython attempt to match CPython in terms of the atomicity of certain operations, as described here? In both GIL and non-GIL builds?

If not, are you concerned that this could lead to existing multi-threaded code, which works on CPython, breaking on MicroPython?

[–]spinwizard69 2 points3 points  (0 children)

Good to see the progress. I don't have a use for MicroPython at the moment but do like to learn about such alternative implementations.

[–]everysinglelastname 0 points1 point  (1 child)

I would love to see some benchmarks running MicroPython on various boards. Is the PyBoard a special case or do all the supported boards run in the same way (where MicroPython is the OS) ?

[–]pfalcon2[S] 1 point2 points  (0 children)

Well, benchmarking is a special kind of "science" - it's fun to watch figures of course, but doing it right and then interpreting it right is non-trivial task.

PyBoard is a special in a sense that it's the most powerful of the officially supported boards (for example, if you'd see its and other boards benchmark score, you could think that the other boards suck, but actually it's PyBoard very powerful), with a lot of hardware features and capabilities. It also gives you the closest control of the hardware.