A Prototyping Board With Every Connector

Prototyping is a personal affair, with approaches ranging from dead-bug parts on tinplate through stripboard and protoboard, to solderless breadboards and more. Whichever you prefer, a common problem is that they don’t offer much in the way of solid connections to the outside world. You could use break-out boards, or you could do like [Pakequis] and make a prototyping board with every connector you can think of ready to go.

The board features the expected prototyping space in the middle, and we weren’t joking when we said every connector. There are analogue, serial, USB, headers aplenty, footprints for microcontroller boards, an Arduino shield, a Raspberry Pi header, and much more. There will doubtless be ones that readers will spot as missing, but it’s a pretty good selection.

We can imagine that with a solderless breadboard stuck in the middle it could be a very useful aid for teaching electronics, and we think it would give more than a few commercial boards a run for their money. It’s not the first we’ve featured, either.

Continue reading “A Prototyping Board With Every Connector” →

Moving Software Down To Hardware

In theory, any piece of software could be built out of discrete pieces of hardware, provided there are enough transistors, passive components, and time available. In general, though, we’re much more likely to reach for a programmable computer or microcontroller for all but the simplest tasks for several reasons: cost, effort, complexity, economics, and sanity. [Igor Brichkov] was working with I2C and decided that he wanted to see just where this line between hardware and software should be by implementing this protocol itself directly with hardware.

One of the keys to “programming” a communications protocol in hardware is getting the timing right, the first part of which is initializing communications between this device and another on the bus. [Igor] is going to be building up the signal in parts and then ORing them together. The first part is a start condition, generated by one oscillator and a counter. This also creates a pause, at which point a second oscillator takes over and sends data out. The first data needed for I2C is an address, which is done with a shift register and a counter pre-set to send the correct bits out on the communications lines.

To build up the rest of the signal, including data from the rotary encoder [Igor] is using for his project, essentially sets of shift registers and counters are paired together to pass data out through the I2C communications lines in sequence. It could be thought of that the main loop of the hardware program is a counter, which steps through all the functions sequentially, sending out data from the shift registers one by one. We saw a similar project over a decade ago, but rather than automating the task of sending data on I2C it allowed the user to key in data manually instead.

Continue reading “Moving Software Down To Hardware” →

Checking In On The ISA Wars And Its Impact On CPU Architectures

An Instruction Set Architecture (ISA) defines the software interface through which for example a central processor unit (CPU) is controlled. Unlike early computer systems which didn’t define a standard ISA as such, over time the compatibility and portability benefits of having a standard ISA became obvious. But of course the best part about standards is that there are so many of them, and thus every CPU manufacturer came up with their own.

Throughout the 1980s and 1990s, the number of mainstream ISAs dropped sharply as the computer industry coalesced around a few major ones in each type of application. Intel’s x86 won out on desktop and smaller servers while ARM proclaimed victory in low-power and portable devices, and for Big Iron you always had IBM’s Power ISA. Since we last covered the ISA Wars in 2019, quite a lot of things have changed, including Apple shifting its desktop systems to ARM from x86 with Apple Silicon and finally MIPS experiencing an afterlife in  the form of LoongArch.

Meanwhile, six years after the aforementioned ISA Wars article in which newcomer RISC-V was covered, this ISA seems to have not made the splash some had expected. This raises questions about what we can expect from RISC-V and other ISAs in the future, as well as how relevant having different ISAs is when it comes to aspects like CPU performance and their microarchitecture.

Continue reading “Checking In On The ISA Wars And Its Impact On CPU Architectures” →

Long-tail pair waves

Current Mirrors Tame Common Mode Noise

If you’re the sort who finds beauty in symmetry – and I’m not talking about your latest PCB layout – then you’ll appreciate this clever take on the long-tailed pair. [Kevin]’s video on this topic explores boosting common mode rejection by swapping out the old-school tail resistor for a current mirror. Yes, the humble current mirror – long underestimated in DIY analog circles – steps up here, giving his differential amplifier a much-needed backbone.

So why does this matter? Well, in Kevin’s bench tests, this hack more than doubles the common mode rejection, leaping from a decent 35 dB to a noise-crushing 93 dB. That’s not just tweaking for tweaking’s sake; that’s taking a breadboard standard and making it ready for sensitive, low-level signal work. Instead of wrestling with mismatched transistors or praying to the gods of temperature stability, he opts for a practical approach. A couple of matched NPNs, a pair of emitter resistors, and a back-of-the-envelope resistor calculation – and boom, clean differential gain without the common mode muck.

If you want the nitty-gritty details, schematics of the demo circuits are on his project GitHub. Kevin’s explanation is equal parts history lesson and practical engineering, and it’s worth the watch. Keep tinkering, and do share your thoughts on this.

Continue reading “Current Mirrors Tame Common Mode Noise” →

The Trials And Tribulations Of Building A Pasta Display

We love unique displays here at Hackaday. If you can figure out how to show information on some weird object, we’re all about it. So when [Julius Curt] wrote in to share his work on the Pasta Analog Display, we were hooked from the subject line.

But in reading his account, it ended up being even better than we hoped for. Because it turns out, getting pasta to behave properly in an electromechanical device is trickier than you might think. Oh sure, as [Julius] points out, those ridges on the side of penne might make them look like gears — but after spending the time and effort to build a particularly slick 3D printed frame to actually use them as such, it turns out they just won’t cooperate. You’d think the pasta makers of the world would have some respect for mechanical tolerances, but unfortunately not.

Continue reading “The Trials And Tribulations Of Building A Pasta Display” →

The Mysterious And Important Work Of Prop Design On Severance

Have you seen Severance? Chances are good that you have; the TV series has become wildly popular in its second season, to the point where the fandom’s dedication is difficult to distinguish from the in-universe cult of [Kier]. Part of the show’s appeal comes from its overall aesthetic, which is captured in this description of the building of one of the show’s props.

A detailed recap of the show is impossible, but for the uninitiated, a mega-corporation called Lumon has developed a chip that certain workers have implanted in their brains to sever their personalities and memories into work and non-work halves. The working “Innies” have no memory of what their “Outies” do when they aren’t at work, which sounds a lot better than it actually ends up being. It’s as weird as it sounds, and then some.

The prop featured here is the “WoeMeter” from episode seven of season two, used to quantify the amount of woe in a severed worker — told you it was weird. The prop was built by design house [make3] on a short timeline and after seeing only some sketches and rough renders from the production designers, and had to echo the not-quite-midcentury modern look of the whole series. The builders took inspiration from, among other things, a classic Nagra tape recorder, going so far as to harvest its knobs and switches to use in the build. The controls are all functional and laid out in a sensible way, allowing the actors to use the device in a convincing way. For visual feedback, the prop has two servo-operated meters and a string of seven-segment LED displays, all controlled by an ESP-32 mounted to a custom PCB. Adding the Lumon logo to the silkscreen was a nice touch.

The prop maker’s art is fascinating, and the ability to let your imagination run wild while making something that looks good and works for the production has got to be a blast. [make3] really nailed it with this one.

Thanks to [Aaron’s Outie] for the tip.

Physical Computing Used To Be A Thing

In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?