A Calculator In 2020?

March 7, 2020 by Elliot Williams 91 Comments

This week, Al Williams wrote up an article on what might be the last scientific calculator. Back in the day, the fanciest of scientific calculators had not just sin, cos, and tan, but were also programmable so that you could code in frequently used formulae. And the calculator that he reviews is certainly powerful: with a screen, processor, and memory almost rivalling a mid-scale smartphone.

Wait a minute! “Almost”? I have a smartphone in my pocket right now. Why would I want something less powerful, when all that the calculator brings to the table is a bit of software? And that app can even be purchased for $20!

I’ll confess. I want a proper desktop calculator from time to time. But why? Sure, I can run calculations on the very computer that I’m using to type right now. And in terms of programming languages, the resources are far superior on my laptop. Unit conversions? Units, or the Interwebs. Heck, I can even type calculations directly into the Unix world’s default editor.

But there’s something nice about the single-purpose device. Maybe it’s the feel of the keys. Maybe it’s because it doesn’t require a context-switch on the computer. Maybe it’s irrational calculator nostalgia. Or maybe it’s an elegant tool from a more civilized age: the user experience is better because the tool is just simpler.

I like stand-alone devices that do their one thing right, and I almost always pick them over their more complex, if also more capable, counterparts when I only need that function. The fixed wrench over the adjustable wrench. The standalone audio recorder over my computer’s software. The simple bench power supply over the programmable. And, when I’m actually setting out to take good photos, a real camera instead of my cell phone’s. Purpose-built tools tend to work much better for their purpose than devices that try to do everything.

The days of the standalone calculator are nearly gone, though, so what am I going to do? I’m certainly not going to shell out megabucks for an overly-fancy calculator, nor am I going to be lured by nostalgia into picking up an antique at the ridiculous prices they fetch online. That leaves one option, and it’s both the Hackaday and the Jedi way. I’m going to have to build it myself. Where am I going to get a nice-feeling numeric keypad?

Mithro Runs Down Open Source FPGA Toolchains

March 6, 2020 by Elliot Williams 28 Comments

Tim [Mithro] Ansell has a lot to tell you about the current state of open FPGA tooling: 115 slides in 25 minutes if you’re counting. His SymbiFlow project aims to be the GCC of FPGA toolchains: cross-platform, multi-platform, completely free, and all-encompassing. That means that it’s an umbrella framework for all of the work that everyone else is doing, from work on synthesis and verification tools, to placing and routing, to vendor-specific chip libraries. His talk catches you up with the state of the art at the end of 2019, and it’s embedded below. Spoiler alert: SymbiFlow has the big Xilinx 7-series FPGAs in its crosshairs, and is closing in. SymbiFlow is that close to getting a networked Linux system on the FPGA fabric in a Xilinx 7 today, completely independent of any vendor tools.

But let’s step back a sec for a little background. When you code for an FPGA, words you type get turned into a bitstream of ones and zeroes that flip perhaps a few million switches inside the chip. Going from a higher-level language to a bitstream is a lot like compiling normal programming languages, except with the twist that the resulting computational logic doesn’t map straight into a machine language, but rather into lower-level physical hardware on the FPGA. So “compilation” for FPGAs involves two steps: synthesis and place-and-routing. Synthesis takes the higher-level language that you write and turns it into a set of networks and timing requirements that represent the same logic, and can work across chip families. Yosys is the open-source synthesis tool of choice here.

Continue reading “Mithro Runs Down Open Source FPGA Toolchains” →

The IoT Trap

February 29, 2020 by Elliot Williams 65 Comments

I’m sure that you’ve heard about the Sonos speaker debacle. (If not, read about it on Hackaday.) Basically, a company that sells a premium Internet-connected speaker wanted to retire an older product line, and offered a 30% discount to people who would “trade in” their old speakers for new ones. The catch: they weren’t really trading them in, but instead flashing a “self-destruct” firmware and then taking it to the recycling.

Naturally, Sonos’ most loyal customers weren’t happy about intentionally bricking their faithful devices, a hubbub ensued, and eventually the CEO ended up reversing course and eating crow. Hackaday’s own Gerrit Coetzee wrote up our coverage and mentioned that maybe Sonos just couldn’t afford to support the service for the old products any more, and didn’t want them to remain in the wild. So much so, that it’s worth 30% of the cost of their current product to get out from under the implicit contract.

By buying one of these IoT devices, you’re paying more money up front for the promise that the company will keep supporting the service that it relies on into the future. But providing this service costs money, and as more and more “products” are actually services in disguise, we’ve seen case after case of working machines shut down because the company doesn’t want to keep paying for the service. It doesn’t seem to matter if the company is small, like Sonos, or an immensely wealthy monopoly player like Google. Somehow, the people planning these products have a much shorter lifetime in mind than their customers do, and fail to make the up-front price cover costs.

This puts these companies in a tough spot. The more a customer loves the device, the longer they’ll want to keep it running, and the worse the blowback will be when the firm eventually has to try to weasel its way out of a “lifetime” contract. And they are alienating exactly their most loyal customers — those who want to keep their widget running longer than might even be reasonable. Given that this whole business model is new, it’s not surprising that some firms will get it wrong. What’s surprising to me is how many fall into the IoT trap.

So take this as a cautionary tale as a consumer. And if you’re in a company offering a product that depends on a service to continue to function, ask yourself if you’re really going to be able to support it for the customer’s idea of the lifetime of the product. What looks like a great deal at a five-year horizon might bankrupt your company at ten. Will you, or your customers, be willing to throw their devices away? Should they be?

Supercon Keynote: Megan Wachs Breaks Down RISC-V

January 27, 2020 by Elliot Williams 17 Comments

The 2019 Hackaday Superconference kicked off with a marvelous, and marvelously geeky, keynote talk on the subject of RISC-V by Dr. Megan Wachs. She is VP of Engineering at SiFive, a company that makes RISC-V processors in silicon, but the talk is a much more general introduction to the RISC-V open instruction-set architecture (ISA) and why you’d care. The short answer to the latter is the same reason you care about any other open standard: it promotes interoperability, reusable toolchains, and will result in us all having access to better and faster CPUs.

The video is embedded below, and it’s absolutely worth a watch. Unfortunately, The video is missing the first few minutes, you can follow along through her slides (PDF) and read through our brief recap below of what fell down the video hole.

Continue reading “Supercon Keynote: Megan Wachs Breaks Down RISC-V” →

New Part Day: LED Driver Is FPGA Dev Board In Disguise

January 24, 2020 by Elliot Williams 51 Comments

Our new part of the day is the ColorLight 5A-75B, a board that’s meant to drive eight of those ubiquitous high-density color LED panels over gigabit Ethernet. If you were building a commercial LED wall, you’d screw a bunch of the LED panels together, daisy-chain a bunch of these boards to drive them, supply power, and you’d be done. Because of that high-volume application, these boards are inexpensive, around $15 each, and available as quickly as you can get stuff shipped from China.

But we’re not here to talk commercial applications. Managing fast Ethernet and pushing so many pixels in real time is a task best handled by an FPGA, and [Tom Verbeure] noticed that these things were essentially amazing FPGA development boards and started hacking on them. [q3k] put it up on GitHub, and you can follow along with the chubby75 reverse engineering project to dig into their secrets.

While the first generations of these boards used the old-standby Spartan 6, things got interesting for fans of open FPGA tools when newer versions were found using the Lattice ECP5-25 chips, the little brother of the stonking big chip [Sprite_TM] used on the 2019 Hackaday Supercon badge. If you want to grab one you’re looking for ColorLight boards marked with revision 6 or 7 as of this writing.

What does this mean? For the price of a gourmet hamburger, you get an FPGA that’s big enough to run a RISC-V softcore, two 166 MHz, 2 MB SDRAMS, flash for the FPGA bitstream, a bazillion digital outputs on 5 V level shifters, and two gigabit Ethernet ports. The JTAG port is broken out in 0.1″ headers, and it works with OpenOCD, which is ridiculously convenient. How’s that for a well-stocked budget FPGA dev board that’s served by a completely open toolchain? Continue reading “New Part Day: LED Driver Is FPGA Dev Board In Disguise” →

Bringing The Blockchain To Network Monitoring

January 22, 2020 by Elliot Williams 14 Comments

If you need to make sure your computer isn’t being messed with, you’ll have a look at the log files. If something seems fishy, that’s grounds for further investigation. If you run a large network of computers, you’ll probably want to look over all of the logs, but you won’t want to run around to each computer individually. Setting up a central server to analyze the logs exposes an additional attack surface: the logs in transit. How do you make sure that the attackers aren’t also intercepting and sanitizing your log file reports?

The answer to this question, and nearly everything else, is blockchain! Or maybe it’s not, but in this short presentation from the 2019 Hackaday Superconference, Shanni Prutchi, Jeff Wood, and six other college students intend to find out. While Shanni “rolls her eyes” at much of blockchain technology along with the rest of us, you have to admit one thing: recursively hashing your log data to make sure they’re not tampered with doesn’t sound like such a bad idea. Continue reading “Bringing The Blockchain To Network Monitoring” →

36C3: All Wireless Stacks Are Broken

December 30, 2019 by Elliot Williams 29 Comments

Your cellphone is the least secure computer that you own, and worse than that, it’s got a radio. [Jiska Classen] and her lab have been hacking on cellphones’ wireless systems for a while now, and in this talk gives an overview of the wireless vulnerabilities and attack surfaces that they bring along. While the talk provides some basic background on wireless (in)security, it also presents two new areas of research that she and her colleagues have been working on the last year.

One of the new hacks is based on the fact that a phone that wants to support both Bluetooth and WiFi needs to figure out a way to share the radio, because both protocols use the same 2.4 GHz band. And so it turns out that the Bluetooth hardware has to talk to the WiFi hardware, and it wouldn’t entirely surprise you that when [Jiska] gets into the Bluetooth stack, she’s able to DOS the WiFi. What this does to the operating system depends on the phone, but many of them just fall over and reboot.

Lately [Jiska] has been doing a lot of fuzzing on the cell phone stack enabled by some work by one of her students [Jan Ruge] work on emulation, codenamed “Frankenstein”. The coolest thing here is that the emulation runs in real time, and can be threaded into the operating system, enabling full-stack fuzzing. More complexity means more bugs, so we expect to see a lot more coming out of this line of research in the next year.

[Jiska] gives the presentation in a tinfoil hat, but that’s just a metaphor. In the end, when asked about how to properly secure your phone, she gives out the best advice ever: toss it in the blender.