A UI-Focused Display Library For The ESP32

If you’re building a project on your ESP32, you might want to give it a fancy graphical interface. If so, you might find a display library from [dejwk] to be particularly useful.

Named roo_display for unclear reasons, the library is Arduino-compatible, and suits a wide range of ESP32 boards out in the wild. It’s intended for use with common SPI-attached display controllers, like the ILI9341, SSD1327, ST7789, and more. It’s performance-oriented, without skimping on feature set. It’s got all kinds of fonts in different weights and sizes, and a tool for importing more. It can do all kinds of shapes if you want to manually draw your UI elements, or you can simply have it display JPEGs, PNGs, or raw image data from PROGMEM if you so desire. If you’re hoping to create a touch interface, it can handle that too. There’s even a companion library for doing more complex work under the name roo_windows.

If you’re looking to create a simple and responsive interface, this might be the library for you. Of course, there are others out there too, like the Adafruit GFX library which we’ve featured before. You could even go full VGA if you wanted, and end up with something that looks straight out of Windows 3.1. Meanwhile, if you’re cooking up your own graphics code for the popular microcontroller platform, you should probably let us know on the tipsline!

Thanks to [Daniel] for the tip!

NPAPI And The Hot-Pluggable World Wide Web

In today’s Chromed-up world it can be hard to remember an era where browsers could be extended with not just extensions, but also with plugins. Although for those of us who use traditional Netscape-based browsers like Pale Moon the use of plugins has never gone away, for the rest of the WWW’s users their choice has been limited to increasingly more restrictive browser extensions, with Google’s Manifest V3 taking the cake.

Although most browsers stopped supporting plugins due to “security concerns”, this did nothing to address the need for executing code in the browser faster than the sedate snail’s pace possible with JavaScript, or the convenience of not having to port native code to JavaScript in the first place. This led to various approaches that ultimately have culminated in the WebAssembly (WASM) standard, which comes with its own set of issues and security criticisms.

Other than Netscape’s Plugin API (NPAPI) being great for making even 1990s browsers ready for 2026, there are also very practical reasons why WASM and JavaScript-based approaches simply cannot do certain basic things.

Continue reading “NPAPI And The Hot-Pluggable World Wide Web”

Detail of Horus's face, from a statue of Horus and Set placing the crown of Upper Egypt on the head of Ramesses III. Twentieth Dynasty, early 12th century BC.

HORUS Framework: A Rust Robotics Library

[neos-builder] wrote in to let us know about their innovation: the HORUS Framework — Hybrid Optimized Robotics Unified System — a production-grade robotics framework built in Rust for real-time performance and memory safety.

This is a batteries included system which aims to have everything you might need available out of the box. [neos-builder] said their vision is to create a robotics framework that is “thick” as a whole (we can’t avoid this as the tools, drivers, etc. make it impossible to be slim and fit everyone’s needs), but modular by choice.

[neos-builder] goes on to say that HORUS aims to provide developers an interface where they can focus on writing algorithms and logic, not on setting up their environments and solving configuration issues and resolving DLL hell. With HORUS instead of writing one monolithic program, you build independent nodes, connected by topics, which are run by a scheduler. If you’d like to know more the documentation is extensive.

The list of features is far too long for us to repeat here, but one cool feature in addition to the real-time performance and modular design that jumped out at us was this system’s ability to process six million messages per second, sustained. That’s a lot of messages! Another neat feature is the system’s ability to “freeze” the environment, thereby assuring everyone on the team is using the same version of included components, no more “but it works on my machine!” And we should probably let you know that Python integration is a feature, connected by shared-memory inter-process communication (IPC).

If you’re interested in robotics and/or real-time systems you should definitely be aware of HORUS. Thanks to [neos-builder] for writing in about it. If you’re interested in real-time systems you might like to read Real-Time BART In A Box Smaller Than Your Coffee Mug and Real-Time Beamforming With Software-Defined Radio.

Two threads running concurrently

The Staggering Complexity And Subtlety Of Concurrency

If you’re gonna be a hacker eventually you’re gonna have to write code. And if you write code eventually you’re gonna have to deal with concurrency. Concurrency is what we call it when parts of our program run at the same time. That could be because of something fairly straightforward, like multiple threads, or multiple processes; or something a little more complicated such as event loops, asynchronous or non-blocking I/O, interrupts and signal handlers, re-entrancy, co-routines / fibers / green threads, job queues, DMA and hardware level concurrency, speculative or out-of-order execution at CPU-level, time-sharing on single-core systems, or parallel execution on multi-core systems. There are just so many ways to get tied up with concurrency.

In this video from [Core Dumped] we learn about The ’80s Algorithm to Avoid Race Conditions (and Why It Failed). This video explains what a race condition looks like and talks through what the critical section is and approaches to protecting it. This video introduces an old approach to protect the critical section first invented in 1981 known as Peterson’s solution, but then goes on to explain how Peterson’s solution is no longer reliable as much has changed since the 1980s, particularly compilers will reorganize instructions and CPUs may run code out of order. So there is no free lunch and if you have to deal with concurrency you’re going to want some kind of support for a mutex of some type. Your programming language and its standard library probably have various types of locks available and if not you can use something like flock (also available as a syscall, to complement the POSIX fcntl), which may be available on your platform.

If you’re interested in contemporary takes on concurrency you might like to read Amiga, Interrupted: A Fresh Take On Amiga OS or The Linux Scheduler And How It Handles More Cores.

Continue reading “The Staggering Complexity And Subtlety Of Concurrency”

GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request

Recently GitHub disabled the Rockchip Linux MPP repository, following a DMCA takedown request from the FFmpeg team. As of writing the affected repository remains unavailable. At the core of this issue is the Rockchip MPP framework, which provides hardware-accelerated video operations on Rockchip SoCs. Much of the code for this was lifted verbatim from FFmpeg, with the allegation being that this occurred with the removal of the original copyright notices and authors. The Rockchip MPP framework was further re-licensed from LGPL 2.1 to the Apache license.

Most egregious of all is perhaps that the FFmpeg team privately contacted Rockchip about this nearly two years ago, with clearly no action taken since. Thus FFmpeg demands that Rockchip either undoes these actions that violate the LGPL, or remove all infringing files.

This news and further context is also covered by [Brodie Robertson] in a video. What’s interesting is that Rockchip in public communications and in GitHub issues are clearly aware of this license issue, but seem to defer dealing with it until some undefined point in the future. Clearly that was the wrong choice by Rockchip, though it remains a major question what will happen next. [Brodie] speculates that Rockchip will keep ignoring the issue, but is hopeful that he’ll be proven wrong.

Unfortunately, these sort of long-standing license violations aren’t uncommon in the open source world.

Continue reading “GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request”

It’s Time To Make A Major Change To D-Bus On Linux

Although flying well under the radar of the average Linux user, D-Bus has been an integral part of Linux distributions for nearly two decades and counting. Rather than using faster point-to-point interprocess communication via a Unix socket or such, an IPC bus allows for IP communication in a bus-like manner for convenience reasons. D-Bus replaced a few existing IPC buses in the Gnome and KDE desktop environments and became since that time the de-facto standard. Which isn’t to say that D-Bus is well-designed or devoid of flaws, hence attracting the ire of people like [Vaxry] who recently wrote an article on why D-Bus should die and proposes using hyprwire instead.

The broader context is provided by [Brodie Robertson], whose video adds interesting details, such as that Arch Linux wrote its own D-Bus implementation rather than use the reference one. Then there’s CVE-2018-19358 pertaining to the security risk of using an unlocked keyring on D-Bus, as any application on said bus can read the contents. The response by the Gnome developers responsible for D-Bus was very Wayland-like in that they dismissed the CVE as ‘works as designed’.

One reason why the proposed hyperwire/hyprtavern IPC bus would be better is on account of having actual security permissions, real validation of messages and purportedly also solid documentation. Even after nearly twenty years the documentation for D-Bus consists mostly out of poorly documented code, lots of TODOs in ‘documentation’ files along with unfinished drafts. Although [Vaxry] isn’t expecting this hyprwire alternative to be picked up any time soon, it’s hoped that it’ll at least make some kind of improvement possible, rather than Linux limping on with D-Bus for another few decades.

Continue reading “It’s Time To Make A Major Change To D-Bus On Linux”

Xcc700: Self-Hosted C Compiler For The ESP32/Xtensa

With two cores at 240 MHz and about 8.5 MB of non-banked RAM if you’re using the right ESP32-S3 version, this MCU seems at least in terms of specifications to be quite the mini PC. Obviously this means that it should be capable of self-hosting its compiler, which is exactly what [Valentyn Danylchuk] did with the xcc700 C compiler project.

Targeting the Xtensa Lx7 ISA of the ESP32-S3, this is a minimal C compiler that outputs relocatable ELF binaries. These binaries can subsequently be run with for example the ESP-IDF-based elf_loader component. Obviously, this is best done on an ESP32 platform that has PSRAM, unless your binary fits within the few hundred kB that’s left after all the housekeeping and communication stacks are loaded.

The xcc700 compiler is currently very minimalistic, omitting more complex loop types as well as long and floating point types, for starters. There’s no optimization of the final code either, but considering that it’s 700 lines of code just for a PoC, there seems to be still plenty of room for improvement.