LabVIEW Abandons Mac After Four Decades

October 15, 2023 by Maya Posch 52 Comments

When National Instruments (NI) released LabVIEW in 1986 it only targeted the Macintosh, with ports to other platforms coming later on in the 1990s. Now, NI has announced that with the next version in 2024, LabVIEW will only be released for Linux and Windows, leaving behind Apple’s software platform after nearly four decades. The news was covered by Apple Insider, which cites a forum thread on the NI website in which the details of LabVIEW for macOS are discussed. This news comes on the heels of the announcement of Valve dropping macOS support with Counter Strike 2.

In both cases the issue at hand appears to be both a combination of a low user count (less than 1% of CS:GO players) and the complexity of using proprietary APIs (Cocoa, Metal, etc.) that have led to the decision to terminate the macOS releases. Not that macOS users aren’t used to app-related bloodbaths after losing all 32-bit applications back in 2019, but the trend of more high-profile applications and games not supporting the OS does seem to be ramping up.

Perhaps the only positive news here for people who bought into the Apple hardware ecosystem here is that Windows runs on M1/M2 Macs, and there is even an experimental Linux distribution in the form of Asahi Linux to conceivably dual-boot into for those applications that just don’t want to run on Apple’s OS.

Close To The Metal

October 14, 2023 by Elliot Williams 81 Comments

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

Debian Bookworm Comes To The Raspberry Pi, And Wayland Is Now Default

October 13, 2023 by Jenny List 48 Comments

It must have been a busy week for the PR department at Raspberry Pi, with the launch of their latest single-board computer, the Pi 5. Alongside the new board comes something else, an updated Raspberry Pi OS version.

This is built from Debian 12 “Bookworm”, and supplants the previous “Bullseye” version. As well as the new OS base it comes with a pile of Pi-specific upgrades including an optimsied version of Mozilla Firefox. Probably most important is that henceforth (at least on 64-bit boards) its desktop will use the Wayland compositor rather than X11 to draw and manipulate windows. This is a development that has been in the works for a very long time — it must be almost a decade since the first Raspberry Pi blog entry about Wayland — so it’s welcome at last to see it.

The new tweaks as well as Wayland are supposed to deliver a much faster Pi experience, so we thought we’d break out the stopwatch and do some rough real-world tests. The bench 8GB Pi 4 here has a vanilla 64-bit Bullseye installed, so off we went to measure boot time, Chromium browser opening time, and Hackaday load time. It was time to download the new 64-bit Bookworm image and do the same. Have we just downloaded a power-up?

Both tests were done with an everyday boot, after the first-time OS set-up, and with all browser caches emptied. First up was a significant boost, with Bookworm booting in 37.14 seconds to Bullseye’s 53.5, but the Chromium opening was a little more disappointing. On Bullseye it took 7.15s, while Bookworm’s Chromium managed a more pedestrian 9.13s. The new Firefox takes only 7.95s to open. Both Chromium browsers load Hackaday in about 1.8s, while the new Firefox did the same job in a shade over 3s.

So allowing for our stopwatch reaction time and the ad-hoc nature of the test, this is a faster-booting OS, but the underlying hardware is still the limiting factor. We’re disappointed to see that there’s no update for the x86 version of the Raspberry Pi Desktop, and we hope they’ll be able to rectify this in the future.

Decoding The 8088

October 9, 2023 by Al Williams 2 Comments

There is a lot to like about open software, and in some areas, a well-thought-out piece of software can really make a huge impact. A great example of this is the Sigrok project. Creating simple devices that act like a logic analyzer is relatively easy. What’s hard is writing nice software for such a setup including protocol decoders. Sigrok has done it and since it is open, you can add your device and decode your protocol. [GloriousCow] had done the hardware part of interfacing to the 8088 in an IBM PC using an off-the-shelf logic analyzer that uses a customized version of Sigrok. But the output was a CSV file you had to process in a spreadsheet program. The next step: write a decoder for Sigrok to understand 8088 bus cycles.

The post covers the details of writing such a plug-in for Pulseview, the Sigrok GUI. It will also work for the command line interface if you prefer that. The code is in Python.

Continue reading “Decoding The 8088” →

At Last! Faster OpenSCAD Rendering Is On The Horizon

October 3, 2023 by Jenny List 30 Comments

Known as “The Programmers Solid 3D CAD Modeller”, OpenSCAD is used by many people for whom writing code comes more naturally than learning a fiddly user interface. It’s a very capable piece of software, but regular users will tell you that it can be rather slow when it comes to rendering your work. We’re very pleased to see that a fix for this has been produced courtesy of [@ochafik], can now be found as an experimental feature in nightly builds, and will in due course no doubt find its way to official releases.

Despite a modern computer invariably having a multi-core architecture, it might surprise you to find that OpenSCAD wasn’t able to take advantage of this previously. The above-linked thread spans over a decade of experimenting and contains some fascinating discussions if you’re prepared to wade through it, and culminates a few weeks ago in the announcement of the new feature giving access to multiple CPUs. We don’t have it yet, but it’s great to know it’s in the works and we’re looking forward to render time involving considerably less of a wait.

So many OpenSCAD projects have passed through these pages over the years, it’s safe to say that it has a significant user base among Hackaday readers. It’s still something an AI hasn’t mastered yet though.

Thanks [pca006132] for the tip.

RP2040 picture on left by Phiarc, CC BY-SA 4.0, via Wikimedia

Kaluma Puts JavaScript On The RP2040

October 1, 2023 by Donald Papp 38 Comments

With a simple firmware update, Kaluma puts a lightweight JavaScript runtime on the Raspberry Pi Pico (which uses the RP2040 microcontroller), providing handy modules for file systems, graphics, networking, and more. Code for a simple LED blink can then look like:

// index.js
const led = 25;
pinMode(led, OUTPUT);
setInterval(() => {
digitalToggle(led);
}, 1000);

Development can then be done using tools that are very familiar to JavaScript developers, such as npm and flashing new code to a USB-connected Pico with the (Node.js-based) Kaluma command-line interface. Take a look at the GitHub repository for the project, or browse some of the projects made with Kaluma.

Much like with MicroPython, there’s value to be had in putting implementations of high-level languages on microcontrollers. Each new language opens embedded programming to a whole new group of coders. But it’s not just languages making their way to the RP2040. Wonderful projects such as emulating the ZX Spectrum on an RP2040 also happen.

Thanks to [Shri Hari Ram] for the tip!

Turing Complete Programming On ARM With Two Instructions

September 29, 2023 by Maya Posch 14 Comments

There are many questions that can be asked for software projects, with most of these questions starting with ‘Why…?’. This is true for the challenge of proving that cascading stylesheets are Turing-complete, or that you don’t need all those fancy ISA bits of an ARM processors when you already got the LDM and STM commands in the 32-bit ISA. What originally started off as a bit of a running gag in a group of developers led to [Kellan Clark] implementing a Turing-complete computer and a functioning interpreter using nothing but these two opcodes.

Adding some Brainfsck to your ARM, inside your GBA. — Adding some Brainf**k to your ARM, inside your GBA.

These two opcodes essentially allow the storing or reading of data into memory from any combination of the 16 general-purpose registers (GPRs). This makes them both extremely versatile and also extremely open to ‘abuse’ like in this example. For a straightforward implementation that could prove the concept, [Kellan] decided to pick one of everyone’s favorite esoteric programming languages: Brainf**k, creating the charmingly titled Armf**k that allows anyone to write BF programs for any suitable ARM processor, like the ARM7TDMI in the Game Boy Advance that [Kellan] targeted.

As a proof of concept it’s unquestioningly intriguing, and a great example of how the most powerful parts of any ISA are those that move data around. After all, as anyone who writes ASM and C knows, computers are just machines that can copy bytes around really fast to make stuff happen. Mind-blowing examples like these serve to illustrate that point quite well.

Tip kindly provided by [eeucalyptus].