Simple MicroPython Game Is A 30 Minute Game Dev Course

May 25, 2021 by Donald Papp 7 Comments

Sometimes, it’s really useful to watch a project’s parts come together one piece at a time in order to get a complete understanding and mental picture of the whole, and we found that to be the case with this simple, retro-inspired sample game from [ezContents]. (Video, embedded below.) The code is on GitHub but if you’re at all interested in what goes on behind the scenes in a game like that, don’t miss the video.

In the video, each game element and function is illustrated, showing exactly what gets done and why. This part is collision detection (click to enlarge.)

These sprite-based games are mostly about moving a small graphical object (a sprite) around a screen in response to user input, and managing what happens when collisions are detected between the player’s sprite and other sprites like enemies, projectiles, and so forth. The development process is wonderfully documented and demonstrated in a video, as each separate part of functionality gets built and explained one piece at a time.

The simple game is made using ArduPy (which is MicroPython combined with Arduino APIs) using Seeed Studios’ Wio Terminal, a small microcontroller development board with integrated screen, sensors, and button inputs including a little directional clicker that [ezContents] uses as a joystick.

The video of the whole process is embedded below; give it a watch and you’ll maybe come away with inspiration, but you’ll definitely have a much better understanding of how these types of games are developed, even if you’re not using the same hardware or development environment.

Continue reading “Simple MicroPython Game Is A 30 Minute Game Dev Course” →

Simple GUI Menus In Micropython

May 11, 2021 by Chris Lott 7 Comments

Love ’em or hate ’em, sometimes your embedded project needs a menu system. Rather than reimplement things each and every time, [sgall17a] put together a simple GUI menu system in Micropython that can be reused in all sorts of projects. The approach uses tables to define the menus and actions, and the demo program comes with a pretty good assortment of examples. Getting up to speed using this module should be fairly easy.

The hardware that [sgall17a] chose to demonstrate the concept couldn’t have been much smaller — it’s a Raspberry Pi Pico development board, an OLED 128 x 64 pixel display, and a rotary encoder with built-in push-button switch (it’s also been tested on ESP32 and ESP8266 boards). The widget under control is one of the commonly available Neopixel development boards. The program is hosted on GitHub, but beware that it’s under development so there may be frequent updates.

This is a good approach to making menus, but is often rejected or not even considered because of the overhead cost of developing the infrastructure. Well, [sgall17a] has done the hard work already — if you have an embedded project requiring local user setup, check out this module.

Looks Like A Pi Zero, Is Actually An ESP32 Development Board

April 30, 2021 by Donald Papp 34 Comments

ATMegaZero ESP32- S2, showing optional color-coded 40-pin header (top)

The ATMegaZero ESP32-S2 is currently being funded with a campaign on GroupGets, and it’s a microcontroller board modeled after the Raspberry Pi Zero’s form factor. That means instead of the embedded Linux system most of us know and love, it’s an ESP32-based development board with the same shape and 40-pin GPIO header as the Pi Zero. As a bonus, it has some neat features like a connector for inexpensive SSD1306 and SH1106-based OLED displays.

Being able to use existing accessories can go a long way towards easing a project’s creation, and leveraging that is one of the reasons for sharing the Pi Zero form factor. Ease of use is also one of the goals, so the boards will ship with CircuitPython (derived from MicroPython), and can also be used with the Arduino IDE.

If a microcontroller board using the Pi Zero form factor looks a bit familiar, you might be remembering the original ATMegaZero which was based on the Atmel ATMega32U4, but to get wireless communications one needed to attach a separate ESP8266 module. This newer board keeps the ATMegaZero name and footprint, but now uses the Espressif ESP32-S2 to provide all the necessary functions.

CircuitPython has been a feature in a wide variety of projects and hacks we’ve seen here at Hackaday, and it’s a fine way to make a microcontroller board easy to use right out of the box.

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