Dear Ubuntu…

Dear Ubuntu,

I hope this letter finds you well. I want to start by saying that our time together has been one of creativity and entertainment, a time in which you gave me the tools to develop a new career, to run a small electronics business, make fun things, and to write several thousand articles for Hackaday and other publications, but for all that it’s sadly time for our ways to part. The magic that once brought us together has faded, and what remains is in danger of becoming a frustration.

In our early days as an item you gave me for the first time a Linux distro that was complete, fast, and easy to use without spending too much time at the CLI or editing config files to make things happen; you gave me a desktop that was smooth and uncluttered, and you freed me from all those little utilities that were required to make Windows usable. You replaced the other distros I’d been using, you dual-booted with my Windows machines, and pretty soon you supplanted the Microsoft operating system entirely.

Ubuntu and me and a trusty Dell laptop, Oxford Hackspace, 2017.
Me and Ubuntu in 2017, good times.

We’ve been together for close to two decades now, and in that time we’ve looked each other in the eye across a variety of desktop and laptop computers. My trusty Dell Inspiron 640 ran you for over a decade through several RAM, HDD, and SSD upgrades, and provided Hackaday readers with the first few years of my writing. Even the Unity desktop couldn’t break our relationship, those Linux Mint people weren’t going to tear us asunder! You captured my text, edited my videos and images, created my PCBs and CAD projects, and did countless more computing tasks. Together we made a lot of people happy, and for that I will always be grateful. Continue reading “Dear Ubuntu…”

How Far Can An EULA Go?

We read this news with mixed glee and horror: a company called Telly is giving TVs away, for the low price of having to live with an always-on advertisement bar and some pretty stringent terms and conditions. Break the terms, and they’ll repossess your TV. If you don’t give them the TV, they have your credit card on record and they think the set is worth $1,000.

The hacker in me sees free hardware, so I checked out the terms and conditions, and it doesn’t look good. They’ve explicitly ruled out opening up or physically modifying the device, and it has to continually have WiFi – for which you pay, naturally. It sounds like it could easily tell if you try to tamper with it. My next thought was, perhaps too cynically, to get one, put it in the closet, and wait for the company to go bankrupt. Because you know that business model isn’t going to last.

But it’s clear that they’ve seen through me. The most bizarre clause is that you have to “Use the Product as the primary television in Your household”. Now, we’re not lawyers, but it seems like an amazing stretch that they can tell you how intensively you are to use the product. Can you imagine a license with a keyboard that demanded that you only use it to write sci-fi novels, or that you have to use it more than any other keyboard?

Nope. Too many hoops to jump through for a silly free TV. You can keep your dystopian future.

Tools Of The Trade: Dirt Cheap Or Too Dirty?

We’ve recently seen a couple reviews of a particularly cheap oscilloscope that, among other things, doesn’t meet its advertised specs. Actually, it’s not even close. It claims to be a 100 MHz scope, and it’s got around 30 MHz of bandwidth instead. If you bought it for higher frequency work, you’d have every right to be angry. But it’s also cheap enough that, if you were on a very tight budget, and you knew its limitations beforehand, you might be tempted to buy it anyway. Or so goes one rationale.

In principle, I’m of the “buy cheap, buy twice” mindset. Some tools, especially ones that you’re liable to use a lot, make it worth your while to save up for the good stuff. (And for myself, I would absolutely put an oscilloscope in that category.) The chances that you’ll outgrow or outlive the cheaper tool and end up buying the better one eventually makes the money spent on the cheaper tool simply wasted.

But that’s not always the case either, and that’s where you have to know yourself. If you’re only going to use it a couple times, and it’s not super critical, maybe it’s fine to get the cheap stuff. Or if you know you’re going to break it in the process of learning anyway, maybe it’s a shame to put the gold-plated version into your noob hands. Or maybe you simply don’t know if an oscilloscope is for you. It’s possible!

And you can mix and match. I just recently bought tools for changing our car’s tires. It included a dirt-cheap pneumatic jack and an expensive torque wrench. My logic? The jack is relatively easy to make functional, and the specs are so wildly in excess of what I need that even if it’s all lies, it’ll probably suffice. The torque wrench, on the other hand, is a bit of a precision instrument, and it’s pretty important that the bolts are socked up tight enough. I don’t want the wheels rolling off as I drive down the road.

Point is, I can see both sides of the argument. And in the specific case of the ’scope, the cheapo one can also be battery powered, which gives it a bit of a niche functionality when probing live-ground circuits. Still, if you’re marginally ’scope-curious, I’d say save up your pennies for something at least mid-market. (Rigol? Used Agilent or Tek?)

But isn’t it cool that we have so many choices? Where do you buy cheap? Where won’t you?

A Literate Assembly Language

A recent edition of [Babbage’s] The Chip Letter discusses the obscurity of assembly language. He points out, and I think correctly, that assembly language is more often read than written, yet nearly all of them are hampered by obscurity left over from the days when punched cards had 80 columns and a six-letter symbol was all you could manage in the limited memory space of the computer. For example,  without looking it up, what does the ARM instruction FJCVTZS do? The instruction’s full name is Floating-point Javascript Convert to Signed Fixed-point Rounding Towards Zero. Not super helpful.

But it did occur to me that nothing is stopping you from writing a literate assembler that is made to be easier to read. First, most C compilers will accept some sort of asm statement, and you could probably manage that with compile-time string construction and macros. However, I think there is a better possibility.

Reuse, Recycle

Since I sometimes develop new CPU architectures, I have a universal cross assembler that is, honestly, an ugly hack, but it works quite well. I’ve talked about it before, but if you don’t want to read the whole post about it, it uses some simple tricks to convert standard-looking assembly language formats into C code that is then compiled. Executing the resulting program outputs the desired machine language into a desired file format. It is very easy to set up, and in the middle, there’s a nice C program that emits machine code. It is not much more readable than the raw assembly, but you shouldn’t have to see it. But what if we started the process there and made the format readable?

At the heart of the system is a C program that lives in soloasm.c. It handles command line options and output file generation. It calls an external function, genasm with a single integer argument. When that argument is set to 1, it indicates the assembler is in its first pass, and you only need to fill in label values with real numbers. If the pass is a 2, it means actually fill in the array that holds the code.

That array is defined in the __solo_info instruction (soloasm.h). It includes the size of the memory, a pointer to the code, the processor’s word size, the beginning and end addresses, and an error flag. Normally, the system converts your assembly language input into a bunch of function calls it writes inside the genasm function. But in this case, I want to reuse soloasm.c to create a literate assembly language. Continue reading “A Literate Assembly Language”

The New Hotness

If there’s one good thing to be said about the chip shortage of 2020-2023 (and counting!) it’s that a number of us were forced out of our ruts, and pushed to explore parts that we never would have otherwise. Or maybe it’s just me.

Back in the old times, I used to be a die-hard Atmel AVR fan for small projects, and an STM32 fan for anything larger. And I’ll freely admit, I got stuck in my ways. The incredible abundance of dev boards in the $2 range also helped keep me lazy. I had my thing, and I was fine sticking with it, admittedly due to the low price of those little blue pills.

An IN-12B Nixie tube on a compact driver PCBAnd then came the drought, and like everyone else, my stockpile of microcontrollers started to dwindle. Replacements at $9 just weren’t an option, so I started looking around. And it’s with no small bit of shame that I’ll admit that I hadn’t been keeping up with the changes as much as I should have. Nowadays, it’s all ESP32s and RP2040s over here, and granted there’s a bit of a price bump, but the performance is there in abundance. But I can’t help feeling like I’m a few years back of the cutting edge.

So when I see work like what [CNLohr] and [Bitluni] are doing with the ultra-cheap CH32V003 microcontrollers, it makes me think that I need to start filling in gaps in my comfortable working-set of chips again. But how the heck am I supposed to keep up? And how do you? It took a global pandemic and silicon drought to force me out of my comfort zone last time. Can the simple allure of dirt-cheap chips get me out? We’ll see!

Thinking Inside The Box

Last week, I wrote about NASA’s technology demonstrator projects, and how they’ve been runaway successes – both the Mars rovers and the current copter came from such experimental beginnings. I argued that letting some spirit of experimentation into an organization like NASA is probably very fruitful from time to time.

And then a few days later, we saw SpaceX blow up a rocket and completely shred its launch platform in the process. Or maybe it was the other way around, because it looks like the concrete thrown up by the exhaust may have run into the engines, causing the damage that would lead to the vehicle spinning out of control. SpaceX was already working on an alternative launch pad using water-cooled steel, but it ran what it had. They’re calling the mission a success because of what they learned, but it’s clearly a qualified success. They’ll rebuild and try again.

In comparison, the other US-funded rocket run by Boeing, the SLS suffered years of delays, cost tremendous amounts of money, and has half the lift of SpaceX’s Super Heavy. But it made it to space. Science was done, many of the CubeSats onboard got launched, the unmanned capsule orbited the moon, and splashed down safely back on earth. They weren’t particularly taking any big risks, but they got the job done.

The lore around SpaceX is that they’re failing forward to success. And it’s certainly true that they’ve got their Falcon 9 platform down to a routine, at a lower cost per launch than was ever before possible, and that their pace has entirely shaken up the conservative space industry. They’ll probably get there with their Starship / Super Heavy too. SLS was an old-school rocket, and they had boring old flame diverters on their launch pad, which means that SLS will never take off from Mars. On the other hand, one of the two systems has put a payload around the Moon.

Maybe there’s something to be said for thinking inside the box from time to time as well?

The Freedom To Fail

When you think of NASA, you think of high-stakes, high-cost, high-pressure engineering, and maybe the accompanying red tape. In comparison, the hobby hacker has a tremendous latitude to mess up, dream big, and generally follow one’s bliss. Hopefully you’ll take some notes. And as always with polar extremes, the really fertile ground lies in the middle.

[Dan Maloney] and I were thinking about this yesterday while discussing the 50th flight of Ingenuity, the Mars helicopter. Ingenuity is a tech demo, carrying nothing mission critical, but just trying to figure out if you could fly around on Mars. It was planned to run for five flights, and now it’s done 50.

The last big tech demo was the Sojourner Rover. It was a small robotic vehicle the size of a microwave oven that they hoped would last seven days. It went for 85, and it gave NASA the first taste of success it needed to follow on with 20 years of Martian rovers.

Both of these projects were cheap, by NASA standards, and because they were technical demonstrators, the development teams were allowed significantly more design freedom, again by NASA standards.

None of this compares to the “heck I’ll just hot-air an op-amp off an old project” of weekend hacking around here, but I absolutely believe that a part of the tremendous success of both Sojourner and Ingenuity were due to the risks that the development teams were allowed to take. Creativity and successful design thrives on the right blend of constraint and freedom.

Will Ingenuity give birth to a long series of flying planetary rovers as Sojourner did for her rocker-bogie based descendants? Too early to tell. But I certainly hope that someone within NASA is noticing the high impact that these technical demonstrator projects have, and also noting why. The addition of a little bit of hacker spirit to match NASA’s professionalism probably goes a long way.