Build An Easy Replica Of HAL 9000

Adafruit’s PropMaker Feather is a microcontroller board designed specifically for building props with electronic features. Thus, what better way to show it off than by building a nifty replica of the most menacing AI ever to roam this solar system? That’s right, it’s the Adafruit HAL9000 build!

Following the 80/20 rule, this version is intended to be reasonably authentic while remaining affordable and easy to build. It’s built around Adafruit’s existing Massive Red Arcade Button, which looks like a decent simulacra of HAL9000’s foreboding, perceptive lens. It’s placed in a case assembled from laser-cut acrylic, with a neat inkjet-printed label on top. Where previously, sound effects were courtesy of an Arduino Uno with a Wave Shield, this version uses the PropMaker Feather, based on the RP2040, instead. It’s actually possible to assemble with zero soldering thanks to quick-connect wires and screw terminals on the PropMaker Feather.

Fundamentally, if you’re building a simple prop that needs audio or LEDs, the PropMaker Feather could be a useful tool for the job. Alternatively, consider building a HAL replica with more capability, like controlling your home. Just don’t give it too much responsibility—we all know how that ends. Video after the break.

Continue reading “Build An Easy Replica Of HAL 9000”

HAL 9000 Becomes A Helpful Voice Assistant

There have been many robots and AIs in science fiction over the years, from Astro Boy to Cortana, or even Virgil for fans of the long-forgotten Crash Zone. However, all these pale into insignificance in front of the cold, uncaring persona of the HAL 9000. Thus, [Jürgen Pabel] thought the imposing AI would make the perfect home assistant.

The build is based on a Raspberry Pi Zero 2, which boasts more grunt than the original Pi Zero while still retaining good battery life and a compact form factor. It’s hooked up with a 1.28″ round TFT display which acts as the creepy glowing eye through which HAL is supposed to perceive the world. There’s naturally a speaker on board to deliver HAL’s haunting monotone, and it’s all wrapped up in an tidy case that really looks the part. It runs on the open-source voice assistant Kalliope to help out with tasks around the home.

[Jürgen]’s page shares all the details you need to make your own, from the enclosure construction to the code that laces everything together. It’s not the first HAL 9000 we’ve seen around these parts, either. Video after the break.

Continue reading “HAL 9000 Becomes A Helpful Voice Assistant”

2022 Sci-Fi Contest: Your Home Assistant, HAL 9000

Anyone who has seen 2001: A Space Odyssey will easily remember HAL 9000, the sentient computer that turned against its human companions aboard Spacecraft Discovery One. [Ben Brooks] decided to recreate the foreboding digital being, and put it to work as a smart home assistant.

The build consists of a 3D printed assembly that looks very much like HAL did in the movie. It runs as a standalone device hooked up to [Ben]’s Home Assistant instance, a self-hosted home automation solution. The device is capable of playing sound clips from the movie, with the help of an ESP8266 and a DF Player Mini module. It’s triggered by a button or motion sensor, but it’s also hooked up to Home Assistant for some extra smarts. This setup makes sure HAL stays silent when a Chromecast is playing content on TV, so as not to disturb essential viewing.

Overall, it’s a fun movie tribute build that is remarkably true to the source material. Let’s just hope this HAL doesn’t get any maniacal ideas, forcing [Ben] to pull apart its processor to stop its dangerous machinations.

We’ve seen some other great HAL builds before, too. Video after the break.

Continue reading “2022 Sci-Fi Contest: Your Home Assistant, HAL 9000”

Servo Larson scanner

No LEDs Required For This Servo-Controlled Larson Scanner

All things considered, it’s pretty easy to get one LED is a strip to light up sequentially, and have it bounce back and forth. Turning that simple animation into a real Larson scanner, with smooth transitions and controlled fade-out, is another thing entirely. And forgetting the LEDs altogether and making a servo-operated Larson scanner is — well, let’s just call it an interesting lesson in hardware abstraction.

The Larson scanner, named after famed TV producer Glen A. Larson for his penchant for incorporating it into shows like Battlestar Galactica and Knight Rider, is actually hard to execute in hardware thanks to the fading tail that follows the lead pixel as it dances back and forth across the display. [Eric Gunnerson] decided to make this and other animation effects easier to achieve with Fade, a custom framework for LED animations that runs on an ESP32.

LED animations are fine, but what about servos? Could Fade be modified to support them? This turned out to be a fairly easy mod thanks to Fade’s architecture and [Eric]’s existing support for non-addressable LEDs via PWM signals. And it was even possible to support more than the 16 PWM channels on an ESP32by adding a UDP connection that puts multiple ESP32s under the control of a central microcontroller.

The video below shows [Eric]’s demo of servo support, with an eight-channel electromechanical Larson scanner. Each “pixel” is a painted ping pong ball swinging back and forth on a hobby servo, and the whole thing sounds just about as awful as you’d expect it to. If you squint just right, the effect looks pretty convincing, but that’s hardly the point. The real story here is [Eric]’s thoughtful architecture, which made the mods easier than starting from scratch.

Continue reading “No LEDs Required For This Servo-Controlled Larson Scanner”

Another Neat General Purpose Soldering Iron Driver

Over on Hackaday.io, user [Tomasz Jastrzebski] has designed a tidy-looking custom controller for driving temperature-controlled soldering irons. The design is intended to be general purpose, capable of operating with irons rated for different voltages and probe type, be they thermocouple- or thermistor-based. Rather than integrating a power supply, this is handled by an external unit, giving the possibility of feeding this from a variety of sources that are not necessarily tied to the grid.

Hardware-wise, we’ve got the ubiquitous STM32 microcontroller in charge of the show, with a nice front end based on the INA823 instrumentation amplifier, referenced to a REF2030 precision voltage source. The input stage is configured as a versatile Wheatstone bridge input circuit, giving plenty of scope for tweaking.

There are a few extra features in the design that aren’t necessarily needed for a soldering iron driver, such as RTC support, complete with supercapacitor backup, but then this doesn’t have to drive a soldering iron, it could drive any DC heater with temperature feedback. With a change in firmware, this could serve other tasks. One potential feature that springs to mind — have the unit automatically power down at a certain time of day in case it was left on accidentally.

The schematic has a lot of relevant detail — in that many parts have a good list of alternatives, presumably because of the semiconductor shortages — which is a good habit to get into if you ask us. Many of us involved with manufacturing have been doing this for years, as it makes sense to give the assembly house the extra options, but this really is basically mandatory practice now.

Firmware for the STM32G0 series microcontroller is based on the STM32 HAL, keeping it simple, with a Visual Studio Code project provided for your convenience. All hardware (KiCAD) and firmware can be found on the project GitHub.

We’ve seen a few projects like this over the years, like this Really Universal Soldering Controller, a custom controller for JBC irons, and this great portable Arduino-based unit.

Write Once, Run Everywhere: Cross-Platform Programming Done Right

One of the goals of programming languages back in the 1950s was to create a way to write assembly language concepts in an abstract, high-level manner. This would allow the same code to be used across the wildly different system architectures of that era and subsequent decades, requiring only a translator unit (compiler) that would transform the source code into the machine instructions for the target architecture.

Other languages, like BASIC, would use a runtime that provided an even more abstract view of the underlying hardware, yet at the cost of a lot of performance. Although the era of 8-bit home computers is long behind us, the topic of cross-platform development is still highly relevant today, whether one talks about desktop, embedded or server development. Or all of them at the same time.

Let’s take a look at the cross-platform landscape today, shall we?

Continue reading “Write Once, Run Everywhere: Cross-Platform Programming Done Right”

The Case For Arduino In “Real Engineering”

For over ten years, Arduino has held onto its popularity as “that small dev-board aimed to get both artists and electronics enthusiasts excited about physical computing.” Along the way, it’s found a corner in college courses, one-off burning man rigs, and countless projects that have landed here. Without a doubt, the Arduino has a cushy home among hobbyists, but it also lives elsewhere. Arduino lives in engineering design labs as consumer products move from feature iterations into user testing. It’s in the chem labs when scientists need to get some sensor data into their pc in a pinch. Despite the frowns we’ll see when someone blinks an LED with an Arduino and puts it into a project box, Arduino is here to stay. I thought I’d dig a little bit deeper into why both artists and engineers keep revisiting this board so much.

Arduino, do we actually love to hate it?

do-we-love-arduinoIt’s not unusual for the seasoned engineers to cast some glares towards the latest Arduino-based cat-feeding Kickstarter, shamelessly hiding the actual Arduino board inside that 3D-printed enclosure. Hasty? Sure. Crude, or unpolished? Certainly. Worth selling? Well, that depends on the standards of the consumer. Nevertheless, those exact same critical engineers might also be kicking around ideas for their next Burning Man Persistence-of-Vision LED display–and guess what? It’s got an Arduino for brains! What may seem like hypocrisy is actually perfectly reasonable. In both cases, each designer is using Arduino for what it does best: abstracting away the gritty details so that designs can happen quickly. How? The magic (or not) of hardware abstraction.

Meet HAL, the Hardware-Abstraction Layer

In a world where “we just want to get things blinking,” Arduino has a few nifty out-of-the-box features that get us up-and-running quickly. Sure, development tools are cross-platform. Sure, programming happens over a convenient usb interface. None of these features, however, can rival Arduino’s greatest strength, the Hardware Abstraction Layer (HAL).

HAL is nothing new in the embedded world, but simply having one can make a world of difference, one that can enable both the artist and the embedded engineer to achieve the same end goal of both quickly and programmatically interacting with the physical world through a microcontroller. In Arduino, the HAL is nothing more than the collection of classes and function calls that overlay on top of the C++ programming language and, in a sense, “turn it into the Arduino programming language” (I know, there is no Arduino Language). If you’re curious as to how these functions are implemented, take a peek at the AVR directory in Arduino’s source code.

With a hardware abstraction layer, we don’t need to know the details about how our program’s function calls translate to various peripherals available on the Uno’s ATMEGA328p chip. We don’t need to know how data was received when Serial.available() is true. We don’t “need to know” if Wire.begin() is using 7-bit addressing or 10-bit addressing for slave devices. The copious amounts of setup needed to make these high-level calls possible is already taken care of for us through the HAL. The result? We save time reading the chip’s datasheet, writing helper functions to enable chip features, and learning about unique characteristics and quirks of our microcontroller if we’re just trying to perform some simple interaction with the physical world.

Cross-Platform Compatibility

Teensy 3.2 keeps form factor but adds hardware features
Teensy 3.2 keeps form factor but adds on-chip hardware features compared to 3.1

There are some cases where the HAL starts to break down. Maybe the microcontroller doesn’t have the necessary hardware to simultaneously drive 16 servos while polling a serial port and decoding serial data. In some cases, we can solve this issue by switching Arduino platforms. Maybe we actually do need three serial ports instead of one (Teensy 3.2). Maybe we do need pulse-width-modulation (PWM) capability on every pin (Due). Because of the hardware abstraction layer, the rest of the source code can remain mostly unchanged although we may be switching chip architectures and even compilers in the process! Of course, in an environment where developing code for the target platform does matter, it doesn’t make sense to go to such efforts to write the general-purpose code that we see in Arduino, or even use Arduino in the first place if it doesn’t have the necessary features needed for the target end-goal. Nevertheless, for producing an end-to-end solution where “the outcome matters but the road to getting there does not,” writing Arduino code saves time if the target hardware needs to change before getting to that end goal.

HAL’s drawbacks

arduino-serial-buffer-sizeOf course, there’s also a price to pay for such nice things like speedy development-time using the HAL, and sometimes switching platforms won’t fix the problem. First off, reading the Arduino programming language documentation doesn’t tell us anything about the limitations of the hardware it’s running on. What happens, let’s say, if the Serial data keeps arriving but we don’t read it with Serial.read() until hundreds of bytes have been sent across? What happens if we do need to talk to an I2C device that mandates 10-bit addressing? Without reading the original source code, we don’t know the answers to these questions. Second, if we choose to use the functions given to us through the HAL, we’re limited by their implementation, that is, of course, unless we want to change the source code of the core libraries. It turns out that the Serial class implements a 64-byte ring buffer to hold onto the most recently received serial data. Is 64 bytes big enough for our application? Unless we change the core library source code, we’ll have to use their implementation.

Both of the limitations above involve understanding how the original HAL works and than changing it by changing the Arduino core library source code. Despite that freedom, most people don’t customize it! This odd fact is a testament to how well the core libraries were written to suit the needs of their target audience (artists) and, hence, Arduino garnered a large audience of users.

Pros of Bare-Metalspeak

digitalWrite takes a whopping 52-55 cycles to change pin direction! [image source]
digitalWrite takes a whopping 52-55 cycles to change pin direction! [image source]
Are there benefits to invoking the hardware directly? Absolutely. A few curious inquirers before us have measured the max pin-toggling frequency with digitalWrite to be on the order of ~100 KHz while manipulating the hardware directly results in a pin-toggling frequency of about 2 MHz, about 20 times faster. That said, is invoking the hardware directly worth it? Depends, but in many cases where tight timing isn’t a big deal and where the goal of a functional end-to-end system matters more than “how we got there,” then probably not! Of course, there are cases when tight timing does matter and an Arduino won’t make the cut, but in that case, it’s a job for the embedded engineer.

Use the HAL, Luke!

To achieve an end-to-end solution where the process of “how we got there” matters not, Arduino shines for many simple scenarios. Keep in mind that while the HAL keeps us from knowing too many details about our microcontroller that we’d otherwise find in the datasheet, I don’t proclaim that everyone throw out their datasheets from here on out. I am, however, a proponent of “knowing no more than you need to know to get the job done well.” If I’m trying to log some sensor data to a PC, and I discover I’ll be saving a few days reading a datasheet and configuring an SPI port because someone already wrote SPI.begin(), I’ll take an Arduino, please.

If you’ve rolled up your sleeves and pulled out an Arduino as your first option at work, we’d love to hear what uses you’ve come up with beyond the occasional side-project. Let us know in the comments below.