In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?

The 16×2 LCD display is a classic in the microcontroller world, and for good reason. Add a couple of wires, download a library, mash out a few lines of code, and your project has a user interface. A utilitarian and somewhat boring UI, though, and one that can be hard to read at a distance. So why not spice it up with these large-type custom fonts?

As [Vaclav Krejci] explains, the trick to getting large fonts on a display that’s normally limited to two rows of 16 characters each lies in the eight custom characters the display allows to be added to its preprogrammed character set. These can store carefully crafted patterns that can then be assembled to make reasonable facsimiles of the ten numerals. Each custom pattern forms one-quarter of the finished numeral, which spans what would normally be a two-by-two character matrix on the display. Yes, there’s a one-pixel wide blank space running horizontally and vertically through each big character, but it’s not that distracting.

Composing the custom patterns, and making sure they’re usable across multiple characters, is the real hack here, and [Vaclav] put a lot of work into that. He started out in Illustrator, but quickly switched to a spreadsheet because it allowed him to easily generate the correct binary numbers to pass to the display for each pattern. It seems to have really let his creative juices flow, too — he came up with 24 different fonts! Out favorite is the one he calls “Tron,” which looks a bit like the magnetic character recognition font on the bottom of bank checks. Everyone remembers checks, right?

Hats off to [Vaclav] for a creative and fun way to spice up the humble 16×2 display. We’d love to see someone pick this up and try a complete alphanumeric character set, although that might be a tall order with only eight custom characters to work with. Then again, if Bad Apple on a 16×2 is possible…

Both Arduino and MicroPython are giants when it comes to the electronics education area, and each one of them represents something you can’t pass up on as an educator. Arduino offers you a broad ecosystem of cheap hardware with a beginner-friendly IDE, helped by forum posts explaining every single problem that you could and will stumble upon. MicroPython, on the other hand, offers a powerful programming environment ripe for experimentation, and doesn’t unleash a machine gun fire of triangle brackets if you try to parse JSON slightly incorrectly. They look like a match made in heaven, and today, from heaven descends the Arduino Lab for MicroPython.

This is not an Arduino IDE extension – it’s a separate Arduino IDE-shaped app that does MicroPython editing and uploads code to your board from a friendly environment. It works over a serial port, and as such, the venerable ESP8266-based boards shouldn’t be be left out – it even offers file manager capabilities! Arduino states that this is an experimental effort – it doesn’t yet have syntax checks, for instance, and no promises are made. That said, it already is a wonderful MicroPython IDE for beginner purposes, and absolutely a move in the right direction. Want to try? Download it here, there’s even a Linux build!

High-level languages let you build projects faster – perfect fit for someone getting into microcontrollers. Hopefully, what follows is a MicroPython library manager and repository! We’ve first tried out MicroPython in 2016, and it’s come a long way since then – we’ve seen quite a few beginner-friendly MicroPython intros, from a gaming handheld programming course, to a bipedal robot programming MicroPython exploration. And, of course, you can bring your C libraries with you.

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!

Ok, we’ll come clean. [Design Build Destroy] didn’t really add any memory to his Arduino Nano. But he did get about 1.5K more program space when compared to the stock setup. The trick? On some Nano boards and clones, the bootloader is set to use a large block of reserved memory, but Optiboot only requires a fraction of that reserved memory. By reprogramming the bootloader and changing the configuration fuses, you can reclaim that unused memory.

Of course, you can’t easily overwrite the bootloader and fuses over the serial port to prevent you from bricking your device. The video below shows how to connect another Arduino to do the programming. You could also use any dedicated AVR programmer you happen to have. Oddly, the Uno already uses Optiboot with the same processors, and is set correctly and the video shows the differences in the configuration between the two in their default state.

Of course, depending on where you get your Nano devices and their age, you may already have this set up at which point you won’t gain anything, but you should be able to easily tell if you need to go through the steps or not. The same trick will probably work with any older Arduino boards you have laying around if Optiboot supports them. What can you do with the extra memory? Maybe speech recognition?

Thanks to the virus crisis, lots of people are designing makeshift ventilator designs in the hopes of saving people’s lives. Many of these are based around some sort of Arduino-powered CPU. [Armstrong Subero] things that’s a great idea, but cautions that making an electronic pair of dice is a different proposition than creating a machine to breathe for someone. But he isn’t just complaining. He talks about considerations when building a real-time and safety-critical system.

[Armstrong] has a lot of good points, although we aren’t sure you need the complexity of a real-time operating system just to squeeze a bag. If anything, that seems like it might make it more susceptible to unexpected operation. However, we agree with his comments that you should have closed-loop control to make sure the device is working, alarming when the device isn’t working, and watchdog timers to guard against lockup.

One excellent point from the post:

For example a high availability system real time system may be specified as having an up time of around 99% in a 24 hour period. Which 1% of the day is it acceptable to have the ventilator not operational? Since we have 1440 minutes in a day, which 14.4 minutes of the day should the patient not be allowed to breathe?

However, he does have some solid suggestions such as using an IDE with debugging and adhering to a coding standard such as MISRA. Of course, he also points out you might choose a different CPU that has safety-critical certifications and corresponding libraries. One suggestion is to have multiple CPUs, and this is a common enough solution in many safety-critical systems. For example, imagine 3 CPUs driving a switching circuit that requires a low logic level to turn on.

You could make the outputs go to inputs if the CPU wants to not drive the switch, or pull the output to ground if it does. Then a pull-up resistor holds the state high if no CPU pulls it to ground. All CPUs could sense the state of the line and if they don’t think it looks right they sound their own alarm. Some systems vote so that two of three CPUs must agree (at least) or, in some cases, three out of five.

We’ve been talking about ventilators quite a bit lately. The kind of mechanical design [Armstrong] is probably thinking of is like the MIT design we talked about last week.

Inspired by the over-the-top stage lighting and pyrotechnics used during e-sport events, [Hans Peter] set out to develop a scaled-down version (minus the flames) for his personal Counter-Strike: Global Offensive sessions. It might seem like pulling something like this off would involve hacking the game engine, but as it turns out, Valve was kind enough to implement a game state API that made it relatively easy.

According to the documentation, the CS:GO client can be configured to send out state information to a HTTP server at regular intervals. It even provided example code for implementing a simple state server in Node.js, which [Hans] adapted for this project by adding some conditional statements that analyze the status of the current game.

These functions fire off serial commands to the attached Arduino, which in turn controls the WS2812B LEDs. The Arduino code takes the information provided by the HTTP server and breaks that down into various lighting routines for different conditions such as wins and losses. But things really kick into gear when a bomb is active.

[Hans] wanted to synchronize the flashing LEDs with the beeping sound the bomb makes in the game, but the API doesn’t provide granular enough data. So he recorded the audio of the bomb arming sequence, used Audacity to precisely time the beeps, and implemented the sequence in his Arduino code. In the video after the break you can see that the synchronization isn’t perfect, but it’s certainly close enough to get the point across in the heat of battle.

With the special place that Counter-Strike occupies in the hearts of hackers and gamers alike, it’s little surprise people are still finding unique ways to experience the game.

Machine learning is starting to come online in all kinds of arenas lately, and the trend is likely to continue for the forseeable future. What was once only available for operators of supercomputers has found use among anyone with a reasonably powerful desktop computer. The downsizing isn’t stopping there, though, as Microsoft is pushing development of machine learning for embedded systems now.

The Embedded Learning Library (ELL) is a set of tools for allowing Arduinos, Raspberry Pis, and the like to take advantage of machine learning algorithms despite their small size and reduced capability. Microsoft intended this library to be useful for anyone, and has examples available for things like computer vision, audio keyword recognition, and a small handful of other implementations. The library should be expandable to any application where machine learning would be beneficial for a small embedded system, though, so it’s not limited to these example applications.

There is one small speed bump to running a machine learning algorithm on your Raspberry Pi, though. The high processor load tends to cause small SoCs to overheat. But adding a heatsink and fan is something we’ve certainly seen before. Don’t let your lack of a supercomputer keep you from exploring machine learning if you see a benefit to it, and if you need more power than just one Raspberry Pi you can always build a cluster to get your task done just a little bit faster, too.

Thanks to [Baldpower] for the tip!

A good deal of the projects we cover here at Hackaday are not, in the strictest sense, practical endeavors. If we required that everything which graced our digital pages had a clear end result, the site would be in a rather sad state of affairs. Sometimes it’s enough just to do something for the challenge of it. But more often than not, you’ll learn something in the process which you can use down the line.

That’s precisely what pushed [Laurence Bank] to see how well he could optimize the frame rate on the popular SSD1306 OLED display. After several iterations of his code, he was able to achieve a blistering 151.5 FPS, with apparently still some room for improvement if he’s feeling up to the challenge. But considering his first attempt was only running at 5.5 FPS, we’d say he’s already more than earned his hacker cred on this one.

A few different tricks were used to achieve such incredible performance gains. To start with, while the official I2C specification says you’re supposed to wait for an acknowledgment back from the device when communicating with it, [Laurence] realized the SSD1306 didn’t actually care. He could continuously blast commands at the display without bothering to wait for an acknowledgment. He admits there are problems with this method, but you can’t argue with the results.

To really wring all the performance out of the system he could, [Laurence] donned his Assembly Cap and examined how the Arduino IDE compiler was interpreting his code. He identified a few areas where changing his C code would force the compiler to generate faster output. He notes that this wouldn’t normally be required when working with more advanced compilers, but that the Arduino toolchain needs its hand held occasionally.

This isn’t the first time we’ve seen somebody try and push more pixels through the very same OLED display, and it’s interesting to see the two very different approaches to the same goal.

Space. The final frontier. Unfortunately, the vast majority of us are planet-locked until further notice. If you are dedicated hobbyist astronomer, you probably already have the rough positions of the planets memorized. But what if you want to know them exactly from the comfort of your room and educate yourself at the same time? [Shubham Paul] has gone the extra parsec to build a Real-Time Planet Tracker that calculates their locations using Kepler’s Laws with exacting precision.

An Arduino Mega provides the brains, while 3.5-turn-pan and 180-degree-tilt servos are the brawn. A potentiometer and switch allow for for planet and mode selection, while a GPS module and an optional MPU9250 gyroscope/magnetometer let it know where you are. Finally a laser pointer shows the planet’s location in a closed room. And then there’s code: a lot of code.

The hardware side of things — as [Shubham Paul] clarifies — looks a little unfinished because the focus of the project is the software with the intent to instruct. They have included all the code they wrote for the RTPT, providing a breakdown in each section for those who are looking to build their own.

There is an extra step to auto-align the RTPT to north, otherwise you’ll have to do so manually. But [Shubham Paul] has designed it so that even if you move the tracker about, the RTPT will readjust its calculations in real time. Each part of the project includes a wealth of related information beyond simple instructions to adequately equip any prospective builders.

This hack gets the job done. If it’s looks you’re after, an artistic expression of maker skills and astronomy can be seen in this planetary map that relies on persistence of vision.