Hardware-in-the-Loop Continuous Integration

November 6, 2024 by Elliot Williams 22 Comments

How can you tell if your software is doing what it’s supposed to? Write some tests and run them every time you change anything. But what if you’re making hardware? [deqing] has your back with the Automatic Hardware Testing rig. And just as you’d expect in the software-only world, you can fire off the system every time you update the firmware in your GitHub.

A Raspberry Pi compiles the firmware in question and flashes the device under test. The cool part is the custom rig that simulates button presses and reads the resulting values out. No actual LEDs are blinked, but the test rig looks for voltages on the appropriate pins, and a test passes when the timing is between 0.95 and 1.05 seconds for the highs and lows. Firing this entire procedure off at every git check-in ensures that all the example code is working.

So far, we can only see how the test rig would work with easily simulated peripherals. If your real application involved speaking to a DAC over I2C, for instance, you’d probably want to integrate that into the test rig, but the principle would be the same.

Are any of you doing this kind of mock-up hardware testing on your projects? Is sounds like it could catch bad mistakes before they got out of the house.

M.2 Makes An Unusual Microcontroller Form Factor

November 3, 2024 by Jenny List 40 Comments

When we think of an m.2 slot in our laptop or similar, it’s usually in the context of its PCI connectivity for high-speed applications such as solid state disks. It’s a connector that offers much more than that interface though, making it suitable for some unexpected add-ons. As an example [MagicWolfi] has produced an m.2 card which contains the equivalent of a Raspberry Pi Pico.

The board itself has the familiar m.2 edge connector at the bottom, and the RP2040 GPIO lines as postage-stamp indentations round the edges. On the m.2 front is uses the USB interface as well as a UART and the I²C lines, as well as some of the interfaces we’re less familiar with such as ALERT, WAKE, DISABLE1/2, LED 1/2, and VENDOR_DEFINED.

On one level this provides a handy internal microcontroller card with which you can do all the things you’d expect from a Pi Pico, but on another it provides the fascinating possibility of the Pico performing a watchdog or other function for the host device. We would be genuinely interested to hear more about the use of the m.2 slot in this way.

If you’d like to know more about m.2, we’ve taken a look at it in more depth.

An SAO For Hams

October 21, 2024 by Al Williams 18 Comments

Generally speaking, the Hackaday Supercon badge will always have a place for SAO (rebranded as “Supercon add-ons”), and that makes sense. We did originate them, after all. This year, though, we’ve gone all in on SAO, and, in particular, we’ve asked to see more SAOs with communication capabilities. The standard has always had an I2C bus, but few people use them. I decided I wanted to set an example and cook up a badge for Supercon. Was it hard? Yes and no. I’ll share with you a little about the board’s genesis and the issues I found. At the end, I’ll make you a special offer, if you are going to Supercon.

The Idea

The front of the SAOGNR — the SAO connector is, of course, on the back

I’ve been a ham radio operator for a very long time. In fact, July was my 47th anniversary in the radio hobby. Well, that’s not true. It was my 47th year with a license. I had been listening to shortwave long before then. So, I wanted to do something with Morse code. You don’t have to know Morse code to get a license these days, but a lot of hams enjoy it.

I set out to do a simple board that would play some Morse code messages. But that’s just another blinking light LED with a buzzer on it, too. So, naturally, I decided it would also provide Morse code output for the I2C host. That is, the SAO could be used to convert ASCII to Morse code. Sounds simple, right? Sure.

Getting Started

I wanted to use a Raspberry Pi Pico but didn’t want to violate the SAO size requirements. Luckily, there’s an RP2040-Zero module that is quite tiny and looks more or less like a normal Pico. The two big differences are plusses: they have a reset button, and instead of a normal LED, they have a WS2812b-style LED.

Continue reading “An SAO For Hams” →

I2C The Hard Way

October 21, 2024 by Al Williams 12 Comments

[Igor] has an AS5600 magnetic rotary encoder chip on a breakout board. Normally, you’d think that was an easy device to work with since it has an I2C interface. But [Igor] wanted to do it the hard way. What’s the hard way? By hand. He directly manipulates the clock and data lines using some push buttons. You can see how it goes in the video below.

This is possible because the controlling device — in this case [Igor] — gets to set the clock rate, and there’s no reason it has to be regular. We have to admit that it never occurred to us to do this, but we have written “bit banged” I2C-like code before.

Continue reading “I2C The Hard Way” →

Clockwork Derby: Digital Robo Rally, Steampunk Style

October 16, 2024 by Heidi Ulrich 7 Comments

Inspired by the classic game Robo Rally, [Ytec3D]’s Clockwork Derby takes tabletop gaming to the next level by combining steampunk aesthetics with automation. We recently had the chance to see it live at Hackfest, together with [Ytec3D]’s animatronic tentacle, and we can say that his new take on playful robotics offers a unique experience for game enthusiasts. The 300×420 mm board uses magnets, motors, and card readers to handle up to eight players, creating a smooth, automated version of Robo Rally where players can focus on strategy while the board handles movement.

In Clockwork Derby, game pieces are moved by a magnetic system controlled by the board, which rotates and shifts pieces in real-time. Each player uses a card reader to program moves, with up to five cards per round. The board scans these cards via barcode scanners, so you don’t have to worry about tracking your moves or adjusting game pieces manually. [Ytec3D]’s game rules have been optimized for the automated setup, allowing for smoother gameplay and an emphasis on strategic choices.

The project is a standout for hackers and tinkerers who appreciate blending physical mechanics with digital precision. It’s a great example of how classic games can be modernized with a bit of ingenuity and tech. For those interested in DIY gaming projects or automation, Clockwork Derby is definitely worth exploring. To dive deeper into the build details and see more of the project, visit [Ytec3D]’s project page for an in-person look at this inventive tabletop game!

Continue reading “Clockwork Derby: Digital Robo Rally, Steampunk Style” →

DIY 3D-Printed Arduino Self-Balancing Cube

October 13, 2024 by Heidi Ulrich 16 Comments

Self-balancing devices present a unique blend of challenge and innovation. That’s how [mircemk]’s project caught our eye. While balancing cubes isn’t a new concept — Hackaday has published several over the years — [mircemk] didn’t fail to impress. This design features a 3D-printed cube that balances using reaction wheels. Utilizing gyroscopic sensors and accelerometers, the device adapts to shifts in weight, enabling it to maintain stability.

At its core, the project employs an Arduino Nano microcontroller and an MPU6050 gyroscope/accelerometer to ensure precise control. Adding nuts and bolts to the reaction wheels increases their weight, enhancing their impact on the cube’s balance. They don’t hold anything. They simply add weight. The construction involves multiple 3D printed components, each requiring several hours to produce, including the reaction wheels and various mount plates. After assembly, users can fine-tune the device via Bluetooth, allowing for a straightforward calibration process to set the balancing points.

If you want to see some earlier incarnations of this sort of thing, we covered other designs in 2010, 2013, and 2016. These always remind us of Stewart platforms, which are almost the same thing turned inside out.

Continue reading “DIY 3D-Printed Arduino Self-Balancing Cube” →

Switch Your RP2040 Between 3.3 V And 1.8 V

September 30, 2024 by Arya Voronova 5 Comments

Ever want to build a RP2040 devboard that has everything you could ever want? Bad news, “everything” also means adding 1.8 V GPIO voltage support. The good news is that this write-up by [xenia] explains the process of adding a “3.3 V/1.8 V” slide switch onto your board.

Some parts are obvious, like the need to pick a flash chip that works at either voltage, for instance. Unfortunately, most of them don’t. But there’s more you’d be surprised by, like the crystal, a block where the recommended passives are tuned for 3.3 V, and you need to re-calculate them when it comes to 1.8 V operation – not great for swapping between voltages with a flick of a switch. Then, you need to adjust the bootloader to detect the voltage supplied — that’s where the fun begins, in large part. Modifying the second stage bootloader to support the flash chip being used proved to be quite a hassle, but we’re graced with a working implementation in the end.

All the details and insights laid out meticulously and to the point, well-deserved criticism of Raspberry Pi silicon and mask ROM design choices, code fully in Rust, and a success story in the end – [xenia]’s write-up has all you could wish for.

Want to learn more about the RP2040’s bootloader specifically? Then check this out — straight out of Cornell, a bootloader that’s also a self-spreading worm. Not only is it perfect for updating your entire RP2040 flock, but it also teaches you everything you could want to know about RP2040’s self-bringup process.