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.

Yesterday’s Future Is Brighter Today

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.

Animated Progress Bar Shows LCD New Tricks

A small LCD screen can be extremely helpful with small microcontroller projects. Not everything needs to communicate to a fancy server using an ESP8266. However, if the simplicity of the character displays irks you, it’s possible to spice them up a little bit with custom characters and create animations, like [Fabien] did with his animated Arduino progress bar. (Google Translate from French)
The project started out simply enough: all [Fabien] needed was a progress bar. It’s easy enough to fill in the “characters” on the 2×16 character LCD screen one-by-one to indicate progress, and the first version of this did exactly that. The second version got a little bit fancier by adding a border around the progress bar and doubling its resolution, but the third version is where knowing the inner machinations of the microcontroller really paid off. Using a custom charset reuse optimization, [Fabien] was able to use 19 custom characters at a time when the display will normally only allow for eight. This was accomplished by placing the custom characters in memory in the correct order, to essentially trick the microcontroller into displaying them.
These types of microcontroller hacks get deep into the inner workings of the microcontroller and help expose some tricks that we can all use to understand their operation on a deeper level. Whether you’re using PWM to get a microcontroller to operate a TV, or creating the ATtiny-est MIDI synth, these tricks are crucial to getting exactly what you want out of a small, inexpensive microcontroller.