For racing games, flight simulators, and a few other simulation-style games, a simple controller just won’t do. You want something that looks and feels closer to the real thing. The major downsides to these more elaborate input methods is that they take up a large amount of space, requiring extra time for setup, and can be quite expensive as well. To solve both of these problems [Rahel zahir Ali] created a miniature steering wheel controller for some of his favorite games.

While there are some commercial offerings of small steering wheels integrated into an otherwise standard video game controller and a few 3D printed homebrew options, nothing really felt like a true substitute. The main design goal with this controller was to maintain the 900-degree rotation of a standard car steering wheel in a smaller size. It uses a 600P/R rotary encoder attached to a knob inside of a printed case, with two spring-loaded levers to act as a throttle and brake, as well as a standard joystick to adjust camera angle and four additional buttons. Everything is wired together with an Arduino Leonardo that sends the inputs along to the computer.

Now he’s ready to play some of his favorite games and includes some gameplay footage using this controller in the video linked below. If you’re racing vehicles other than cars and trucks, though, you might want a different type of controller for your games instead.

[Marius Taciuc’s] latest endeavor, the B4 Thinker, offers a captivating glimpse into microcontroller architecture through a modular approach. This proof-of-concept project is meticulously documented, with a detailed, step-by-step guide to each component and its function.

Launched in 2014, the B4 Thinker project began with the ambitious goal of building a microcontroller from scratch. The resulting design features a modular CPU architecture, including a base motherboard that can be expanded with various functional modules, such as an 8-LED port card. This setup enables practical experimentation, such as writing simple assembly programs to control dynamic light patterns. Each instruction within this system requires four clock pulses to execute, and the modular design allows for ongoing development and troubleshooting.

While still in its draft phase with some incomplete components, the B4 Thinker project stands out for its educational value and the thorough documentation provided. This modular approach not only supports incremental improvements but also serves as a valuable learning resource for those interested in computer architecture and design.

It seems like four bits is the sweet spot of not to complicated, but not too simple. So we see a lot of 4-bit CPUs. Some even use discrete transistors.

The Raspberry Pi Foundation had their new RP2350 chip audited by Hextree.io, and now, both companies want to see if you can hack it. Just to prove that they’re serious, they’re putting out a $10,000 bounty. Can you get inside?

The challenge to hack the chip is simple enough. You need to dump a secret that is hidden at OTP ROW 0xc08. It’s 128 bits long, and it’s protected in two ways—by the RP2350’s secure boot and by OTP_DATA_PAGE48_LOCK1. Basically, the chip security features have been activated, and you need to get around them to score the prize.

The gauntlet was thrown down ahead of DEF CON, where the new chip was used in the event badges. Raspberry Pi and Hextree.io invited anyone finding a break to visit their booth in the Embedded Systems Village. It’s unclear at this stage if anyone claimed the bounty, so we can only assume the hunt remains open. It’s been stated that the challenge will run until 4 PM UK time on September 7th, 2024.

Hacking microcontrollers is a tough and exacting art. The GitHub repo provides full details on what you need to do, with the precise rules, terms, and conditions linked at the bottom. You can also watch the challenge video on Hextree.io.

MIDI as a standard has opened up a huge world to any musician willing to use a computer to generate or enhance their playing and recording. Since the 80s, it has it has revolutionized the way music is produced and performed, allowing for seamless integration of digital instruments, automation of complex sequences, and unprecedented control over everything from production to editing. It has also resulted in a number of musical instruments that probably wouldn’t be possible without electronic help, like this MIDI instrument which might be the world’s smallest.

Fitting into a cubic inch of space, the tiny instrument’s volume is mostly taken up by the MIDI connector itself which was perhaps an acceptable size by 1980s standards but seems rather bulky today. A two-layer PCB split into three sections sandwiches the connector in place and boasts an ATtiny85 microcontroller and all the associated electronics needed to implement MIDI. Small threaded screws hold the platform together and provide each layer with a common ground. Four small pushbuttons at the top of the device act as the instrument’s keys.

The project’s creator (and Hackaday alum!) [Jeremy Cook] has it set up to play notes from a piano right now, but has also made the source code available so that any musical action can be programmed onto these buttons. Flexibility is perhaps MIDI’s greatest strength and why the standard has lasted for decades now, as it makes it fairly straightforward to build more comprehensive, easy-to-learn musical instruments or even musical instruments out of retro video game systems.

Over the last decade or so, we’ve been inundated with appliances with wireless or “smart” technology that is often of dubious utility. No one really needs a tablet in their refrigerator or Wi-Fi on their coffee maker. A less glamorous kitchen appliance that actually might benefit from some automation and connectivity is the garbage can, or “bin” for those speaking the Queen’s English, and [Mellow_Labs] is here to show off just how to get that done with this automatic garbage can lid.

As he explains, the real impetus behind this build is to not have to touch a dirty lid while cooking to avoid having to take time to wash one’s hands again afterwards. There are a few other design criteria as well; it has to be roommate-approved so nothing permanently attached to the lid, overly complicated, or with an unnecessary amount of wires or other fixtures. A servo with an extension sits on the lid itself, and when activated forces the lid open. A distance sensor provides basic gesture recognition and a microcontroller with wireless connectivity controls both and provides home automation integration as well. With a 3D printed case that includes a quick disconnect function for easy cleaning of the lid, the build was ready to be put into service.

The first iteration used an infrared distance sensor, but placing it by an open window caused it to continuously open and close since sunlight has the same wavelengths of light the sensor is tuned for. A quick swap with an ultrasonic sensor solved the problem, and the garbage can is working flawlessly in the kitchen now. Another appliance that is generally not targeted by off-the-shelf automation solutions is the range fume hood, but another build tackled that problem a while back.

LEDs are a wonderful technology. You put in a little bit of power, and you get out a wonderful amount of light. They’re efficient, cheap, and plentiful. We use them for so much!

What you might not have known is that these humble components have a secret feature, one largely undocumented in the datasheets. You can use an LED as a light source, sure, but did you know you can use one as a sensor?

Dual-Use Devices

The concept of using an LED as a sensor is much like using a speaker as a microphone. Flip things around, and instead of emitting light, the LED senses it instead. You can see the effect quite simply by using a multimeter. Hook up the leads of a multimeter to your LED, and set it to measure current. Point the LED towards the sun, and you’ll likely pick up a reading. While the LED is sensitive to light, it’s usually on quite a small range of wavelength, unlike traditional photodiodes.

But how to use this effect? Well, you can go multiple routes. If you’re of the analog tilt, you can hook the LED up to the inputs of an op-amp, using the device to amplify the output if you so desire. Just about any garden-variety op-amp can be used in such a way that it produces a higher output voltage the more light falls on the LED.

However, you can go so much further, as the bright minds at Mitsubishi Electric Research Laboratories (MERL) determined back in 2003. Following their example, you might like to hook the LED up to a microcontroller. Setting it up in a “reverse biased” mode allows it to act as a sensor when attached to an IO pin, instead of acting as a light emitter. To do this, simply attach the LED’s anode to ground, while connecting the cathode to an I/O pin in a high state. This achieves the “reverse bias,” and charges the inherent capacitance of the LED. The capacitance is small, so this only takes a fraction of a second. Then, the IO pin can be switched to an input, and the capacitance of the LED will discharge into the microcontroller pin. The more light, the more current induced in the LED, and the faster the LED’s capacitance will discharge. Measure how long it takes for the voltage to drop below the IO pin’s digital logic level, and you can sense light levels with a simple IO pin.

In fact, the team at MERL realized that you could go even further. The humble LED could become a “last centimeter” communications device, used as both light transmitter and receiver. To achieve this, one simply had to insert the LED between two tristate IO pins on a microcontroller. With the anode driven high and the cathode driven low, the LED would light. Flipped the other way, and the LED would be reverse biased. Then, one of the tristate pins could be set to input mode to read the LED as a sensor.

As suggested by the team at MERS, LEDs can be used as sensors in all kinds of innovative applications. You could use a TV’s power LED to detect light levels, and thus adjust screen brightness appropriately. You can even do simple proximity sensing, using an array of LEDs to act as emitters and sensors in turn. You could even use status LEDs on small devices to do bidirectional communication if you were so inclined.

And yet! We almost never use LEDs for any of these things. Realistically, while LEDs are sensors, they’re not excellent sensors. We have far better phototransistors, photodiodes, and other sensors available these days. This technique could be useful to you, if you’re trying to design a device with the bare minimum part count or as cheaply as possible. Or, if you want to put surprise functionality into a device that has just an LED on board. But in the real world, this technique doesn’t get a whole lot of use. Futzing around with nifty LED tricks takes more engineering time than just speccing a proper sensor, after all.

Still, the technique has found some real applications. LEDs used in this way do have the benefit of being quite selective as to wavelength, and can be quite stable over time. The legendary Forrest Mims took advantage of this, putting LED sensors to use in a variety of scientific apparatus. Indeed, his ozone measurement device relied on this technique, and was so reliable it proved there was a drift error in NASA’s own Nimbus-7 satellite.

There’s also hope in the rapidly-advancing field of perovskite technology. Perovskite LEDs, or PerLEDs, could use advanced semiconductor materials to create devices that act as both good light sources and capable photodetectors. The hope is that they might be good enough to create touchable displays that need no additional sensor for touch. Instead, the PerLED array would act as both display and sensor. However, for now, the research is at an early stage, and the instability of perovskites means any practical applications are a long way off.

It’s also worth noting that this technique doesn’t work on a lot of modern LEDs. Namely, addressable LEDs, self-flashing LEDs, and anything of that ilk. That’s because this technique relies on hooking up a microcontroller directly to the LED die itself. Many modern “smart” LEDs don’t break out the pins themselves, only providing pins for the controller chip inside. Thus, don’t expect to use this technique with your NeoPixels, WS2812Bs, or anything like that.

Ultimately, using LEDs as a sensor is a fun technique. It’s also highly useful if you’re doing specific things with certain wavelengths of light. Barring that, though, it’s a great party trick to keep in your toolbox, because you never know when it’ll come in handy.

 

In a forum post has come the announcement that mBed, ARM’s accessible microcontroller development platform, is to reach end-of-life in July 2026. This means that the online platform and OS will no longer be supported by ARM, though the latter will remain an open source project. The website will be shuttered, and no new projects can be created after that date using ARM infrastructure.

mBed was originally launched back in 2009, as a competitor to the Arduino IDE for ARM’s chips. Its easy development made it attractive and there were soon an array of boards from different manufacturers supporting it, but perhaps due to its support for only the one architecture, it failed to find success. It’s certainly not the first time a single-architecture microcontroller development platform has been discontinued, we need only look to the Intel Edison for that, but given the success of ARM platforms in general it’s still something of a surprise. Perhaps it’s time to take the press release explanation that other platforms such as Arduino have simply been much more popular.

Will a community form around an open source mBed? Given that it’s been a definite minority among Hackaday projects over the years, while we hope it does, we’re not so sure.

mBed board image: Viswesr, CC BY-SA 3.0.

In case you haven’t heard, about a month ago MicroPython has celebrated its 11th birthday. I was lucky that I was able to start hacking with it soon after pyboards have shipped – the first tech talk I remember giving was about MicroPython, and that talk was how I got into the hackerspace I subsequently spent years in. Since then, MicroPython been a staple in my projects, workshops, and hacking forays.

If you’re friends with Python or you’re willing to learn, you might just enjoy it a lot too. What’s more, MicroPython is an invaluable addition to a hacker’s toolkit, and I’d like to show you why.

Hacking At Keypress Speed

Got a MicroPython-capable chip? Chances are, MicroPython will serve you well in a number of ways that you wouldn’t expect. Here’s a shining example of what you can do. Flash MicroPython onto your board – I’ll use a RP2040 board like a Pi Pico. For a Pico, connect an I2C device to your board with SDA on pin 0 and SCL on pin 1, open a serial terminal of your choice and type this in:

>>> from machine import I2C, Pin
>>> i2c = I2C(0, sda=Pin(0), scl=Pin(1))
>>> i2c.scan()

This interactivity is known as REPL – Read, Evaluate, Print, Loop. The REPL alone makes MicroPython amazing for board bringup, building devices quickly, reverse-engineering, debugging device library problems and code, prototyping code snippets, writing test code and a good few other things. You can explore your MCU and its peripherals at lightning speed, from inside the MCU.

When I get a new I2C device to play with, the first thing I tend to do is wiring it up to a MicroPython-powered board, and poking at its registers. It’s as simple as this:

>>> for i in range(16):
>>>     # read out registers 0-15
>>>     # print "address value" for each
>>>     print(hex(i), i2c.readfrom_mem(0x22, i))
>>> # write something to a second (0x01) register
>>> i2c.writeto_mem(0x22, 0x01, bytes([0x01]) )

That i2c.scan() line alone replaces an I2C scanner program you’d otherwise have to upload into your MCU of choice, and you can run it within three to five seconds. Got Micropython running? Use serial terminal, Ctrl+C, and that will drop you into a REPL, just type i2c.scan() and press Enter. What’s more, you can inspect your code’s variables from the REPL, and if you structure your code well, even restart your code from where it left off! This is simply amazing for debugging code crashes, rare problems, and bugs like “it stops running after 20 days of uptime”. In many important ways, this removes the need for a debugger – you can now use your MCU to debug your code from the inside.

Oh, again, that i2c.scan()? You can quickly modify it if you need to add features on the fly. Want addresses printed in hex? (hex(addr) for addr in i2c.scan()). Want to scan your bus while you’re poking your cabling looking for a faulty wire? Put the scan into a while True: and Ctrl+C when you’re done. When using a typical compiled language, this sort of tinkering requires an edit-compile-flash-connect-repeat cycle, taking about a dozen seconds each time you make a tiny change. MicroPython lets you hack at the speed of your keyboard typing. Confused the pins? Press the `up` button, edit the line and run the i2c = line anew.

To be clear, all of code is running on your microcontroller, you just type it into your chip’s RAM and it is executed by your MCU. Here’s how you check GPIOs on your Pi Pico, in case you’re worried that some of them have burnt out:

>>> from machine import Pin
>>> from time import sleep
>>> pin_nums = range(30) # 0 to 29
>>> # all pins by default - remove the ones connected to something else if needed
>>> pins = [Pin(num, Pin.OUT) for num in pin_nums]
>>> 
>>> while True:
>>>   # turn all pins on
>>>   for i in range(len(pins)):
>>>     pins[i].value(True)
>>>   sleep(1)
>>>   # turn all pins off
>>>   for i in range(len(pins)):
>>>     pins[i].value(False)
>>>   sleep(1)
>>>   # probe each pin with your multimeter and check that each pin changes its state

There’s many things that make MicroPython a killer interpreter for your MCU. It’s not just the hardware abstraction layer (HAL), but it’s also the HAL because moving your code from board to board is generally as simple as changing pin definitions. But it’s all the other libraries that you get for free that make Python awesome on a microcontroller.

Batteries Included

It really is about the batteries – all the libraries that the stock interpreter brings you, and many more that you can download. Only an import away are time, socket, json, requests, select, re and many more, and overwhelmingly, they work the same as CPython. You can do the same r = requests.get("https://retro.hackaday.com"); print(r.text)[:1024] as you would do on desktop Python, as long as you got a network connection going on. There will be a few changes – for instance, time.time() is an integer, not a float, so if you need to keep track of time very granularly, there are different functions you can use.

Say, you want to parse JSON from a web endpoint. If you’re doing that in an Arduino environment, chances are, you will be limited in what you can do, and you will get triangle bracket errors if you mis-use the JSON library constructs because somehow the library uses templates; runtime error messages are up to you to implement. If you parse JSON on MicroPython and you expect a dict but get a list in runtime, it prints a readable error message. If you run out of memory, you get a very readable MemoryError printed out, you can expect it and protect yourself from it, even fix things from REPL and re-run the code if needed.

The user-supplied code is pretty good, too. If you want PIO or USB-HID on the RP2040, or ESP-CPU-specific functions on the ESP family, they are exposed in handy libraries. If you want a library to drive a display, it likely already has been implemented by someone and put on GitHub. And, if that doesn’t exist, you port one from Arduino and publish it; chances are, it will be shorter and easier to read. Of course, MicroPython has problems. In fact, I’ve encountered a good few problems myself, and I would be amiss not mentioning them.

Mind The Scope

In my experience, the single biggest problem with MicroPython is that writing out `MicroPython` requires more of my attention span than I can afford. I personally shorten it to uPy or just upy, informally. Another problem is that the new, modernized MicroPython logo has no sources or high-res images available, so I can’t print my own stickers of it, and MicroPython didn’t visit FOSDEM this year, so I couldn’t replenish my sticker stock.

On a more serious note, MicroPython as a language has a wide scope of where you can use it; sometimes, it won’t work for you. An ATMega328P can’t handle it – but an ESP8266 or ESP32 will easily, without a worry in the world, and you get WiFi for free. If you want to exactly control what your hardware does, counting clock cycles or hitting performance issues, MicroPython might not work for you – unless you write some Viper code.

If you want to have an extremely-low-power MCU that runs off something like energy harvesting, MicroPython might not work – probably. If you need your code run instantly once your MCU gets power, mind the interpreter takes a small bit of time to initialize – about one second, in my experience. If you want to do HDMI output on a RP2040, perhaps stick to C – though you can still do PIO code, there are some nice libraries for it.

Some amount of clock cycles will be spent on niceties that Python brings. Need more performance? There are things you can do. For instance, if you have a color display connected over SPI and you want to reduce frame rendering time, you might want to drop down to C, but you don’t have to ditch MicroPython – just put more of your intensive code into C-written device drivers or modules you compile, and, prototype it in MicroPython before you write it.

As Seen On Hackaday

If you’ve followed the USB-C PD talking series, you must’ve seen that the code was written in MicroPython, and I’ve added features like PD sniffing, DisplayPort handling and PSU mode as if effortlessly; it was just that easy to add them and more. I started with the REPL, a FUSB302 connected to a RP2040, poking at registers and reading the datasheet, and while I needed outside help, the REPL work was so so much fun!

There’s something immensely satisfying about poking at a piece of technology interactively and trying to squeeze features out of it, much more if it ends up working, which it didn’t, but it did many other times! I’ve been hacking on that PD stack, and now I’m slowly reformatting it from a bundle of functions into object-based code – Python makes that a breeze.

Remember the Sony Vaio board? Its EC (embedded controller) is a RP2040, always powered on as long as batteries are inserted, and it’s going to be running MicroPython. The EC tasks include power management, being a HID over I2C peripheral, button and LED control, and possibly forwarding keyboard and trackpoint events to save a USB port from the second RP2040, which will run QMK and server as a keyboard controller. MicroPython allows me to make the firmware quickly, adorn it with a dozen features while I do it, and keep the codebase expandable on a whim. The firmware implementation will be a fun journey, and I hope I can tell about it at some point.

Have you used MicroPython in your projects? What did it bring to your party?

Model rocketry has always taken cues from what’s happening in the world of full-scale rockets, with amateur rocketeers doing their best to incorporate the technologies and methods into their creations. That’s not always an easy proposition, though, as this three-year effort to nail a SpaceX-style vertical landing aptly shows.

First of all, hats off to high schooler [Aryan Kapoor] from JRD Propulsion for his tenacity with this project. He started in 2021 with none of the basic skills needed to pull off something like this, but it seems like he quickly learned the ropes. His development program was comprehensive, with static test vehicles, a low-altitude hopper, and extensive testing of the key technology: thrust-vector control. His rocket uses two solid-propellant motors stacked on top of each other, one for ascent and one for descent and landing. They both live in a 3D printed gimbal mount with two servos that give the stack plus and minus seven degrees of thrust vectoring in two dimensions, which is controlled by a custom flight computer with a barometric altimeter and an inertial measurement unit. The landing gear is also clever, using rubber bands to absorb landing forces and syringes as dampers.

The video below shows the first successful test flight and landing. Being a low-altitude flight, everything happens very quickly, which probably made programming a challenge. It looked like the landing engine wasn’t going to fire as the rocket came down significantly off-plumb, but when it finally did light up the rocket straightened and nailed the landing. [Aryan] explains the major bump after the first touchdown as caused by the ascent engine failing to eject; the landing gear and the flight controller handled the extra landing mass with aplomb.

All in all, very nice work from [Aryan], and we’re keen to see this one progress.

The look, the feel, the sound — there are few things more satisfying in this world than a nice switch. If you’re putting together a device that you plan on using frequently, outfitting it with high-quality switches is one of those things that’s worth the extra cost and effort.

So we understand completely why [STR-Alorman] went to such great lengths to get the aftermarket seat heaters he purchased working with the gorgeous switches Toyota used in the 2006 4Runner. That might not sound like the kind of thing that would involve reverse engineering hardware, creating a custom PCB, or writing a bit of code to tie it all together. But of course, when working on even a halfway modern automobile, it seems nothing is ever easy.

The process started with opening up the original Toyota switches and figuring out how they work. The six-pin units have a lot going on internally, with a toggle, a rheostat, and multiple lights packed into each one. Toyota has some pretty good documentation, but it still took some practical testing to distill it down into something a bit more manageable. The resulting KiCad symbol for the switch helps explain what’s happening inside, and [STR-Alorman] has provided a chart that attributes each detent on the knob with the measured resistance.

But understanding how the switches worked was only half the battle. The aftermarket seat heaters were only designed to work with simple toggles, so [STR-Alorman] had to develop a controller that could interface with the Toyota switches and convince the heaters to produce the desired result. The custom PCB hosts a Teensy 3.2 that reads the information from both the left and right seat switches, and uses that to control a pair of beefy MOSFETs. An interesting note here is the use of very slow pulse-width modulation (PWM) used to flip the state of the MOSFET due to the thermal inertia of the heater modules.

We love the effort [STR-Alorman] put into documenting this project, going as far as providing the Toyota part numbers for the switches and the appropriate center-console panel with the appropriate openings to accept them. It’s an excellent resource if you happen to own a 4Runner from this era, and a fascinating read for the rest of us.