Pulling Back The Veil, Practically

In a marvelous college lecture in front of a class of engineering students, V. Hunter Adams professed his love for embedded engineering, but he might as well have been singing the songs of our people – the hackers. If you occasionally feel the need to explain to people why you do what you do, at fancy cocktail parties or something, this talk is great food for thought. It’s about as good a “Why We Hack” as I’ve ever seen.

Among the zingers, “projects are filter removers” stuck out. When you go through life, there are a lot of things that you kinda understand. Or maybe you’ve not even gotten around to thinking about whether you understand them or not, and just take them for granted. Life would all simply be too complicated if you took it all sufficiently seriously. Birdsong, Bluetooth, the sun in the sky, the friction of your car’s tire on various surfaces. These are all incredibly deep subjects, when you start to peel back the layers.

And Hunter’s point is that if you are working on a project that involves USB, your success or failure depends on understanding USB. There’s no room for filters here – the illusion that it “just works” often comes crashing down until you learn enough to make it work. Some of his students are doing projects cooperatively with the ornithology department, classifying and creating birdsong. Did you know that birds do this elaborate frequency modulation thing when they sing? Once you hear it, you know, and you hear it ever more.

So we agree with Hunter. Dive into a project because you want to get the project done, sure, but pick the project because it’s a corner of the world that you’d like to shine light into, to remove the filters of “I think I basically understand that”. When you get it working, you’ll know that you really do. Hacking your way to enlightenment? We’ve heard crazier things.

The Need For Speed?

We wrote up a video about speeding up Arduino code, specifically by avoiding DigitalWrite. Now, the fact that DigitalWrite is slow as dirt is long known. Indeed, a quick search pulls up a Hackaday article from 2010 demonstrating that it’s fifty times slower than toggling the pin directly using the native pin registers, but this is still one of those facts that gets periodically rediscovered from generation to generation. How can this be new again?

First off, sometimes you just don’t need the speed. When you’re just blinking LEDs on a human timescale, the general-purpose Arduino functions are good enough. I’ve written loads of useful firmware that fits this description. When the timing requirements aren’t tight, slow as dirt can be fast enough.

But eventually you’ll want to build a project where the old slow-speed pin toggling just won’t cut it. Maybe it’s a large LED matrix, or maybe it’s a motor-control application where the loop time really matters. Or maybe it’s driving something like audio or video that just needs more bits per second. One way out is clever coding, maybe falling back to assembly language primitives, but I would claim that the right way is almost always to use the hardware peripherals that the chipmakers gave you.

For instance, in the end of the video linked above, the hacker wants to drive a large shift register string that’s lighting up an LED matrix. That’s exactly what SPI is for, and coming to this realization makes the project work with timing to spare, and in just a few lines of code. That is the way.

Which brings me to the double-edged sword that the Arduino’s abstraction creates. By abstracting away the chips’ hardware peripherals, it makes code more portable and certainly more accessible to beginners, who don’t want to learn about SPI and I2C and I2S and DMA just yet. But by hiding the inner workings of the chips in “user friendly” libraries, it blinds new users to the useful applications of these same hardware peripherals that clever chip-design engineers have poured their sweat and brains into making do just exactly what we need.

This isn’t really meant to be a rant against Arduino, though. Everyone has to start somewhere, and the abstractions are great for getting your feet wet. And because everything’s open source anyway, nothing stops you from digging deeper into the datasheet. You just have to know that you need to. And that’s why we write up videos like this every five years or so, to show the next crop of new hackers that there’s a lot to gain underneath the abstractions.

Open Source Hiding In Plain Sight

On the podcast, [Tom] and I were talking about the continuing saga of the libogc debacle. [Tom] has been interviewing some of the principals involved, so he’s got some first-hand perspective on it all – you should really go read his pieces. But the short version is that an old library that many Nintendo game emulators use appears to have cribbed code from both and open-source real-time operating system called RTEMS, and the Linux kernel itself.

You probably know Linux, but RTEMS is a high-reliability RTOS for aerospace. People in the field tell me that it’s well-known in those circles, but it doesn’t have a high profile in the hacker world. Still, satellites run RTEMS, so it’s probably also a good place to draw inspiration from, or simply use the library as-is. Since it’s BSD-licensed, you can also borrow entire functions wholesale if you attribute them properly.

In the end, an RTOS is an RTOS. It doesn’t matter if it’s developed for blinking LEDs or for guiding ICBMs. This thought got [Tom] and I to thinking about what other high-reliability open-source code is out there, hidden away in obscurity because of the industry that it was developed for. NASA’s core flight system came instantly to mind, but NASA makes much of its code available for you to use if you’re interested. There are surely worse places to draw inspiration!

What other off-the-beaten-path software sources do you know of that might be useful for our crowd?

Practice While You Work

This week, I had to do something I haven’t done in a long, long time: make myself a custom PCB the old-fashioned way, with laser toner and etchant. The reason? I bought a horrible K40 laser cutter, and the motion controller doesn’t seem to be able to do acceleration control, which means the machine rams full speed into and out of 90 degree corners, for instance. It sounds awful, and it dramatically limits how fast the laser cutter can run.

The plan, then, is to use a controller based on the wonderful FluidNC, but that meant making an adapter board for the flat-flex cable that connects to the X carriage, and the connector has 2 mm pin spacings instead of the usual 2.54 mm, and it just doesn’t fit into any prototyping boards that I have lying around. Besides, a custom PCB adapter board just looks neater.

I wasn’t confident that I could align and drill the dozen small holes for the flat-flex connector; they didn’t have much extra space around them for the copper pads. These holes had to be dead on, or risk ripping them up. And this is where I heard the voice of my old Jedi master.

When you have a tricky operation coming up that requires more precision than you’re immediately comfortable with, you can practice on the other parts of the project that don’t demand that much precision. Pretending that they do, and taking all the care that you can, gets you in shape to tackle the truly critical bits, and if you mess up a little on the easy stuff, it’s not a problem. I had more than a few pin-headers and other random holes to drill for practice anyway.

Now of course, you could always be giving all of your projects 100% all of the time, if time is never of the essence and effort is free. In the real world, you don’t always want to work at maximum precision. Good enough is often good enough.

But there’s also a time and a place for practicing precision, especially when you see a need for it up ahead. Drilling the big holes dead center got me back in the swing of things, and they needed to get drilled one way or the other. I find it useful to think about the job first, plan ahead where the tricky bits are going to be, and then treat the “easy” stuff along the way as practice for the more demanding operations. Hope you do too!

Multitasker Or Many Monotaskers?

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

Valentine Heart

Valentine’s Day…Hacks?

How do you reconcile your love for hacking projects together with your love for that someone special? By making him or her a DIY masterpiece of blinking red LEDs, but in heart shape. Maybe with some custom animations, and in a nice frame with a capacitive touch sensor to turn it on or off.

Or at least, that’s what I did. The good news is that my girlfriend, now wife, understands that this sort of present comes from a place of love. And it probably didn’t hurt that I also picked up some flowers to frame it with, and cooked her favorite lunch later that afternoon.

But if I’m 100% frank with myself, I’d have to admit that this was about 50% “present” and 50% “project”. Of course it also helps that she gets me, and that she knows that I put a bunch of effort into making it look as good as it did, and maybe because of that she forgives the 50% project.

Valentine’s day projects are a high-wire balancing act. If any other project fails, you can just try again. But here, the deadline is firm. Cosmetics matter a lot more on Valentine’s day than the other 364 days of the year, too. And finally, you really have to know the gift-receiver, and be sure that you’re not falling deeper into the excuse-for-a-cool-project trap than I did. And don’t forget the flowers.

I pulled it off with this one, at least, but I do feel like it was close, even today. Have you ever made a Valentine’s hacking project? How’d it go?

(Note: Featured image isn’t my project: It’s a lot more colorful!)

Software In Progress

Open source software can be fantastic. I run almost exclusively open software, and have for longer than I care to admit. And although I’m not a serious coder by an stretch, I fill out bug reports when I find them, and poke at edge cases to help the people who do the real work.

For 3D modeling, I’ve been bouncing back and forth between OpenSCAD and FreeCAD. OpenSCAD is basic, extensible, and extremely powerful in the way that a programming language is, and consequently it’s reliably bug-free. But it also isn’t exactly user friendly, unless you’re a user who likes to code, in which case it’s marvelous. FreeCAD is much more of a software tool than a programming language, and is a lot more ambitious than OpenSCAD. FreeCAD is also a program in a different stage of development, and given its very broad scope, it has got a lot of bugs.

I kept running into some really serious bugs in a particular function – thickness for what it’s worth – which is known to be glitchy in the FreeCAD community. Indeed, the last time I kicked the tires on thickness, it was almost entirely useless, and there’s been real progress in the past couple years. It works at least sometimes now, on super-simple geometries, and this promise lead me to find out where it still doesn’t work. So I went through the forums to see what I could do to help, and it struck me that some people, mostly those who come to FreeCAD from commercial programs that were essentially finished a decade ago, have different expectations about the state of the software than I do, and are a lot grumpier.

Open source software is working out its bugs in public. Most open source is software in development. It’s growing, and changing, and you can help it grow or just hang on for the ride. Some open-source userland projects are mature enough that they’re pretty much finished, but the vast majority of open-source projects are coding in public and software in progress.

It seems to me that people who expect software to be done already are frustrated by this, and that when we promote super-star open projects like Inkscape or Blender, which are essentially finished, we are doing a disservice to the vast majority of useful, but still in progress applications out there that can get the job done anyway, but might require some workarounds. It’s exactly these projects that need our help and our bug-hunting, but if you go into them with the “finished” mentality, you’re setting yourself up for frustration.