Image

Mars Pathfinder: What Really Happened?

You’ve probably heard of Mars Pathfinder, the NASA lander and its Sojourner rover that took up residence on Mars in 1997. At first, all was well, but after a few days, the lander suffered a series of total system resets. A watchdog timer detected a problem and forced reboots. [Vivek Bhageria’s] recent post looks into what happened and the eventual solution.

The root cause was priority inversion. This happens when a lower-priority task holds a resource needed by a higher-priority task and prevents the higher-priority task from executing. In this case, the operating system was VxWorks, but this can happen on any kind of priority scheduling system.

The simplified version is that there were two tasks that each used the same mutex to avoid stepping on each other. The highest priority was a data distribution task. The lowest priority task dealt with meteorology data processing. There was also a medium-priority task that handled bus maintenance.

The failure would occur when the low-priority task had the mutex and lost its time slot before releasing it. The high-priority task would then find it couldn’t take the mutex. However, the low-priority task didn’t get control again because of the medium-priority tasks waiting to run.

In effect, the high-priority task was now waiting on something that couldn’t become available until the lowest-priority task was able to run. That’s priority inversion.

Continue reading “Mars Pathfinder: What Really Happened?” →

Image

The EDG C++ Compiler Frontend Has Been Open Sourced

Recently [John Spicer] of the EDG C++ compiler front-end project announced that the project will be made open source, from now on managed by the non-profit C++ Alliance. Related source code can be found on the GitHub account.

The Edison Design Group (EDG) is a US company which has made compiler front-ends since 1988, previously also for Java and Fortran. They are used in the Intel C++ compiler, Microsoft’s VC++, NVIDIA’s CUDA compiler, as well as many other commercial products. Last year the decision was made to shutdown the company in 2026 and transition to an open source model, with the details outlined on the EDGCPP site.

Although far from the only C++ front-end, EDGCPP will be very interesting still for supporting bleeding-edge features and having been used in such wide-ranging, demanding applications by a host of commercial customers. For most of us C++ developers our contact with it will have been via the MSVC and Intel Compiler Collection tooling, but of course it’s just one part of the entire toolset.

We’re looking forward to seeing what this means for the wider open source C++ ecosystem, especially as it pertains to GCC and LLVM’s Clang.

Image

It’s GW-BASIC, Jim, But Not As We Know It

Back in the old days the IBM-PC, like most of its contemporary computers, shipped with BASIC in ROM. Even after it stopped living in ROM, IBM-Compatibles shipped with GW-BASIC, and now we have a project that asks: what if they still did? Thoreau BASIC is GW-BASIC, but updated for the 21st century.

It’s meant to be code-compatible with all old GW-BASIC code — which means, yes, line numbers and GOTOs abound — but it can boot from a modern x86 PC’s UEFI or run under Windows and take full advantage of modern hardware with 64-bit memory and multithreading support. Graphics are 24-bit at any resolution your monitor can handle, and there are a number of handy built-in commands to handle file management, graphics — including sprites — mouse and keyboard input, 32-channel sound, and more. It is also not strictly an interpreted language. Programs can be compiled to run under Windows or bare-metal on UEFI x86 machines.

It’s not open source, but the project is “pay what you want” over on Itch.io, where you can also see a number of examples.

We’ve seen other attempts to revive BASIC over the years, like MoonBASIC or BASIC-256, but we have to admit it’s never going to be the dominant force it once was, regardless of how nostalgic we might get. That’s probably for the best, but it’s still nice to know you can boot to BASIC if you really, really want to. Do you think it would work with our preprocessor?

Image

When The Debugger Lies With Stale Cache Values

In a recent blog post by [Daniel Mangum] he goes over a scenario observed while debugging the Cortex-M33-based nRF54LM20, reading and writing values while running through a few scenarios. After initially it seemed to go seemingly without any issues, suddenly the GDB debugger would happily return values that suggested that a previous operation had not succeeded. Or, as the case turned out to be, stale cached values were being returned.

What follows is a very technical and low-level breakdown of how this MCU functions inside, especially its cryptographic features and Key Management Unit, which is used for storing sensitive information. The most amusing part is probably you can bypass the cached data by explicitly specifying the access port and memory address along with other parameters.

This ReadMemAP command supported by the JLinkGDBServer used here showed the right value, whereas the normal GDB read command using x kept returning the cached values. This raised the question of which cache was doing this. The direct read from the AHB-AP access port worked fine, so the suspicion is that the J-Link software’s own caching, with a run without the J-Link caching indeed working fine.

J-Link has had some hardware-related issues too, with this new issue pointing to an awkward software bug that could be table-flip-and-rage-quit worthy depending on how much time it wastes during a debug session. Fortunately [Daniel] seems to have caught this one quickly and had an easy way to bypass it, but we aren’t all that lucky.

 

Image

A 3D Rasterizer For Embedded Devices

Once upon a time, doing graphics on a microcontroller was challenging, to say nothing of the concept of going into three dimensions. But modern microcontrollers are far more powerful, and you might find yourself wanting to do all sorts of graphical wizardry with one. To that end, you might find Jet useful.

Created by [CubeCoders], Jet is a compact 3D rasterizer built for modern chips like the ESP32 and STM32. It’s dependency free, relatively tiny, and is written in C++17 with an eye towards working well on memory-limited platforms. It runs entirely in software, uses only integer arithmetic, and is built around 16-bit RGB565 color — intended to make it easy to use with parts like the ST7796, ILI9488, and other similar displays interfaced via SPI.

As a point of reference, on a ESP32-S3 Jet can render around 650 on-screen triangles (post-culling) at 60 frames per second on a 480×320 display, or 1300 triangles at 30 FPS. The developers note that 3D performance lands somewhere between the Sega 32X and Sega Saturn — not bad for a microcontroller you can buy for under $20. The Wipeout-like demo shows off the capabilities of Jet rather fantastically, we think.

You’d be foolish to expect your next microcontroller project to render Crysis. However, if you want some retro 3D graphics for your next ESP32-based build, you might just consider exploring what Jet can do for you.

Continue reading “A 3D Rasterizer For Embedded Devices” →

Image

Pulse: A New VHDL Simulator

With VHDL being arguably more deterministic and bullet-proof than Verilog, it’s good to see another open source VHDL simulator joining the fray that is not a variation of ghdl. Written by [Óscar Grimal] in C++ with an MIT license, the Pulse project is a still in progress package that provides the entire toolchain, from the compiler to the requisite waveform output.

This waveform output is provided in the form of a text-based user interface (TUI), which at the very least helps a lot with making it cross-platform compatible. As dependencies only a C++20 capable compiler and CMake are indicated.

Of course, with VHDL being a rather hefty language especially once you start piling up the associated standard library, the currently supported language and library features are somewhat limited still so that you’re limited to basic IEEE packages and types, with default values are not supported yet.

Per the roadmap on the GitHub project’s Readme more VHDL language features including generics and additional types will be added, along with an enhanced simulation engine. It’s also said that mixed-language support with Verilog will be added, though SystemVerilog looks to be getting the short end of the stick as usual.

It will definitely be interesting to compare this package to ghdl.

Image

Local LLMs Can Work Better Than Claude, At Least For Some

This is going to be a very personal question, because when you’re talking cloud vs local anything, it comes down to this: how much are you willing to pay for independence? The local option might save you long term, or it might never pay off the capital investment. It will almost certainly cost you your time to set up and maintain your own system — but what you get back is independence. With LLMs, traditionally you lose quite a bit of performance, but as [Anurag Singh] points out on XDA Developers, a lesser model might actually let you get more done, depending on your workflow.

[Anurag] had been on the 20$/month plan with Anthropic when he decided that the scratch just wasn’t worth the sniff– he was hitting usage limits he couldn’t stand at that level, but couldn’t justify a higher tier of access. So he decided to try a local LLM, even though all he had was a 16 GB MacBook Air M5, not a beefy workstation. Since his workflow isn’t so much ‘vibe code the whole thing for me’ as ‘help me find where I went wrong here, electronic rubber duck’, Qwen2.5 Coder 14B proved more than adequate for his use case.

It can’t understand all the moving parts of a large project as well as Claude can — not surprising given how old it is and how much memory it has to work with — but that’s [Anurag]’s job. He’s the programmer, it’s just the assistant. For his use case, he can make use of his existing hardware and having the the LLM right in VS Code is allows for a speedy workflow.

Your millage may vary, but if you want to get into locally running LLMs, we can point you at the easy ways to get started. Depending on your hardware, you might want to grab another GPU.