Wireless MicroPython Programming with Thonny

-

I’ve been playing with a few MicroPython projects recently on several different embedded platforms, including a couple of ESP32 WiFi modules. There are various ways to program these modules:

  • Use a serial terminal and ampy (maintained by [devxpy] since being dropped by Adafruit in 2018).
  • If you use Pycom boards or WiFy firmware, there are the pymakr plugins for Atom and Visual Studio.
  • If you prefer the command-line like me, there is rshell by one of the top MicroPython contributors [Dave Hylands].

For over a year, I have been quite happy with rshell until I started working on these wireless nodes. Being lazy, I want to tinker with my ESP32 modules from the sofa, not drag my laptop into the kitchen or balcony to plug up a USB cable. Can’t I work with them wirelessly?

Well, you can use WebREPL. While its functional, it just didn’t strike my fancy for some reason. [Elliot] mentioned in a recent podcast that he’s using telnet to access his wireless nodes, but he’s using esp-link on an ESP8266, which means throwing another chip into the mix.

The Thonny IDE

I had all but given up when by chance I saw this video on the Dronebot Workshop channel about running MicroPython on the new Raspberry Pi Pico boards. Bill was using Thonny, a Python IDE that is popular in the education community. Thonny was introduced in 2015 by Aivar Annamaa of the University of Tartu in Estonia. Thonny was designed to address common issues observed during six years of teaching Python programming classes to beginners. If you read about the project and its development, you’ll see that he’s put a lot of effort into making Thonny, and it shows.

Leaning about Thonny got me curious, and after a little digging I discovered that it has WebREPL support for MicroPython right out-of-the-box. Although this is a new feature and classified as experimental, I found it reasonably stable to use and more than adequate for home lab use.

Installation and Connection

Instructions are clearly given on the project’s website. There is a downloader link at the top of the page for Windows. For Linux and Mac simply doing sudo apt install thonny or brew install thonny was all I needed. If you have a Raspberry Pi, you will find Thonny is pre-installed — version 3.3.3 was found on a recent Pi 4 in my lab. On an older Pi 3 however, Thonny was too old and simply reinstalling it didn’t work for me. Doing a sudo apt update, sudo apt upgrade, and then reinstalling Thonny resulted in the latest version 3.3.6.

For some reason, the Thonny found in the Ubuntu 20.04 and Debian Buster package repositories also weren’t recent enough. Rather than building from source, I used the provided Linux installation script that downloads and installs the latest release.

In order to connect to a module, you will use the Run -> Select interpreter... menu. Here you pick which type of module to use, and which interface (USB or WebREPL). Note that you have to connect to your module over USB first and make sure that WebREPL is enabled in boot.py. This is the normal method of enabling WebREPL in general — if your module already has WebREPL setup, you don’t need to change anything. Fill in the WebREPL URL and password — you should connect and be good to go.

Tweaks

Thonny Connection Screen

By default, Thonny’s windows are stacked vertically. If you’re using a modern wide-screen monitor, you will probably want to rearrange the windows in Thonny so the editor and shell are side-by-side (see the feature image). This is done by adding ShellView.location = e to the [view] section of the configuration.ini file (see here). The e means East, and other compass points like se can be specified as well. For the systems I tested, the configuration file can be found in the following places:

  • Raspi, Ubuntu, Debian
    ~/.config/Thonny/configuration.ini
  • Mac
    ~/Library/Thonny/configuration.ini
  • Windows
    C:\Users\\AppData\Roaming\Thonny\configuration.ini

I had no problems using the REPL manually, but I discovered an issue once you start testing self-starting applications with forever loops. If you are not careful, your application’s main loop can prevent you from regaining REPL control. The solution is to make sure your application sleeps for several milliseconds in the main loop. I tested with 100 ms (see here) and was always able to regain control. This shouldn’t be an issue in most home sensor applications, where the module may sleep for tens of minutes between readings.

By default, a Thonny installation doesn’t make itself visible for command line execution. On the computers I tested, you will find the Thonny executable in the following locations:

  • Raspi /usr/bin/thonny
  • Ubuntu, Debian (installed via installer script)
    ~/apps/thonny/bin/thonny
  • Mac
    /Applications/Thonny.app/Contents/MacOS/thonny
  • Windows
    C:\Users\\AppData\Local\Programs\Thonny\thonny.exe

Multiple Modules and Instances

Thonny Modules Selection List

Thonny can support a variety of different modules. But if you want to connect to multiple modules at the same time, you need to run several instances of Thonny simultaneously. By default, only one instance is allowed. In the Tools -> Options -> General menu, untick the Allow only single Thonny instance checkbox.

I noticed one quirk on MacOS, however. For some reason, unchecking that option doesn’t work when launching the app from the GUI. There is a workaround — you can get multiple instances running if you start them from the command line.

One more annoyance — by default, Thonny will use the previous interpreter / connection when starting up. This is reasonable behavior, but causes a hiccup when talking to multiple boards simultaneously. Just ignore the plethora of error messages when Thonny instance #2 tries to connect to an already connected module, and use the menus to connect to the second device. There apparently isn’t any command line argument for a specific connection, but I have an inquiry pending on the GitHub project page.

Tip of the Iceberg

I have only focused on the WebREPL connectivity aspect of Thonny here, a functionality which seems to be uncommon in other MicroPython programming workflows. But this only scratches the surface of Thonny. Under the hood, it has a lot to offer that is hidden when you first open it.

And while I have been using its MicroPython mode of operation, Thonny was designed to aid students who are learning to write and debug “normal” Python programs running on desktop computers. If you frequently work in Python, I would encourage you to have a look at these aspects of the program — an object inspector, debugger, single-stepping, and a whole slew of other useful tools.

Thonny is also a multi-platform tool. While preparing this article, I tested it on MacOS, Windows 10, Debian, Ubuntu, and Raspberry Pi computers with no problems. The project is open-sourced under the MIT License.

At the very least, Thonny is a great solution for remote MicroPython programming of WiFi embedded modules. Check it out and give it a test run, especially if you’re lazy like me.



from Blog – Hackaday https://ift.tt/3eE3d4J

Comments

Post a Comment

Popular posts from this blog

Modern Radio Receiver Architecture: From Regenerative to Direct Conversion

-
Image
Modern radio receivers have a distinct advantage over the common early designs which I covered in my previous article . Most of the receivers you will have worked with over the past couple decades are designs by Edwin Armstrong ; regenerative, superregenerative, or most commonly superheterodyne. These are distinguished by a few fascinating key traits that bring both benefits and drawbacks. Today let’s dive into Mr. Armstrong’s receivers. I’ll also talk about DC receivers which, despite the name, are not made to listen to batteries. These are receivers you are much more likely to encounter in modern equipment. Regenerative and Superregenerative The regenerative receiver is all about doing more with less. You still see some of these in simple applications like RF remote controls. The idea derives from how an oscillator works. In a simple way of thinking, an oscillator is an amplifier with enough positive feedback that any tiny signal at the right frequency will amplify and then, throu...
Get this one»

Hackaday Links: May 31, 2020

-
We begin with sad news indeed as we mark the passing of Marcel van Kervinck on Monday. The name might not ring a bell, but his project, the Gigatron TTL computer , certainly will. We did a deep dive on the microprocessor-less computer a while back, and Marcel was a regular at conferences and on the Gigatron forums, supporting users and extending what the computer can do. He was pretty candid about his health issues, and I’ll add that when I approached him a few weeks ago out of the blue about perhaps doing a Hack Chat about Gigatron, he was brutally honest about how little time he had left and that he wouldn’t make it that long. I was blown away by the grace and courage he displayed. His co-conspirator Walter Belger will carry on the Gigatron mission, including joining us for a Hack Chat on June 24. In the meantime, this might be a great time to pick up a Gigatron kit before they’re all sold out and get busy soldering all those delicious through-hole TTL chips. May of 2020 is the mo...
Get this one»

Homebrew 68K Micro-ATX Computer Runs Its Own OS

-
Image
We’re no stranger to home built Motorola 68000 computers here at Hackaday, but more often than not, they tend to be an experiment in retro minimalism. The venerable processor is usually joined by only a handful of components, and there’s an excellent chance they’ll have taken up residence on a piece of perfboard. Then [NotArtyom] sent in his Blitz , and launched the bar into the stratosphere. Make no mistake, the Blitz isn’t just some simple demo of classic chips. The open hardware motherboard has onboard floppy, IDE, and PS/2 interfaces, with a trio of 8-bit ISA expansion slots for good measure. The  Motorola 68030 CPU is humming along at 50 MHz, with 4 MB of RAM and 512 KB of ROM along for the ride. Designed to fit the Micro-ATX motherboard standard, you can even mount the Blitz in a contemporary PC case and run it on a standard ATX power supply. An earlier prototype of the Blitz motherboard. As if the hardware wasn’t impressive enough, [NotArtyom] went ahead and created hi...
Get this one»