Wireless MicroPython Programming With Thonny

April 29, 2021 by Chris Lott 11 Comments

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. Continue reading “Wireless MicroPython Programming With Thonny” →

Bridging The PC And Embedded Worlds With Pico And Python

April 18, 2021 by Stephen Ogier 17 Comments

Although protocols like I2C and SPI are great for communicating between embedded devices and their peripherals, it can be a pain to interface these low-level digital interfaces to a PC. [Alexandre] typically used an Arduino to bridge between the PC and embedded worlds, but he got tired of defining a custom serial protocol for each project. Inspired by MicroPython’s machine module, [Alexandre] has developed u2if—an implementation of some of MicroPython’s machine module for PC—using a USB-connected Raspberry Pi Pico to bridge between a PC and low-level digital interfaces.

u2if consists of two parts: the PC portion is a Python implementation of a portion of the MicroPython machine module, and the Raspberry Pi Pico receives some custom C++ firmware. Thus far, [Alexandre] has implemented functionality for the onboard ADCs, I2C, SPI, UART, and GPIO lines as well as additional support for I2S sound and the WS2812B addressable LED.

In addition to the u2if package, [Alexandre] has designed a PCB to break out all of the Raspberry Pi Pico’s interfaces in a handy 3×3.9″ board. We especially like that multiple headers are supplied for I2C, including one with enough space to mount an SSD1306 OLED display.

We think this could be an incredibly useful tool, and what makes it even more impressive is that it uses a board many of us already have laying around. If you want a dedicated device for interfacing with low-level digital buses, you may want to check out the GreatFET.

Cycling Cadence Display With ESP32

March 2, 2021 by Danie Conradie 9 Comments

Terry Pratchett once said “Wisdom comes from experience. Experience is often a result of lack of wisdom.” This is as true with technical skills as it is with the rest of life, and you won’t truly understand a specific topic unless you’ve struggled with it a bit. [publidave] wanted a simple wireless display for a bluetooth cycling cadence sensor, and soon found himself deep down the rabbit hole of Micropython and Bluetooth Low Energy on the ESP32.

[publidave] had converted his bicycle for indoor training during lockdown and winter, and realized he can’t use the guided training app and view his cadence simultaneously, so he needed a dedicated cadence display. Since [publidave] was comfortable with Python, he decided to give Micropython on the ESP32 ago. Bluetooth Low Energy can be rather confusing if you haven’t implemented it before, especially if good examples are hard to come by. In short, the ESP32 needs to find the sensor, connect to it, select the right service, and listen for the notifications containing the data. The data is then converted to RPM and displayed on a small OLED display. [publidave] does an excellent job of describing what exactly he did, highlighting the problems he encountered, and how he solved them.

In the end, he had a functional display, a good idea of what he would do differently next time, and a lot of additional knowledge and understanding. In our book that’s a successful project.

Since so much of the health related devices work with Bluetooth Low Energy, it could be handy to know the technology and how to interface with it. It would allow you to do things like unbrick a $2000 exercise bike,

It Ain’t Broke, But Should I Fix It?

February 20, 2021 by Elliot Williams 76 Comments

Five years ago, I wrote a series on getting started with your own MQTT-based home information/automation network. Five years is a long while in Hackaday time. Back then, the ESP8266 was a lot newer, and the 8266 Arduino port wasn’t fully in shape yet, and the easiest software framework to get MQTT up and running was NodeMCU; so that’s what I used for the article series, and as a consequence a handful of devices around my house run minor modifications of that basic “hello world”, but doing useful stuff.

Since then, NodeMCU has changed a bunch of its libraries and the ESP32 has replaced the ESP8266 in my parts drawer. If you tried to run my code, you’d find that it won’t run on an ESP8266 without porting or compiling an old version of NodeMCU for yourself anyway, and it won’t run on an ESP32 at all. When [Chris Lott] tried to follow my guide, he discovered that Micropython is probably a better language choice in 2021. To minimize lines of code, I’d agree, although the Arduino and Espressif’s own native IDF have grown into the job just about as well. In short, anything but NodeMCU.

Built in an hour, survived for five years.

But my home automation system doesn’t care. Those little guys are running 24/7, flipping bits like it was still 2016. Thermometers, light sensors, and power meters haven’t changed much in five years, and although I’ve revamped the databasing, display, and user control a number of times since then, using a fixed communication transport protocol means that they’re still talking the same language. Indeed, even if NodeMCU is dead to me, the MQTT content of my original series is all still valid, and installing a broker on a Raspberry Pi has only become easier in the intervening five years.

So I’ve got a bunch of legacy code running within the walls of my own home, and it makes me nervous. If the devices fail, or maybe when they eventually fail, it’s not going to be “just flash another ESP8266 and replace it”, because even though I have some ancient NodeMCU binaries sitting around, I know when to throw in the towel. But there’s no good reason to pull them down and start reflashing either. Except that it makes me a little bit itchy, just knowing that there’s orphaned, dead-end code running all around me. Surrounding me. Staring deep into my hacker’s heart.

I know better than to tear down a running system, even though I could do it one device at a time, and each module would surely be a simple, independent fix; even though I’d love the excuse to play around with Micropython and its MQTT implementation on the ESP8266, or maybe even swap some of them out for ESP32s; even though these were all temporary quick hacks that have somehow served for five (5!) years. I certainly know better, right? (Right?)

Minimal MQTT With Micropython

February 17, 2021 by Chris Lott 16 Comments

I have been meaning to play around with MQTT for some time now, and finally decided to take the plunge one evening last week. I had three cheap home temperature and humidity sensors, and was bothered that they often didn’t agree. Surprisingly, while the analog one had a calibration adjustment in the back, I have no idea how to calibrate the two digital ones. I took this as a sign that it was time to learn MQTT and be able to install my own, accurate sensors. Of course, I began by ordering the cheapest sensors I could find, but I can always upgrade later on.

While we have written quite a bit about MQTT in Hackaday, I had to go all the way back to 2016 to find this introductory four-part series by Elliot Williams. Five years is a long time in the tech world, but I decided to give it a try anyway. Continue reading “Minimal MQTT With Micropython” →

The Shell And The Microcontroller

January 9, 2021 by Elliot Williams 104 Comments

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?

Ringing In The Holidays With Self-Playing Chimes

December 24, 2020 by Adam Zeloof 4 Comments

The holiday season is here, and along with it comes Christmas music. Love them or hate them, Yuletide tunes are a simple fact of life each December. This year, [Derek Anderson] put a modern spin on a few classic melodies and listened to them via his set of self-playing chimes.

Inspired by [Derek]’s childhood Ye Merry Minstrel Caroling Christmas Bells (video), these chimes really bring the old-school Christmas decoration into the 21st century. Each chime is struck by a dedicated electromagnetically-actuated mallet, which is in turn controlled by an ESP32 running MicroPython.

The chimes play MIDI files, so you could, of course, play music unrelated to Christmas if you wanted to. And they even feature an OLED screen that displays what song is being played. For added flair, the entire thing is beautifully framed in black walnut, not to mention the custom-wound solenoids.

This project incorporated mechanical and electrical design, woodworking, 3D printing, programming, and song arrangement. It’s a wonder that [Derek] was able to create the entire product in the 40-80 hour time frame he estimated. (Though it looks like he had a bit of help.)

We always love to see projects like this, ones in which several disciplines get rolled together to create a beautiful finished piece.

Continue reading “Ringing In The Holidays With Self-Playing Chimes” →