One of the goals of programming languages back in the 1950s was to create a way to write assembly language concepts in an abstract, high-level manner. This would allow the same code to be used across the wildly different system architectures of that era and subsequent decades, requiring only a translator unit (compiler) that would transform the source code into the machine instructions for the target architecture.
Other languages, like BASIC, would use a runtime that provided an even more abstract view of the underlying hardware, yet at the cost of a lot of performance. Although the era of 8-bit home computers is long behind us, the topic of cross-platform development is still highly relevant today, whether one talks about desktop, embedded or server development. Or all of them at the same time.
Let’s take a look at the cross-platform landscape today, shall we?
For however many Linux distributions there are to choose from, there are perhaps even more window managers that can be paired with them, and some have dramatically different features than the X window systems that most of us are familiar with. There’s a rabbit hole to fall down, as with most Linux-related topics, but while this tiling window manager from [caoluin], called sara, adds to the cacophony, it’s also representative of any pet project that lets us take a deep dive into something personally interesting.
What started as a desire to revive an abandoned window manager called catwm eventually evolved into a fork of sorts of another popular window manager called dwm. dwm is used as a basis or as building blocks for many other window managers, and while [caoluin] was writing sara he found that many of the solutions he found converged on the same things that dwm had already implemented. In a way, it’s reassuring if your solutions are similar to tried-and-true methods already in use. For other things he found interesting solutions, and other features that dwm has he found to be unnecessary and removed them.
Does the world need another window manager? Probably not. But we can all appreciate building something from scratch, just to see how it really works under the hood. As far as that goes, we’d consider sara a success for [caoluin], and if you’re really interested in window managers then you can take a look at his Github page or one of the more esoteric window managers we’ve seen.
Last year’s Hackaday Superconference badge was an electronic tour de force, packing an ECP5 FPGA shoehorned into a Game Boy-like form factor and shipping with a RISC-V core installed that together gave an almost infinite badge hacking potential. It did not however run Linux, and that’s something [Greg Davill] has addressed, as he’s not only running Linux on his badge, but also a framebuffer that allows him to use the badge screen as the Linux terminal screen. Finally you can watch Linux boot on your Superconference badge itself, rather than over its serial port.
He’s achieved this by changing essentially everything: from the new VexRiscv CPU core, to new video drivers and a VGA terminal courtesy of Frank Buss, now part of the LiteVideo project. It’s not quite a fully fledged Linux powerhouse yet, but you can find it in a GitHub repository should you have a mind to try it yourself. Paging back through his Twitter feed reveals the effort he’s put into this work over the last few months, and shows that it’s been no easy task.
For those keeping score at home, this is an open hardware design, running an open CPU core, with community-designed open-source peripherals, compiled by an open-source toolchain, running an open-source operating system. And it’s simply a fantastic demo for the badge, showing off how flexible the entire system is. One of the best parts of writing for Hackaday is that our community is capable of a huge breadth of amazing pieces of work, and this is an exemplar of that energy. We can’t wait to see what Greg and any other readers tempted to try it will come up with.
An ideal application for mesh networking is off-grid communication; when there’s no cellular reception and WiFi won’t reach, wide-area technologies like LoRa can be used to create ad hoc wireless networks. Whether you’re enjoying the outdoors with friends or conducting a rescue operation, a cheap and small gadget that will allow you to create such a network and communicate over it would be a very welcome addition to your pack.
That’s exactly the goal of the Meshtastic project, which aims to take off-the-shelf ESP32 LoRa development boards and turn them into affordable mesh network communicators. All you need to do is buy one of the supported boards, install the firmware, and starting meshing. An Android application that will allow you to use the mesh network to send basic text messages is now available as an alpha release, and eventually you’ll be able to run Signal over the LoRa link.
Navigating to another node in the network.
Developer [Kevin Hester] tells us that these are still the very early days, and there’s plenty of work yet to be done. In fact, he’s actively looking to bring a few like-minded individuals onto the project. So if you have experience with the ESP32 or mobile application development, and conducting private communications over long-range wireless networks sounds like your kind of party, this might be your lucky day.
From a user’s perspective, this project is extremely approachable. You don’t need to put any custom hardware together, outside of perhaps 3D printing a case for your particular board. The first time around you’ll need to flash the firmware with esptool.py, but after that, [Kevin] says future updates can be handled by the smartphone application.
Incidentally, the primary difference between the two boards is that the larger and more expensive one includes GPS. The mesh networking side of things will work with either board, but if everyone in your group has the GPS-equipped version, each user will be able to see the position of everyone else in the network.
If you’ve got a desktop 3D printer, there’s an excellent chance you’ve heard of OctoPrint. This web front-end, usually running on a Raspberry Pi, allows you to monitor and control the printer over the network from any device that has a browser. But what if you’ve got two printers? Or 20? The logistics of each printer getting its own Pi can get uncomfortable in a hurry, which is why [Jay Doscher] has been working on a way to simplify things.
Leveraging the boosted processing power of the Raspberry Pi 4 and some good old fashioned Linux trickery, [Jay] is now controlling multiple printers from a single device. The trick is to run multiple instances of the OctoPrint backend and assign them to virtual network interfaces so they don’t interfere with each other. This takes some custom systemd unit files to get up and running on Raspbian, which he’s been kind enough to include them in the write-up.
But getting multiple copies of OctoPrint running on the Pi is only half the battle. There still needs to be a way to sort out which printer is which. Under normal circumstances, the printers would be assigned random virtual serial ports when the Pi booted. To prevent any confusion, [Jay] explains how you can use custom udev rules to make sure that each printer gets its own unique device node. Even if you aren’t trying to wrangle multiple 3D printers, this is a useful trick should you find yourself struggling to keep track of your USB gadgets.
If you’re wondering why [Jay] needs to have so many 3D printers going at the same time, we hear they’ve been keeping rather busy running off parts for commissioned copies of his popular projects. Something to consider the next time you’re wondering if there’s a way to make a happy buck out of this little hobby of ours, folks.
It’s an unwritten rule that all proper pieces of shop equipment need a nameplate. Otherwise, how are you going to know what name to use when you curse it under your breath? In the old days these would have been made out of something fancy such as brass, but for the modern hacker that doesn’t stand on tradition, you can now easily outfit all your gear with custom 3D printed nameplates using this online tool.
Granted, it wouldn’t be very difficult to throw one of these together in whatever CAD package you happen to have access to. But with the tool [Tobias Weber] has developed, you don’t have to. Simply pick the font, the shape of the border, and fill in a few variables to fine tune things such as padding and base thickness.
Finally, enter your text and marvel at the real-time 3D preview that’s rendered thanks to the magic of modern web technologies. In seconds, you’ll have an STL file that’s ready for the warm liquid goo phase.
The huge collection of fonts are a particularly nice touch, ranging from delicate scripts to military style stencils. Depending on your CAD software, getting arbitrary fonts imported and extruded into a three dimensional shape can be tricky for new players. If we do have one complaint though, it’s that there doesn’t seem to be a clear indicator of how big the nameplate is going to be when exported. First time around, it spit out an STL that would have been 300 mm long if we hadn’t scaled it down in the slicer.
This project is very reminiscent of another web-based tool we featured recently. That one allowed you to make 3D printed QR codes which would whatever entomb in plastic whatever data your cold hacker heart desired.
For most people, a software defined radio is a device. An RTL-SDR dongle perhaps, or the HackRF that a popular multi-tool for working in the radio frequency realm. But as they explain, the SDR hardware can be considered merely as the analogue front end, being just the minimal analogue circuitry coupled with a digitiser. The real software-defined part comes — as you might expect — in the software
Kate and Mike introduce GNU Radio Companion — the graphical UI for GNU Radio — as their tool of choice and praise it’s use as a general purpose digital signal processing system whether or not that includes radio. Taking their own Great Scott Gadgets GreatFET One USB hackers toolkit peripheral as an input device they demonstrate this by analysing the output from a light sensor. Instantly they can analyse the mains frequency in a frequency-domain plot, and the pulse frequency of the LEDs. But their bag of tricks goes much deeper, exploring multiple “atypical use cases” that unlock a whole new world through creative digital signal processing (DSP).