Benchmarking Latency Across Common Wireless Links For MCUs

February 11, 2024 by Maya Posch 13 Comments

Although factors like bandwidth, power usage, and the number of (kilo)meters reach are important considerations with wireless communication for microcontrollers, latency should be another important factor to pay attention to. This is especially true for projects like controllers where round-trip latency and instant response to an input are essential, but where do you find the latency number in datasheets? This is where [Michael Orenstein] and [Scott] over at Electric UI found a lack of data, especially when taking software stacks into account. In other words, it was time to do some serious benchmarking.

The question to be answered here was specifically how fast a one-way wireless user interaction can be across three levels of payload sizes (12, 128, and 1024 bytes). The effective latency is measured from when the input is provided on the transmitter, and the receiver has processed it and triggered the relevant output pin. The internal latency was also measured by having a range of framework implementations respond to an external interrupt and drive a GPIO pin high. Even this test on an STM32F429 MCU already showed that, for example, the STM32 low-level (LL) framework is much faster than the stm32duino one.

Continue reading “Benchmarking Latency Across Common Wireless Links For MCUs” →

The Usage Of Embedded Linux In Spacecraft

February 10, 2024 by Maya Posch 44 Comments

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More

February 9, 2024 by Maya Posch 17 Comments

The memory map of the original 8086 computer with its base and extended memory made the original PC rather straightforward, but also posed countless issues for DOS-based applications as they tried to make use of memory beyond the legacy 1 MB address space. The initial ways to deal with this like EMS, XMS and UMB were rather cumbersome and often impractical, but with the arrival of the 80286 and 80386 processors more options opened up, including protected mode. More interestingly, this led to unreal mode, DOS extenders and the somewhat more obscure LOADALL instruction, as covered by [Julio Merino] in a new article.

This article builds on the first one which covered the older methods and covered the basics of protected mode. Where protected mode is convenient compared to real mode is that with the former the memory accesses go via the MMU and thus allows for access to 16 MB on the 80286 and 4 GB on the 80386. The segment descriptors and resolving of these that make this possible can be (ab)used on the 80286 and up by realizing that these segment descriptors are also used in real mode. Unreal mode is thus about switching to protected mode, loading arbitrary segment descriptors and switching back to real mode. As this is outside the original processor spec, it is commonly called ‘unreal mode’.

Continue reading “Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More” →

Ask Hackaday: What About Imperfect Features?

January 24, 2024 by Arya Voronova 24 Comments

Throughout the last few years’ time, I’ve been seeing sparks of an eternal discussion here and there. It’s a nuanced one, but if I could summarize, it’s about different feature development strategies we can follow to design things, especially if they’re aimed at a larger market. Specifically – when adding a feature, how complete and perfect should it be?

A while back, I read a Mastodon thread about VLC not implementing backwards per-frame skipping. At the surface level, it’s about an indignant user asking – what’s the deal with VLC not having a “go back a frame” button? A ton of video players have this feature implemented. There’s a forum thread linked, and, reading it could leave you with a good few conflicting emotions. Here’s a recap.

In what appears to be one of multiple threads asking about a ‘previous frame’ button in VLC, there’s an 82-post discussion involving multiple different VLC developers. The users’ argument is that it appears to be clearly technically possible to add a ‘previous frame’ button in practice, and the developers’ argument is that it’s technologically complex to implement in some cases – for certain formats, even impossible to implement! Let’s go into the developers’ stated reasoning in more details, then – here’s what you can find in the thread, to the best of my ability.

Continue reading “Ask Hackaday: What About Imperfect Features?” →

Testing Your C Knowledge With This One Simple Quiz

January 23, 2024 by Maya Posch 53 Comments

One of the most exciting aspects of the C programming language — as effectively high-level assembly — is that although it’s a bit friendlier for the developer, it also adds a lot of required know-how on account of its portability across platforms and architectures. This know-how is what [Oleksandr Kaleniuk] manages to wonderfully illustrate with a simple 5-question, multiple-choice quiz on what the return value is of the provided function snippets of C code. How well do you know C?

For those who have had their run-ins with C directly (or indirectly via the support for it in languages like C++) the words ‘undefined behavior‘ (UB) are likely to induce a nervous twitch or two, along with a suspicious glance at whichever parts of reality are about to evaporate and destabilize the Universe this time. Although it is said that a proper C program is written with zero UB cases in it, in practice this can be rather tough, even before considering the other exciting ways in which a piece of code can fail to do the expected thing.

For languages other than C this is of course also a challenge, which is the reason why certification programs for e.g. avionics go out of their way to weed out such preventable issues, and only few programming languages like Ada (anything avionics, medical, etc.) and C++ (F-35 and other US DoD projects) make it into devices where failure is literally not an option.

How A Steam Bug Once Deleted All Of Someone’s User Data

January 20, 2024 by Maya Posch 14 Comments

In a retrospective, [Kevin Fang] takes us back to 2015, when on the Steam for Linux issue tracker [keyvin] opened an issue to report that starting the Steam client after moving the Steam folder had just wiped all of his user data, including his backup drive mounted under /media. According to [keyvin], he moved the standard ~/.local/share/steam to a drive mounted under /media and symlinked ~/.local/share/steam to this new location on the external drive. He then tried starting Steam, which failed, before Steam crashed and tried reinstalling itself. That’s when [keyvin] realized that Steam had apparently recursively deleted everything owned by his user from the root folder.

The infamous Valve code that made Linux users sad.

In the issue thread, user [doofy] got hit by the same bug when trying to directly start the ~/.local/share/steam/steam.sh script with debugging enabled. He then was the first to point out the rm -rf in that steam.sh script, but since this particular line is in a function only called when Steam tries to remove and reinstall itself to ‘fix’ a botched start, how did this happen? Ultimately it seems to be because of the STEAMROOT variable being set to an empty string, and another unset variable triggering the reset_steam() function, leading to the demise of all the user data.

Since then Valve has presumably fixed the issue, as no further users have filed tickets, but it’s concerning that a similar issue seems to still exist on Windows. Whether or not the original Linux issue has been fixed, it shows clearly how one should always check return values and perhaps, just maybe, never do an automated rm -rf or equivalent.

Continue reading “How A Steam Bug Once Deleted All Of Someone’s User Data” →

Open Source Needs A New Mission: Protecting Users

January 10, 2024 by Donald Papp 43 Comments

[Bruce Perens] isn’t very happy with the current state of Free and Open Source Software (FOSS), and an article by [Rupert Goodwins] expounds on this to explain Open Source’s need for a new mission in 2024, and beyond. He suggests a focus shift from software, to data.

The internet as we know it and all the services it runs are built on FOSS architecture and infrastructure. None of the big tech companies would be where they are without FOSS, and certainly none could do without it. But FOSS has its share of what can be thought of as loopholes, and in the years during which the internet has exploded in growth and use, large tech companies have found and exploited all of them. A product doesn’t need to disclose a single line of source code if it’s never actually distributed. And Red Hat (which [Perens] asserts is really just IBM) have simply stopped releasing public distributions of CentOS.

In addition, the inherent weak points of FOSS remain largely the same. These include funding distributions, lack of user-focused design, and the fact that users frankly don’t understand what FOSS offers them, why it’s important, or even that it exists at all.

A change is needed, and it’s suggested that the time has come to move away from a focus on software, and shift that focus instead to data. Expand the inherent transparency of FOSS to ensure that people have control and visibility of their own data.

While the ideals of FOSS remain relevant, this isn’t the first time the changing tech landscape has raised questions about how things are done, like the intersection of bug bounties and FOSS.

What do you think? Let us know in the comments.