Hackaday Links Column Banner

Hackaday Links: July 12, 2026

Although we’d rather bring you news of clever modifications and repairs down on the farm, more often than not, the name “John Deere” has appeared on the pages of Hackaday because of their opposition to farmers actually being able to work on the machines their livelihoods depend on. But thanks to a settlement reached between the company and the Federal Trade Commission this week, farmers seem to have been handed a much-needed win in the Right to Repair battle.

When a lawsuit against a company ends in a settlement, it usually means spending money they would rather pay than go to court. Indeed, earlier cases against John Deere have resulted in plenty of checks being written. But this time around, the FTC agreement requires Deere to make its diagnostic and repair software available to owners and independent shops. It also has a clause that prevents them from retaliating against owners who want to handle their own repairs rather than going through the company’s official service channels — hard to believe that’s something that actually needs to be specified, but it does give you a hint as to just how bad the situation has been. We’ll definitely be keeping an eye on this story.

Sounds like the Feds were busy this week, as the Federal Communications Commission also gave the green light to Reflect Orbital to launch a prototype satellite for their controversial “sunlight as a service” concept. The company plans to put the spacecraft into a roughly 600 km orbit around the planet, where it will deploy its 324-square-meter reflector and angle itself to illuminate a spot on the ground. It might sound like something a Bond villain would come up with, but Reflect Orbital says the capability will be used to beam sunlight directly onto solar panels at night and to provide light for search-and-rescue operations.

As you might expect, providing such a service on a global scale would require many such reflectors, which is where the concern really comes in. Critics note that a sky full of literal mirrors can cause all sorts of issues, ranging from the scientific to the scenic. The American Astronomical Society points out that each satellite in the constellation could appear to be four times as bright as the full Moon, and that it’s possible an amateur sky watcher could get an eyeball full of redirected sunlight should one of them unexpectedly zip past the aperture of their backyard telescope.

Continue reading “Hackaday Links: July 12, 2026”

SPI On Embedded Linux

Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?

The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.

The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.

Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.

Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.

Continue reading “SPI On Embedded Linux”