Oftentimes, when we’re using a microcontroller, we’re whipping up some very specific code focused on executing a particular task. The device is set up to execute code that does exactly what we want with minimal overhead. However, sometimes, there are scenarios where it pays to go with a somewhat heavier setup, wherein the microcontroller runs an operating system for the benefits that offers.

Federico Terraneo came to Hackaday Europe to discuss this very topic. He talks about kernel architecture, real-time operating systems, and how to best use C++ in the world of microcontrollers.

Microcontrolling

The talk begins in a helpful place. Federico starts by explaining what an operating system actually is. Basically, it’s the software that exists between the hardware and the applications that run upon it. Breaking it down into parts, an operating system typically consists of a main kernel, atop which sits things like the basic system services, libraries, and device drivers, along with utility programs necessary to maintain and work with the system. The user interface sits on top of all that, which allows the user to select and run applications and generally use the operating system to get things done.

Of course, different operating systems differ in the specifics of their architectures. Monolithic kernels, such as Linux relies on, keep a split between kernelspace and userspace. This is where where the kernel has full hardware access running on the CPU in system mode, while the applications run in user mode without such direct access. Monolithic kernels typically only run on architectures with memory management units (MMU)—think full-scale computers with proper CPUs, like your laptop or desktop. Unikernel operating systems, like FreeRTOS, are a little different, where applications and the operating system are collapsed down into a single executable binary that runs with raw hardware access. There is no abstraction, no memory protection, or anything like that, which makes the architecture easier to run on typical microcontrollers. There are also microkernels, which aim to minimize the amount of code that runs in system mode, pushing things like drivers and filesystem access into userspace. This architecture still needs an MMU, and is mostly only seen in niche uses where high security and/or attention to safety is critical.

When it comes to microcontrollers, unikernels are the most relevant architecture to think about. However, they have limitations–in stability, in security, in the fact that there is no run-time code loading or any way to easily partially upgrade the system. The fluid kernel, which Federico came to explain, aims to solve some of these issues. It hopes to offer a scalable operating system solution that works across the world of embedded computing, where sometimes microcontroller resources are limited and where memory management units seldom exist. It’s also intended to be compatible with standard APIs—think POSIX, C++ standard libraries, and all that. Federico calls it the “UNIX on a chip” concept.

The fluid kernel aims to exist at the intersection of the monolithic kernel and the unikernel. It allows hosting applications in kernelspace or in userspace as needed. A fluid kernel is also built to be POSIX compliant twice—with the same API whether you’re operating in kernelspace or userspace. The fluid kernel concept is designed around achieving process abstraction via the hardware Memory Protection Unit (MPU) common in modern 32-bit microcontrollers. It’s not quite an MMU, and can’t do all the same fancy virtual memory tricks, but it’s enough to provide a basic level of memory protection on a microcontroller platform. The fluid kernel can also become a unikernel if so desired as a compile-time option, which takes away process support while reducing code size significantly. It allows for unikernel devleopment that can be upgraded into a fluid kernel later by flipping the compile-time option the other way.

Federico does a great job of explaining the pros and cons of the fluid kernel architecture, and explores the security implications inherent in going this route. The Miosix RTOS is discussed as the practical implementation of this philosophy, and there’s even a helpful diversion into the efficient use of C++ on microcontrollers. If you’re getting serious about embedded development, or you just want to learn about a new architecture you might find useful one day, it’s a great talk to dive into on your next lunch break.

There are many ways to detect stress in an individual. You can use self-reporting checklists, you could try and measure various vital signs like respiratory rate and pulse and infer things, or you could observe the levels of hormones like cortisol in the blood.

Or… you could pull some parts out of a Playstation 4, and get hacking. Edwin Hwu did precisely that, creating a device that can image the skin down to the nanometer and potentially even determine fine details about an individual’s health status. He came to Hackaday Europe 2026 to tell us all about it.

Look Closely

Edwin’s background is very relevant to this project. He worked in a research institute in Taiwan where he collaborated with the German National Metrology Institute, working on atomic resolution imaging on silicon wafers. When you’re doing sub-nanometer calibration work for the semiconductor industry, that’s serious stuff, as is the X-ray microscopy that Edwin has dived into. When it comes to looking at things at very tiny scales, he knows his stuff. He’s also done plenty of work on real-time cell culture monitoring, skin assessments, and even high resolution 3D printing. It’s a broad skill base that all fed into the project he came to Hackaday Europe to talk about.

There is a problem with optical microscopy that comes down to the diffraction limit of light—which means you can only image down to a resolution of around 1 micrometer. That’s why we use scanning electron microscopes for so many finer tasks, because the diffraction limit of electron beams is so much smaller. This allows the imaging of structures like carbon nanotubes or buckyballs, but with the limitation that the surface must be conductive and the imaging be done in a vacuum environment. A newer technology is the atomic force microscope (AFM), which involves using a very sharp probe with a tip of just 2-3 nanometers to actually touch molecules. This can be done without a need for a conductive surface or vacuum. When taking this approach to look at things on the nanometer scale, Edwin likens it to trying to poke a 1 euro coin with the tallest mountain on Earth. It’s a precise device with incredibly high resolution, but the average AFM costs half a million euros, and is incredibly bulky and slow at what it does. That is, unless… you find a way to build one on the cheap.

Some time ago, Edwin created an atomic force microscope using the optical head of a DVD player, achieving a resolution of 0.39 nanometers. With this build, it was possible to image a single strand of DNA. Edwin also talks about how he used simple piezoelectric buzzers to create an ultrafine scanner for this work. The piezo elements are used for actuation, since they can be controlled to make incredibly minute movements. The work developed to the point where DIY AFM kits were made available at a mere fraction of the cost of traditional laboratory-grade installations.

This work spawned a greater plan. Through his talk, Edwin explains how he figured out that e-waste gaming consoles could be turned into cutting-edge atomic force microscopes. Specifically, the Playstation 4 was the perfect candidate, with its high-end Blu-Ray optical head which is capable of reaching the diffraction limit of light. The Blu-Ray optical head is used to monitor the movement of the AFM probe, while scanning it is achieved with a piezo rig just like the earlier DVD-based build. It also has the benefit that the Blu-Ray hardware is built for higher data rates, meaning it’s possible to stream data from the optical head much faster for a quicker AFM scan. Edwin refers to his build as the HS-DAFM—for High Speed Dermal Atomic Force Microscope—since it’s 100 times faster than traditional laboratory atomic force microscopes.

The word “dermal” is important—because Edwin has put the build to use in examining skin nanotexture, for diagnostic purposes. His talk explains how, combined with machine learning systems, the tool can be used to investigate skin conditions and help in the diagnostic process. It’s also become useful from the perspective of cosmetics, and looking at how the skin looks at the nanoscale due to factors like aging and UV exposure. With the aid of machine learning tools, Edwin has found that it’s even possible to determine if someone has asthma with 75% accuracy, just from a skin scan. There is even an exploration of mental stress versus skin nanotexture, albeit in a very preliminary stage.

If you’ve ever wondered about the finer details of doing atomic force microscopy on the cheap, or how skin texture holds the secrets of so many health-related matters, Edwin’s talk is a great one. Sometimes thinking outside of the box and the limitations of commercial laboratory equipment can lead to wonderous things, as it did here!