In our technologically complex world, standards are a double-edged sword. While they clearly make it possible for widgets and doodads to interoperate with each other, they also tend to drift away from their original intention over time, thanks to the march of progress or even market forces. If there’s one thing you can expect about standards, it’s that they beget other standards.
One standard that has stood the test of time, with modification of course, is the Musical Instrument Digital Interface, or MIDI. It’s hard to overstate the impact MIDI has had on the music world since it was first dreamed up in the early 1980s. Started amid a Wild West of competing proprietary synchronization standards, MIDI quickly became the de facto interface for connecting electronic musical instruments together. And as it did, it moved from strictly pro-grade equipment down the market to prosumer and home users, fueled in part by the PC revolution.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about. Continue reading “MIDI All The Things Hack Chat”→
Given an unknown PCBA with an ARM processor, odds are good that it will have either the standard 10 pin 0.05″ or 20 pin 0.1″ debug connector. This uncommon commonality is a boon for an exploring hacker, but when designing a board such headers require board space in the design and more components to be installed to plug in. The literally-named Debug Edge standard is a new libre attempt to remedy this inconvenience.
The name “Debug Edge” says it all. It’s a debug, edge connector. A connector for the edge of a PCBA to break out debug signals. Card edge connectors are nothing new but they typically either slot one PCBA perpendicularly into another (as in a PCI card) or hold them in parallel (as in a mini PCIe card or an m.2 SSD). The DebugEdge connector is more like a PCBA butt splice.
It makes use of a specific family of AVX open ended card edge connectors designed to splice together long rectangular PCBAs used for lighting end to end. These are available in single quantities starting as low as $0.85 (part number for the design shown here is 009159010061916). The vision of the DebugEdge standard is that this connector is exposed along the edge of the target device, then “spliced” into the debug connector for target power and debug.
Right now the DebugEdge exists primarily as a standard, a set of KiCAD footprints, and prototype adapter boards on OSHPark (debugger side, target side). A device making use of it would integrate the target side and the developer would use the debugger side to connect. The standard specifies 4, 6, 8, and 10 pin varieties (mapping to sizes of available connector, the ‘010’ in the number above specifies pincount) offering increasing levels of connectivity up to a complete 1:1 mapping of the standard 10 pin ARM connector. Keep in mind the connectors are double sided, so the 4 pin version is a miniscule 4mm x 4.5mm! We’re excited to see that worm its way into a tiny project or two.
If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here’s your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard’s newest revision, C++20, deciding on all the new features that will come to C++’s next major release.
After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its “being a superset of C” times. Frankly, when it comes to loving or hating the language, I haven’t fully made up my own mind about it yet. My biggest issue with it is that “programming in C++” can just mean so many different things nowadays, from a trivial “C with classes” style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won’t get easier. Although, they also won’t get harder. Well, at least not necessarily. I guess? Well, it’s complex, but that’s simply the nature of the language.
Anyway, the list of new features is long, combining all the specification proposals is even longer, and each and every one of these additions could fill its own, full-blown article. But to get a rough idea about what’s going to come to C++ next year, let’s have a condensed look at some of these major new features, changes, and additions that will await us in C++20. From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there’s a lot at play here!
Sure, we all love fixing stuff, but there’s often a fine line between something that’s worth repairing and something that’s cheaper in the long run to just replace. That line gets blurred, though, when there’s something to be learned from a repair.
This wonky temperature-compensated crystal oscillator is a good example of leaning toward repair just for the opportunity to peek inside. [Kerry Wong] identified it as the problem behind a programmable frequency counter reading significantly low. A TCXO is supposed to output a fixed frequency signal that stays stable over a range of temperatures by using a temperature sensor to adjust a voltage-controlled oscillator that corrects for the crystal’s natural tendency to vary its frequency as it gets hotter or colder. But this TCXO was pretty old, and even the trimmer capacitor provided was no longer enough to nudge it back in range. [Kerry] did some Dremel surgery on the case and came to the conclusion that adding another trim cap between one of the crystal’s leads and ground would help. This gave him a much wider adjustment range and let him zero in on the correct 10-MHz setting. [Mr. Murphy] still runs the show, though – after he got the TCXO buttoned up with the new trimmer inaccessible, he found that the frequency was not quite right. But going from 2 kHz off to only 2 Hz is still pretty good.
The NASA workmanship standards are absolutely beautiful. I mean that in the fullest extent of the word. If I had any say in the art that goes up in the Louvre, I’d put them up right beside Mona. They’re a model of what a standard should be. A clear instruction for construction, design, and inspection all at once. They’re written in clear language and contain all the vernacular one needs to interpret them. They’re unassuming. The illustrations are perfectly communicative. It’s a monument to the engineer’s art.
Around five years ago I had a problem to solve. Every time a device went into the field happily transmitting magic through its myriad connectors, it would inevitably come back red tagged, dusty, and sad. It needed to stop. I dutifully traced the problem to a connector, and I found the problem. A previous engineer had informed everyone that it was perfectly okay to solder a connector after crimping. This instruction was added because, previously, the crimps were performed with a regular pair of needle nose pliers and they came undone… a lot. Needless to say, the solder also interfered with their reliable operation, though less obviously. Stress failures and intermittent contact was common.
We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.
[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?
When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.
So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.