Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

An ATTiny board that one of the students developed for this project, etched on single-sided FR4.

Electronics And C++ Education With An ATTiny13

When [Adam, HA8KDA] is not busy with his PhD studies, he mentors a group of students interested in engineering. To teach them a wide range of topics, he set out to build a small and entertaining embedded project as they watch and participate along the way. With this LED-adorned ATTiny13A project, [Adam] demonstrated schematic and PCB design, then taught C++ basics and intricacies – especially when it comes to building low-footprint software – and tied it all together into a real-world device students could take home after the project. His course went way beyond the “Hello world”s we typically expect, and some of us can only wish for a university experience like this.

He shares the PCB files and software with us, but also talks about the C++20 framework he’s developed for this ATTiny. The ATTiny13A is very cheap, and also very limited – you get 1K of ROM and 64 bytes of RAM. This framework lets you make good use of it, providing the basics like GPIO wiggling, but also things like low-power operation hooks, soft PWM with optional multi-phase operation support and EEPROM access. Students could write their own animations for this device, and he includes them in the repo, too!

In educational projects, it pays to keep code direct and clean, cruft-less and accessible to students. These are the things you can only achieve when you truly understand the tools you’re working with, which is the perfect position for teaching about them! [Adam] intends to show that C++ is more than suitable for low-resource devices, and tells us about the EEPROM class code he wrote – compiling into the same amount of instructions as an Assembly implementation and consuming the same amount of RAM, while providing compile-time checks and fail-safe syntax.

We’ve talked about using C++ on microcontrollers before, getting extra compile-time features without overhead, and this project illustrates the concept well. [Adam] asks us all, and especially our fellow C++ wizards, for our opinions on the framework he designed. Could you achieve even more with this simple hardware – make the code more robust, clean, have it do more within the limited resources?

What could you build with an ATTiny13, especially with such a framework? A flashy hairclip wearable, perhaps, or a code-learning RF-remote-controlled outlet. We’ve also seen a tiny camera trigger for endurance races,, a handheld Flappy Bird-like console, and many more!

Free Your Pi With This Bare Metal Programming Environment

[Rene Strange] has graced these fair pages a short while ago with a sweet Raspberry Pi software based poly synth, with a tantalising reference to it being a bare metal application. So now, we’ll look into circle, the bare metal programming environment that it is based upon. The platform consists of a large set of C++ classes to access the hardware as well as perform tasks such as task creation and scheduling in the cooperative multitasking, multicore environment. Supporting all Raspberry Pi boards from version 2 onwards (not including the Pico!) in both 32-bit and 64-bit flavours, the environment is pretty complete. Classes are provided for USB, networking, FatFS, as well as more mundane tasks such as dealing with interrupts. On top of these classes there are a pile of application-specific libraries, covering functions such as display interfacing, GUIs using a variety of frameworks, and some more esoteric applications such as interfacing to a Pico, and even sending the system log to a remote web browser!

Classes and libraries however, don’t always help by themselves, which is where the 42 (yes, we know) code examples come in very handy. They’ve provided example applications for some fun stuff like drawing Mandelbrot fractals to the display, as well as some more mundane tasks that we have to deal with such as getting that pesky DMA controller to play nice with the SPI hardware. All-in-all, this looks like a great set of tools for taking full advantage of some fairly beefy hardware for your next embedded project that needs plenty of resources, but not all that unnecessary operating system stuff.

Perhaps not quite as complete as circle, but we’ve seen a fair few Raspberry Pi Bare metal projects over the years, like the Nerdsynth, based on the PiZero, and this neat little bare metal assembly language clone of starfox.

Thanks [Ruhan] for the tip!

Header: Aryan Patidar, CC BY 4.0/Evan-Amos, Public domain.

How Did We Get To The Speed Of Light?

Every high school physics student knows c, or the speed of light, it’s 3 x 10^8 metres per second. More advanced or more curious students will know that this is an approximation, and the figure of 299,792,458 metres per second that forms the officially accepted figure comes from a resonance of the caesium atom from which is derived a value for the second.

Galileo Galilei, whose presence in this story should come as no surprise. Justus Sustermans, Public domain.

But for those who are really curious about measuring the speed of light the question remains: Just how did we arrive at that figure and how long have we been measuring it? The answer contains some surprises, and some exceptionally clever scientific thought and experimentation over the centuries.

The nature of light and whether it had a speed at all had been puzzling philosophers and scientists since antiquity, but the first experiments performed in an attempt to measure it were you will not be surprised to hear, performed by Galileo sometime in the early 17th century. His experiment involved his observation of assistants uncovering lanterns at known distances away, and his observations  failed to arrive at a figure.

Later that century in 1676 the first numerical estimate of the speed of light was made by the Danish astronomer Ole Rømer, who observed an apparent variation in the period of one of Jupiter’s moons depending upon whether the Earth was approaching it or moving away from it. From this he was able to estimate the time taken for light to cross the Earth’s orbit, and from there the mathematician Christiaan Huygens was able to produce a figure of 220,000,000 metres per second.

Spinning Cogs And Mirrors: Time Of Flight

The mile-long evacuated tube used in Michelson's time-of-flight experiment. H.
The mile-long evacuated tube used in Michelson’s time-of-flight experiment. H. H. Dunn, Public domain.

The experiments with which we will perhaps be the most familiar are the so-called time of flight measurements, which take Galileo’s idea of observing the delay as light travels over a distance, and bring to it ever higher precision. This was first performed in the middle of the 19th century by the French physicist Hippolyte Fizeau, who reflected a beam of light from a mirror over several kilometres, and used a toothed wheel to chop it into pulses. The pulses could be increased in frequency by moving the wheel faster until the time taken for the light to travel the distance from wheel to mirror and back again matched the separation between teeth and the returning pulse could be observed. His calculation of 313,300,000 metres per second was successively improved upon through the work of succession of others including Léon Foucault, culminating in the series of experiments by the American physicist Albert A. Michelson in the 1920s. Michelson’s final figure stood at 299,774,000 metres per second, measured through a multi-path traversal of a mile-long evacuated tube in the California desert. In the second half of the century the techniques shifted to laser interferometry, and in the quest to define the SI units in terms of constants, eventually to the definition mentioned in the first paragraph.

The most fascinating part of the story probably encapsulates the essence of scientific discovery, namely that while to arrive at something takes the work of many scientists building on the work of each other, it can then often be rendered into a form that can be understood by a student who hasn’t had to pass through all that effort. We could replicate Fizeau and Michelson’s experiments with a pulse generator, laser diode, and oscilloscope, which while of little scientific value nearly a century after Michelson’s evacuated tube, is still immensely cool. Has anyone out there given it a try?

Header image: Tommology, CC BY-SA 4.0.

Linux Fu: Fusing Hackaday

Unix and, by extension, Linux, has a mantra to make everything possible look like a file. Files, of course, look like files. But also devices, network sockets, and even system information show up as things that appear to be files. There are plenty of advantages to doing that since you can use all the nice tools like grep and find to work with files. However, making your own programs expose a filesystem can be hard. Filesystem code traditionally works at the kernel module level, where mistakes can wipe out lots of things and debugging is difficult. However, there is FUSE — the file system in user space library — that allows you to write more or less ordinary code and expose anything you want as a file system. You’ve probably seen FUSE used to mount, say, remote drives via ssh or Dropbox. We’ve even looked at FUSE before, even for Windows.

What’s missing, naturally, is the Hackaday RSS feed, mountable as a normal file. And that’s what we’re building today.

Writing a FUSE filesystem isn’t that hard, but there are a lot of tedious jobs. You essentially have to provide callbacks that FUSE uses to do things when the operating system asks for them. Open a file, read a file, list a directory, etc. The problem is that for some simple projects, you don’t care about half of these things, but you still have to provide them.

Luckily, there are libraries that can make it a lot easier. I’m going to show you a simple C++ program that can mount your favorite RSS feed (assuming your favorite one is Hackaday, of course) as a file system. Granted, that’s not amazing, but it is kind of neat to be able to grep through the front page stories from the command line or view the last few articles using Dolphin. Continue reading “Linux Fu: Fusing Hackaday”

The Legend Of Zelda: Decompiled

Keeping source code to programs closed is something that is generally frowned upon here for plenty of reasons. Closed source code is less secure and less customizable, but unfortunately we won’t be able to convince everyone of the merits of open source code any time soon. On the other hand, it is possible to decompile some of those programs whose source remains behind locked doors in an attempt to better understand that code, and one of the more impressive examples of that of late is this project which has fully decompiled The Ocarina of Time.

To get started with the code for this project, one simply needs to clone the Git repository and then use a certain set of software tools (depending on the user’s operating system) to compile the ROM from the source code. From there, though, the world is your rupee-filled jar. Like we’ve seen from other decompiled games, any number of enhancements to the original game can be made including increasing the frame rate, improving the graphics, or otherwise adding flourishes that wouldn’t otherwise be there.

The creators of this project do point out that this is still a work-in-progress as only one of the 18 versions have been completed, but the fact that the source code they have been able to decompile builds a fully-working game when recompiled speaks to how far along it’s come. We’ve seen similar processes used for other games before that also help to illustrate how much improvement is possible when re-writing old games from their source code.

Thanks to [Lazarus] for the tip!

Continue reading “The Legend Of Zelda: Decompiled”

Classic 80s Text-To-Speech On Classic 80s Hardware

Those of us who were around in the late 70s and into the 80s might remember the Speak & Spell, a children’s toy with a remarkable text-to-speech synthesizer. While it sounds dated by today’s standards, it was revolutionary for the time and was riding a wave of text-to-speech functionality that was starting to arrive to various computers of the era. While a lot of them used dedicated hardware to perform the speech synthesis, some computers were powerful enough to do this in software, but others were not quite able. The VIC-20 was one of the latter, but thanks to an ESP8266 it has been retroactively given this function.

This project comes to us from [Jan Derogee], a connoisseur of this retrocomputer, and builds on the work by [Earle F. Philhower] who ported the retro speech synthesis software known as SAM from assembly to C which made it possible to run on the ESP8266. Audio playback is handled on the I2S port, but some work needed to be done to get this to work smoothly since this port also handles the communication with the VIC-20. Once this was sorted out, a patch was made to be able to hear the computer’s audio as well as the speech synthesizer’s. Finally, a serial command interface was designed by [Jan] which allows for control of the module.

While not many of us have VIC-20s sitting at home, it’s still an interesting project that shows the broad scope of a small and inexpensive chip like the ESP8266 which would have had a hefty price tag back in the 1980s. If you have other 80s hardware laying around waiting to be put to work, though, take a look at this project which brings new vocabulary words to that old classic Speak & Spell.

Continue reading “Classic 80s Text-To-Speech On Classic 80s Hardware”