MicroPython Forum (Archive)

I can't see the 'threading' branch in the main repo, and I it doesn't seem to be
merged into master. Where can I find it now?

The lower level _thread library is supported on the WiPy, but as far as I can see hasn't yet made it to the Pyboard.

Hi guys!

Any news on this? I'm waiting for it to come to the pyboard, as I just spent weeks debugging problems which would not have occurred if I had working threads...

Ciao,
Bob

Hi,

I am trying to create a Bridge between UART and Bluetooth with the wipy.
So, another device, call it Device_A, can connect via UART to the wipy and send Data to a Bluetooth HUB and later also to a Server via Wifi.
When Data is send succesfully to the Server, or HUB, a notification should be sent back to Device_A through the bridge(wipy).
I have a first idea of how to do this. I need 4 threads:
1. Read Uart ( Wait for Chars, read in frame, SENT TO BUFFER1/ QUEUE1/..)
2. Process Frame (Wait for Frame in Buffer1/ Queue1..., Process Frame: Send Data via Wifi/BLE.., Write to Buffer2)
3. Bluetooth (Wait for Events, process events.., write to Buffer2)
4. Write UART (Wait for Frames in Buffer2, Write to UART)

The module "uasyncio" would be perfect to use here, but unfortunately I have a Wipy-board.

What would be an alternative here? _threads? This has very limited functionalities..

Since you mention Bluetooth and WiPy, I assum that you use a WiPy2 or WiPy3 from Pycom with an ESP32 processor.
For that device you have to ask as forum.pycom.io.
Besides that, you may use uasyncio in both variants of MicroPython with slight differences.

For the record, Damien presented Threads in MicroPython at our recent MicroPython Meetup. It can be difficult to see Damien's screen but hopefully you can get the gist.

The summary is that he's recently tidied up the _thread implementation on the ESP32 and so threading is now viable on the ESP32 and the PyBoard. The interface is identical between the ports. In particular there were some bugs wrt running multiple threads with PSRAM-enabled ESP32's.

The on-the-spot examples he came up with were pretty compelling! Pretty neat to run a thread in the background while using the REPL. If I need concurrency I'd first reach for an asyncio solution but it's good to have options.

As @nic mentioned, only the _thread module is currently available. The threading module, which adds many more higher-level abstractions, is a pure-python library built on top of the primitives supplied by _thread. For someone sufficiently motivated, it shouldn't be a massive task to start porting CPython's threading source code to MicroPython...

PS I've only just posted that video and haven't yet processed the other videos from the night but when I get around to it I'll add the usual entry to the Melbourne MicroPython Meetup blog.

Roberthh wrote: ↑

Tue Dec 18, 2018 2:02 pm

Since you mention Bluetooth and WiPy, I assum that you use a WiPy2 or WiPy3 from Pycom with an ESP32 processor.
For that device you have to ask as forum.pycom.io.
Besides that, you may use uasyncio in both variants of MicroPython with slight differences.

Thanks, I have created a framework which working well. But, i have a big issue now with asynchronous https Client requests connecting to a web Server and get a token for further processing.
For python, there is the module "aiohttp" which would work perfectly, but unfortunately, the micropython "uaiohttpclient" is very limited. Here, I can do simple requests to http-server, but it seems that i can not get a token from a authentication process or include a payload.

Are there any other modules, which could work on the wipy?`I am using "microRESTCli" at the moment, its simple and great, but it seems that it is not asynchronous due to a blocking socket. If I try to just set the socket to non blocking as described in Peter Hinchs example of Uasyncio, it crashes.
Thanks in advance!

nic wrote: ↑

Sat Jan 19, 2019 8:05 pm

I am using "microRESTCli" at the moment, its simple and great, but it seems that it is not asynchronous due to a blocking socket. If I try to just set the socket to non blocking as described in Peter Hinchs example of Uasyncio, it crashes...

Using nonblocking sockets is rather more involved than taking existing code and setting the socket to nonblocking. My uasyncio tutorial doesn't really go into this. When you read from a nonblocking socket you will usually get nothing. You might get partial data. The read's priority is immediate return so you'll get whatever is available at that moment. You can use the uselect module to help with polling sockets. Writing can also send partial data.

There is a lot of information online. For practical MicroPython examples there is mqtt_as in this repo and micropython-iot.

pythoncoder wrote: ↑

Sun Jan 20, 2019 11:48 am

nic wrote: ↑

Sat Jan 19, 2019 8:05 pm

I am using "microRESTCli" at the moment, its simple and great, but it seems that it is not asynchronous due to a blocking socket. If I try to just set the socket to non blocking as described in Peter Hinchs example of Uasyncio, it crashes...

Using nonblocking sockets is rather more involved than taking existing code and setting the socket to nonblocking. My uasyncio tutorial doesn't really go into this. When you read from a nonblocking socket you will usually get nothing. You might get partial data. The read's priority is immediate return so you'll get whatever is available at that moment. You can use the uselect module to help with polling sockets. Writing can also send partial data.

There is a lot of information online. For practical MicroPython examples there is mqtt_as in this repo and micropython-iot.

Thanks for the advice of MQTT! So, how could I establish a asynchronous connection between the wipy and a webserver? My board would be a client who publishes data to the broker and also subscribe in the event of a reponse from the webserver. How would the broker be able to communciate with the webserver, who provides data for the board?

thanks in advance!

You need a Python MQTT client which communicates with the broker. It would subscribe to the topic(s) to which your board published, and it would publish to the topic(s) to which your board subscribed. This Python client would talk to the webserver.

If your webserver is written in Python and you have access to the source you could adapt it to also perform the role of MQTT client.

I suggest you look at paho-mqtt for a CPython MQTT library.