A Rotary Encoder: How Hard Can It Be?

April 20, 2022 by Al Williams 64 Comments

As you may have noticed, I’ve been working with an STM32 ARM CPU using Mbed. There was a time when Mbed was pretty simple, but a lot has changed since it has morphed into Mbed OS. Unfortunately, that means that a lot of libraries and examples you can find don’t work with the newer system.

I needed a rotary encoder — I pulled a cheap one out of one of those “49 boards for Arduino” kits you see around. Not the finest encoder in the land, I’m sure, but it should do the job. Unfortunately, Mbed OS doesn’t have a driver for an encoder and the first few third-party libraries I found either worked via polling or wouldn’t compile with the latest Mbed. Of course, reading an encoder isn’t a mysterious process. How hard can it be to write the code yourself? How hard, indeed. I thought I’d share my code and the process of how I got there.

There are many ways you can read a rotary encoder. Some are probably better than my method. Also, these cheap mechanical encoders are terrible. If you were trying to do precision work, you should probably be looking at a different technology like an optical encoder. I mention this because it is nearly impossible to read one of these flawlessly.

So my goal was simple: I wanted something interrupt driven. Most of what I found required you to periodically call some function or set up a timer interrupt. Then they built a state machine to track the encoder. That’s fine, but it means you eat up a lot of processor just to check in on the encoder even if it isn’t moving. The STM32 CPU can easily interrupt with a pin changes, so that’s what I wanted.

The Catch

The problem is, of course, that mechanical switches bounce. So you have to filter that bounce either in hardware or software. I really didn’t want to put in any extra hardware more than a capacitor, so the software would have to handle it.

I also didn’t want to use any more interrupts than absolutely necessary. The Mbed system makes it easy to handle interrupts, but there is a bit of latency. Actually, after it was all over, I measured the latency and it isn’t that bad — I’ll talk about that a little later. Regardless, I had decided to try to use only a pair of interrupts.

Continue reading “A Rotary Encoder: How Hard Can It Be?” →

Arm Pumps Up The Volume With Mbed And A Potentiometer

April 19, 2022 by Al Williams 7 Comments

Last time, I told you how to get started with the “Black Pill” STM32F411 board using the Mbed OS. The example program, admittedly, didn’t use many of the features of the OS, unless you count what the USB serial port driver uses behind the scenes. However, this time, we’ll make a practical toy that lets you adjust your PC’s volume level with a pot.

The Black Pill is a good choice for this application since it has analog inputs and can act as a USB keyboard. In fact, the Mbed OS has drivers for all kinds of USB devices. We’ve seen the serial port, but you can also look like a mass storage device or a mouse, for example. Just for practice, we’ll create two threads of execution. One will read the pot and send a message over to the other thread. That thread will communicate with the PC as a USB keyboard. Any computer that understands media keys on a keyboard should work with the device.

Threads

Creating threads is very simple. For many cases, you just define a void function that takes no arguments and use it with a Thread object:

readknobThread.start(vol_thread);

Of course, the function shouldn’t return unless you want the thread to end. As I mentioned in the last post, you can sleep with the ThisThread::sleep_for call. There is also a yield call if you simply want to give up the time slice without sleeping for a specific amount of time.

Continue reading “Arm Pumps Up The Volume With Mbed And A Potentiometer” →

Arming With An OS

April 13, 2022 by Al Williams 28 Comments

We see tons of projects with the infamous “Blue Pill” STM32 boards. They are cheap and plentiful and have a lot of great features, or at least they were before the chip shortage. I recently picked up a “Black Pill”, which is very similar but has an even more powerful processor. For a few bucks, you get an ARM CPU that can run at 100 MHz (but with USB, probably 96 MHz). There’s 512 kB of flash and 128 kB of RAM. There’s a USB type C port, and even a button and an LED onboard. The thing fits on a breadboard and you can program it with a cheap STLink dongle which costs about $10.

Of course, you then have to consider the software. The STM32Cube stuff is a lot to set up and learn but it does let you do just about anything you can imagine. Then there is the STM32Duino plug-in that lets you use it as a beefy Arduino. That works and is easy enough to set up. However, there’s also Mbed. The only problem is that Mbed doesn’t work right out of the box. Turns out, though, it isn’t that hard to set up. I’ll show you how easy it is to get things going and, next time, I’ll show you a practical example of a USB peripheral that uses the mBed RTOS features.

First Steps

Obviously, you are going to need a Black Pill. There are at least two choices but for as cheap as they are there is little reason not to get the STM32F411 version that has more memory. The DIP form factor will fit in whatever breadboard you happen to have and a USB C cable will power the board so unless you are driving a lot of external circuitry, you probably don’t need an external supply.

Continue reading “Arming With An OS” →

A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays

April 4, 2022 by Maya Posch 11 Comments

As a standard feature of the Linux kernel, device tree overlays (DTOs) allow for easy enabling and configuration of features and drivers, such as those contained within the standard firmware of a Raspberry Pi system. Using these DTOs it’s trivial to set up features like as a soft power-off button, triggering an external power supply and enable drivers for everything from an external real-time clock (RTC) to various displays, sensors and audio devices, all without modifying the operating system or using custom scripts.

It’s also possible to add your own DTOs to create a custom overlay that combines multiple DTO commands into a single one, or create a custom device tree binary (DTB) for the target hardware. Essentially this DTB is loaded by the Linux kernel on boot to let it know which devices are connected and their configuration settings, very similar to what the BIOS component with x86-based architectures handles automatically.

Ultimately, the DTB concept and the use of overlays allow for easy configuration of such optional devices and GPIO pin settings, especially when made configurable through a simple text file as on the Raspberry Pi SBC platform.

Continue reading “A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays” →

An M-Core module plugged into its devboard. Around it are Ethernet, HDMI, Type-C, two USB-A ports, one MicroSD card socket and one unpopulated footprint for a WiFi module

MangoPi To Bring A SD-Card-Sized Linux Module

April 1, 2022 by Arya Voronova 14 Comments

Today’s Diminutive Device is a small castellated System-On-Module (Twitter link, nitter proxy) from [MangoPi] called M-Core, with a quad-core A53 CPU and 1 GB of RAM. As such, it’s very capable of running Linux, and even sports an HDMI output! Taking a closer look at the devboard picture, we can spot traces for three USB 2.0 ports, what seems to be two SDIO interfaces for MicroSD or WiFi cards, and an Ethernet MagJack with its termination network. This is a decent set of interfaces, rivaling what we’d expect out of a Pi Zero!

More importantly, this module is as small as an SD card itself – or as an OLED display that we hobbyists sprinkle onto our projects. Having power of Linux in such a small footprint is certainly something to behold! The back of the module is mostly flat, save for a few decoupling capacitors on the other side of the CPU – it seems, an Allwinner H616. On top of it, we can see the CPU itself, a small buck regulator and a DDR3 RAM chip, as well as tightly-packed passives. There’s even an unpopulated footprint for a DFN8 QSPI flash chip – with a lightweight enough OS build, you could perhaps dedicate your MicroSD card to storage only.

The devboard for uses the “FlexyPins”-like connectivity technique we’ve covered recently, and [MangoPi] say they bought those pins on TaoBao. We can’t help but be a bit amused at the thought of putting HDMI through such connections, but it seems to work well enough! Castellated modules like these are relatively easy to work with, so it shouldn’t be hard to literally pop this module out of the devboard and figuratively pop it onto your PCB. Next step is, reportedly, porting Armbian to this board, likely solving quite a few software support hurdles.

MangoPi have been posting updates on their Twitter page over the last few weeks, and, as it comes with the format, a lot of questions are left unanswered. Why does the devboard only show a single linear regulator of the kind we typically expect to deliver 1 A at most? Will we get higher-RAM versions? What’s the price going to look like? Will this module ever get to market? We can only hope, but if it does indeed, we are sure to see a few projects with these, whether it’s smart glasses, smart displays, phones, handhelds or malicious wall chargers. As usual, community makes or breaks an SBC, and we shall watch this one closely.

We thank [WifiCable] and [DjBiohazard] for sharing this with us!

The BGA chip in question flipped onto a piecce of breadboard, all its pins broken out with magnet wire.

Heroic Efforts Give Smallest ARM MCU A Breakout, Open Debugger

March 21, 2022 by Arya Voronova 14 Comments

In today’s episode of Diminutive Device Technology Overview, [Sprite_TM] is at it again – this time conquering the HC32L110. A few weeks ago, we have highlighted the small ARM Cortex M0+ microcontroller, which is outstanding because of its exceptionally small size. We also pointed out a few hurdles, among them – hard-to-approach SDK and documentation, and difficulties making and assembling a PCB for such a small BGA. Today, we witness how [Sprite_TM] bulldozed through all of these hurdles for all of us, and added a few pictures to our collective “outrageous soldering” galleries while at it.

First, he figured out an example layout for this MCU that’s achievable for us even on a cheapest 2-layer board from JLCPCB, keeping distances within the generic tolerance standards by snubbing out a few pins. As a result, we only lose access to four GPIOs – those will have to be kept as inputs, so that nothing burns out. However, that’s the kind of tradeoff we are okay making if it helps us keep our PCB small and lightweight for projects where these factors matter. After receiving the resulting board, he also recorded a short tutorial on soldering such packages at home with a mere hot air gun and a few bare necessities like flux and tweezers – embedded below.

It doesn’t end there, however, as he decided to work around the GPIO fanout limitation in a non-intended way. Evidently, [Sprite_TM] decided to have some fun, taking a piece of regular 0.1″ spacing protoboard and deadbugging the chip with magnet wire, much to our amusement. The resulting contraption, pictured above, worked – and this is ever something you’d like to be able to achieve yourself in times of dire need, whether you make something work or simply to be entertained by making use of a cursed mounting technique, there’s an one-hour-long livestream recording of how this magnet wire contraption came to be. And, of course, that wasn’t the last thing to be shared.

Continue reading “Heroic Efforts Give Smallest ARM MCU A Breakout, Open Debugger” →

An Interview With Reinhard Keil

March 6, 2022 by Chris Lott 3 Comments

Over on the Embedded FM podcast, [Chris] and [Elecia] just released their interview with [Reinhard Keil] of compiler fame. [Reinhard] recounts the story of Keil’s growth and how it eventually became absorbed into Arm back in 2005. Along with his brother Günter, the two founded the company as Keil Software in the Americas, and Keil Elektronik in Europe. They initially made hardware products, but as the company grew, they became dissatisfied with the quality and even existence of professional firmware development tools of the day. Their focus gradually shifted to making a CP/M- and a PC-based development environment, and in 1988, they introduced the first C-compiler designed for the 8051 from the ground up.

Love it or hate it, the Arm Keil suite of µVision IDE and the MDK/Cx51 compiler have been around a long time and used by embedded developers in many industries. Although a free and restricted-use version is available, the license fees prevent most folks from getting very enthusiastic about it. Pricing aside, the µVision IDE has its critics: [Jay Carlson], who used every IDE under the sun a few years ago in his review of sub-one-dollar microcontrollers, opined that it was nothing more than a free editor you get with C51 or MDK-ARM. On the other hand, even [Jay] concedes is that every chip he tested was officially supported by Keil and worked out of the box. Another thing that is important to some users is being able to produce consistent binaries from old projects. This isn’t important for your one-off MQTT hot tub thermometer. But if you need to recompile firmware for a fifteen-year-old railroad signaling system that has multiple certifications and regulatory approvals, using the original compiler and library versions is a huge help.

[Reinhard] goes on to discuss various tools and systems being developed at Arm by his team, such as improvements and additions to the CMSIS suite, the transition of the online Mbed compiler to the new Keil Studio Cloud, and an Arm hardware virtualization tool for cloud-based CI verification. Lest you think everything at Arm is proprietary and expensive, he points out that Arm is a major contributor to the GCC project and the CMSIS components are open source. Even if you aren’t interested in Arm/Keil tools, do check out the interview — it’s quite interesting and touches on several topics of general interest to all firmware developers. Or if you prefer, read the interview when the transcript is completed.