The End Of BLHeli_32: Long Live AM32?

June 7, 2024 by Maya Posch 11 Comments

An essential part of drones are the Electronic Speed Controller (ESC) which translate the commands from the flight computer into responses by the connected brushless motors (generally BLDCs). As the ESC determines a lot of the performance characteristics of a drone, it has its own firmware, which for (FPV) drones is overwhelmingly BLHeli, specifically the 32-bit version (BLHeli_32). Now the Norwegian company (BLHeli AS) behind this closed source firmware has thrown in the towel, citing illegal use of its firmware by sanctioned countries like Russia for purposes like warfare. This news and its implications are covered in detail in a video by the [Mads Tech] YouTube channel, including the message sent to customers by the company’s lawyer.

So far the GitHub repository is still online, featuring binary images for BLHeli_32, as well as the open source BLHeli (8-bit Atmel/Silabs) firmware and BLHeli_S (multirotor 8-bit Silabs) firmware. Due to the open source nature of these earlier projects forks already exist, such as BlueJay for BLHeli_S, and with the AM32 project there is an open source 32-bit ESC alternative. For 8-bit platforms it would thus seem that even with BLHeli_32 vanishing there is no impact at all, while for 32-bit platforms AM32 seems to be largely a drop-in solution.

Regardless of the reasons behind BLHeli_32 vanishing like this, the community and businesses can now hopefully move their (financial) support over to the AM32 project, making this more of a blip than an outright disaster for those who are into their high-end multicopter drones.

Thanks to [Frank Zhao] for the tip.

Continue reading “The End Of BLHeli_32: Long Live AM32?” →

Make Your Code Slower With Multithreading

June 7, 2024 by Dave Rowntree 51 Comments

With the performance of modern CPU cores plateauing recently, the main performance gains are with multiple cores and multithreaded applications. Typically, a fast GPU is only so mind-bogglingly quick because thousands of cores operate in parallel on the same set of tasks. So, it would seem prudent for our applications to try to code in a multithreaded fashion to take advantage of this parallelism. Or so it would seem, but as [Marc Brooker] illustrates, it’s not as simple as one would assume, and it’s very easy to end up with far worse overall performance and no easy way to fix it.

[Marc] was rerunning an old experiment to calculate the expected number of birthdays in a shared group of people using brute force. The experiment was essentially a tight loop running a pseudorandom number generator, the standard libc rand() function. [Marc] profiled the code for single-thread and multithreaded versions and noted the runtime dramatically increased beyond two threads. Something fishy was going on. Running perf, [Marc] noted that there were significant L1 cache misses, but the real killer for performance was the increase in expensive context switches. Perf indicated that for four threads, the was an overhead of nearly 50% servicing spin locks. There were no locks in the code, so after more perf magic, the syscalls taking all the time were identified. Something in there was using a futex (or fast userspace mutex) a whole lot.

Continue reading “Make Your Code Slower With Multithreading” →

The MXM card with the 3dfx chip in the center, black silkscreen, mounted on the MXM to PCIe adapter, green silkscreen

An MXM Take On The 3dfx Voodoo

June 7, 2024 by Arya Voronova 9 Comments

[sdz] of Vogons forum brings us an unexpected device for the 21st century – a 3dfx Voodoo 4 card in MXM format, equipped with 64MB of RAM. This isn’t just a showpiece – this card actually, properly works when installed into our hacker’s Dell Precision M4800, and [sdz] tells us more on how the card came to be.

Equipped with a VSA-100 GPU, this card has a whole lot of support components for adapting old interfaces to modern ones. There’s a PCIe-PCI bridge IC, an FPGA, HDMI muxes, and a Realtek scaler for video conversion. Handling all the MXM interfaces would’ve been downright impossible, so the card also holds an LVDS header for the M4800’s panel. Plus, for testing all of it, [sdz] has developed a PCIe to MXM adapter board with minimal circuitry needed to have the card work – this is a seriously involved hack and it’s executed remarkably well.

The forum post shows a whole lot of the journey, from receiving the PCBs to code and FPGA gateware bringup, as well as videos of VGA and HDMI operation. In the end, our hacker shows us a fully working setup, the 3dfx card inserted into M4800 and driving its display, as well as overclocking experiments; the author has promised to open-source the card files in due time, too. It’s seriously nice to see DIY MXM cards in the wild, and if you ever wanted to build one, we’ve got an article tells you everything you could want to know about the MXM standard.

We thank [Misel] for sharing this with us!

Continue reading “An MXM Take On The 3dfx Voodoo” →

Reverse Engineering Keeps Early Ford EVs Rolling

June 7, 2024 by Dan Maloney 5 Comments

With all the EV hype in the air, you’d be forgiven for thinking electric vehicles are something new. But of course, EVs go way, way back, to the early 19th century by some reckonings. More recently but still pretty old-school were Ford’s Think line of NEVs, or neighborhood electric vehicles. These were commercially available in the early 2000s, and something like 7,200 of the slightly souped-up golf carts made it into retirement communities and gated neighborhoods.

But as Think aficionado [Hagan Walker] relates, the Achille’s heel of these quirky EVs was its instrument cluster, which had a nasty habit of going bad and taking the whole vehicle down with it, sometimes in flames. So he undertook the effort of completely reverse engineering the original cluster, with the goal of building a plug-in replacement.

The reverse engineering effort itself is pretty interesting, and worth a watch. The microcontroller seems to be the primary point of failure on the cluster, probably getting fried by some stray transients. Luckily, the microcontroller is still available, and swapping it out is pretty easy thanks to chunky early-2000s SMD components. Programming the MCU, however, is a little tricky. [Hagan] extracted the code from a working cluster and created a hex file, making it easy to flash the new MCU. He has a bunch of other videos, too, covering everything from basic diagnostics to lithium battery swaps for the original golf cart batteries that powered the vehicle.

True, there weren’t many of these EVs made, and fewer still are on the road today. But they’re not without their charm, and keeping the ones that are still around from becoming lawn ornaments — or worse — seems like a noble effort.

Continue reading “Reverse Engineering Keeps Early Ford EVs Rolling” →

The IBM PC: Brainchild Of A Misfit

June 7, 2024 by Al Williams 27 Comments

We’ve read a number of histories of the IBM PC and lived through that time, too. But we enjoyed [Gareth Edwards’] perspective in a post entitled The Misfit who Built the IBM PC. The titular character is Don Estridge, a decidedly atypical IBM employee who was instrumental in creating the personal computer market as we know it.

It’s not that IBM invented the personal computer — far from it. But the birth of the PC brought personal computers to the mainstream, especially in offices, and — much to IBM’s chagrin — opened up the market for people to make add-on cards for printers, videos, and other accessories.

IBM was a computer juggernaut in the late 1970s. Its divisions were the size of other companies, and some have compared it to a collection of mafia families. The company was heavily invested in big computers, and management was convinced that personal computing was, at most, an avenue to video games and most likely a fad.

Known as a conservative company, the PC project drew from a number of corporate misfits who had been technically successful but often punished for coloring outside the lines. They developed a prototype. The post quotes one of the people involved as saying, “The system would do two things. It would draw an absolutely beautiful picture of a nude lady, and it would show a picture of a rocket ship blasting off the screen. We decided to show the Management Committee the rocket ship.” Wise choice.

That’s just the kind of tidbit in this post, and if you have any interest in computer history of the 1980s, you’ll definitely want to check it out. Estridge died in 1985, so he didn’t get to see much of the result of the market he opened up. Of course, there were many other players who appear in this story. The PC has many parents, as you might expect.

We’ve done our own recounting of this story. However, we tend to obsess more over the internals.

Hackaday Podcast Episode 274: Capstan Robots, Avionics Of Uncertain Purpose, And What The Frack?

June 7, 2024 by Al Williams No comments

What do capstans, direct conversion receivers, and fracking have in common? They were all topics Hackaday editors Elliot Williams and Al Williams found fascinating this week. If you wonder what makes an electrical ground a ground, or what a theodolite is, you should check it out.

This week, the hacks came fast and furious. Capstans, instead of gears, work well for 3D-printed mechanisms, a PI Pico can directly receive radio signals, and the guys saw a number of teardowns and reverse engineering triumphs. You’ll also find solid-state heat pumps, flying wings, spectroscopy, and more.

The can’t miss articles this week? Learn about theodolites, a surveying feat from ancient Greece, and how fracking works.

Check out the links below if you want to follow along, and as always, tell us what we’ve mispronounced — or any other thoughts on the episode — in the comments!

Download an archival copy for your personal collection.

Continue reading “Hackaday Podcast Episode 274: Capstan Robots, Avionics Of Uncertain Purpose, And What The Frack?” →

Comparing X86 And 68000 In An FPGA

June 7, 2024 by Dave Rowntree 15 Comments

[Michael Kohn] started programming on the Motorola 68000 architecture and then, for work reasons, moved over to the Intel x86 and was not exactly pleased by the latter chip’s perceived shortcomings. In the ’80s, the 68000 was a very popular chip, powering everything from personal computers to arcade machines, and looking at its architecture and ease of programming, you can see why this was.

Fast-forward a few years, and [Michael] decided to implement both cores in an FPGA to compare real applications, you know, for science. As an extra bonus, he also compares the performance of a minimal RISC-V implementation on the same hardware, taken from an earlier RISC-V project (which you should also check out !)

Utilizing their ‘Java Grinder’ application (also pretty awesome, especially the retro console support), a simple Mandelbrot fractal generator was used as a non-trivial workload to produce binaries for each architecture, and the result was timed. Unsurprisingly, for CISC architectures, the 68000 and x86 code sizes were practically identical and significantly smaller than the equivalent RISC-V. Still, looking at the execution times, the 68000 beat the x86 hands down, with the newer RISC-V speeding along to take pole position. [Michael] admits that these implementations are minimal, with no pipelining, so they could be sped up a little.

Also, it’s not a totally fair race. As you’ll note from the RISC-V implementation, there was a custom RISC-V instruction implemented to perform the Mandelbrot generator’s iterator. This computes the complex operation Z = Z² + C, which, as fellow fractal nerds will know, is where a Mandelbrot generator spends nearly all the compute time. We suspect that’s the real reason RISC-V came out on top.

If actual hardware is more your cup of tea, you could build a minimal 68k system pretty easily, provided you can find the chips. The current ubiquitous x86 architecture, as odd as it started out, is here to stay for the foreseeable future, so you’d just better get comfortable with it!

Continue reading “Comparing X86 And 68000 In An FPGA” →