PCB Bring-Up Hack Chat

Join us on Wednesday, April 15 at noon Pacific for the PCB Bring-Up Hack Chat with Mihir Shah and Liam Cadigan!

The printed circuit design process is pretty unique among manufacturing processes. Chances are pretty good that except for possibly a breadboard prototype, the circuit that sits before you after coming back from assembly has only ever existed in EDA software or perhaps a circuit simulator. Sure, it’s supposed to work, but will it?

You can — and should — do some power-off testing of new boards, but at some point you’re going to have to flip the switch and see what happens. The PCB bring-up process needs to be approached carefully, lest debugging any problems that crop up become more difficult than need be. Mihir and Liam from inspectAR will discuss the bring-up process in depth, offering tips and tricks to make things go as smoothly as possible, as well as demonstrating how the inspectAR platform can fit into that process, especially with teams that are distributed across remote sites. If your board releases the Magic Smoke, you’ll want to know if it’s your design or an assembly issue, and an organized bring-up plan can be a big help.

Note: Liam will be doing a simulcast web demo of inspectAR via Zoom. ​

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, April 15 at 12:00 PM Pacific time. If time zones have got you down, we have a handy time zone converter.

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 “PCB Bring-Up Hack Chat”

Tony Brooker And Autocode – The First High-level Language

The field of computer science has undeniably changed the world for virtually every single person by now. Certainly for you as Hackaday reader, but also for everyone around you, whether they’re working in the field themselves, or are simply enjoying the fruits of convenience it bears. What was once a highly specialized niche field for a few chosen people has since grown into a discipline that not only created one of the biggest industry in modern times, but also revolutionized every other industry, some a few times over.

The fascinating part about all this is the relatively short time span it took to get here, and with that the privilege to live in an era where some of the pioneers and innovators, the proverbial giants whose shoulders every one of us is standing on, are still among us. Sadly, one of them, [Tony Brooker], a pioneer of the early programming language concept known as Autocode, passed away in November. Reaching the remarkable age of 94, the truly sad part however is that this might be the first time you hear his name, and there’s a fair chance you never heard of Autocode either.

But Autocode was probably the first high-level computer language, and as such played a fundamental role in the development of whatever you’re coding in today. So to honor the memory of [Tony Brooker], let’s remember the work he did with Autocode, and the leap in computer science history that it represented.

Continue reading “Tony Brooker And Autocode – The First High-level Language”

These Tips Make Assembling A Few Hundred PCBs Easier

There are a few common lessons that get repeated by anyone who takes on the task of assembling a few hundred PCBs, but there are also unique insights to be had. [DominoTree] shared his takeaways after making a couple hundred electronic badges for DEFCON 26 (that’s the one before the one that just wrapped up, if anyone’s keeping track.) [DominoTree] assembled over 200 Telephreak badges and by the end of it he had quite a list of improvements he wished he had made during the design phase.

Some tips are clearly sensible, such as adding proper debug and programming interfaces, or baking an efficient test cycle into the firmware. Others are not quite so obvious, for example “add a few holes to your board.” Holes can be useful in unexpected ways and cost essentially zero. Even if the board isn’t going to be mounted to anything, a few holes can provide a way to attach jigs or other hardware like test fixtures.

[DominoTree] ended up having to attach multiple jumper wires to reprogram boards after assembly, and assures us that “doing this a bunch of times really sucked.”
Other advice is more generic but no less important, as with “eliminate as many steps as possible.” Almost anything adds up to a significant chunk of time when repeated hundreds of times. To the basement hacker, something such as pre-cut and pre-tinned wires might seem like a shameful indulgence. But cutting, stripping, tinning, then hand-soldering a wire adds up to significant time and effort by iteration number four hundred (that’s two power wires per badge) even if one isn’t staring down a looming deadline.

[DominoTree] also followed up with additional advice on making assembly easier. Our own [Brian Benchoff] has also shared his observations on the experience of developing and assembling a large number of Hackaday Superconference badges, including what it took to keep things moving along when inevitable problems surfaced.

You don’t need to be making batches of hundreds for these lessons to pay off, so keep them in mind and practice them on your next project.

Debug Superpowers Bring An STM32 Back From The Dead

When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead”

Examine Source Code To Assembly Mapping With PenguinTrace

C-programmers who don’t have a mental model of what’s going on underneath their thin veneer of abstraction above assembly code are destined for trouble. In order to provide a convenient way to understand what C-code gets compiled to and how it runs on the machine, [Alex Beharrell] has created penguinTrace, a program which allows you to see what instructions your code compiles to, and examine how it executes.

While you can get somewhat similar functionality out of standard debuggers, penguinTrace was purpose-built to facilitate exploration of how the whole process works. You can single-step through the instructions your code compiled to, examine variables, and look at the stack — the usual debugger stuff — but structured more for exploration and learning than full-on debugging. Based on our experiences when we learned low-level programming, anything that can help novices build that all-important mental picture of what’s going on underneath is a good thing. But, since it was written with a secondary purpose of learning how debuggers themselves work, it’s a great opportunity for exploring that space, too.

The UI harnesses CodeMirror to provide a browser-based interface, and is configurable to use Clang or GCC for compilation. It supports AMD64/X86-64 and AArch64 architectures, and will run on Windows using WSL: if you’ve got a PC running Linux, a Raspberry Pi, or a Windows box, you’re good to go. The code is AGPL-licensed and available on GitHub. So, if you want to gain a better understanding of what happens when you compile and run “hello, world,” grab a copy and start exploring.

This isn’t the only way to debug, though – we previously featured an application that allows a type of debugging for the Arduino platform.

 

 

35C3: Biggest Communication Congress, Yet Little Chaos

Every year for the past 35 years, the German Chaos Computer Club has met just after Christmas for a few days of “Spaß am Gerät” — having fun with the machines. And that’s everything from trying to bring an old PDP-8 back into running condition to forging new software to replace the old and busted social media platforms that permeate our lives. The sum total of around 17,000 people doing the nerdy stuff that they love, and sharing it together, is both amazing and inspiring. Four days of little sleep and much socializing later, I bet there was still another four days’ worth of stuff to see.

The official theme this year was “Refreshing Memories” which honestly sounds a bit too much like a cola slogan, but was a great opportunity to think back on the hacks of the past that got us where we are. Assemblies put up shrines to their hacker heroes of the past. Retro computers were everywhere, in the talks and on the floor. This year’s Congress was a great time to look back and remember, but also to create new memories for the future. On that front, it was a total success.

But the unofficial theme this year was “Smooth Running”. Everything went very well, which is no small feat considering that the infrastructure, decoration, security, and even the medical response teams are from the Chaos community. It’s the depth of engagement that makes this work: of the 17,000 people who showed up, just over 4,000 of them volunteered for “angel” shifts — meaning they helped guard the doors, staff the info desks, or build up or tear down. It was the largest ever CCC, and you could feel it, but they pulled it off, and then some.

The angels are geeks just like you and me, and since everything went so smoothly, they had time to play. For instance, the phone operations people offer DECT phone service so that attendees can bring in their home phones and use them at Congress. In years past, the lines to register and enroll phones were painfully long. This year, it all happened online, and the result is that the phone ops crew got bored. That explains how they had time to establish roaming home-phone wireless service in some of the normal Leipzig city trams. Wait, what?

Continue reading “35C3: Biggest Communication Congress, Yet Little Chaos”

New Game, Old Ways: Cramming An NES Game Into 40 KB

Why would anyone bother to create new content for a console system that’s staring down its 40th birthday? Perhaps just for the challenge of fitting a game into 40 kilobytes of storage.

That at least seems to be the motivation behind [Morphcat Games] pending release of Micro Mages, a new game for the Nintendo Entertainment System console that takes its inspiration from Super Mario Bros. The interesting bit here is how they managed to stuff so much content into so little space. The video below goes into great detail on that, and it’s a fascinating lesson in optimization. The game logic itself is coded in assembler, which of course is far more efficient than higher level languages. Even so, that took 32 kB of ROM, leaving a mere 8 kB for background elements and foreground sprites.

Through a combination of limited sprite size, tiling of smaller sprites to make larger characters, and reusing tiles by flipping them horizontally or vertically, an impressively complete palette of animated characters was developed. Background elements were similarly deconstructed and reused, resulting in a palette of tiles used to generate all the maps for the game that takes up just 60 bytes. Turning those into playable levels involves more mirroring and some horizontal shifting of tiles, and it looks like quite an engaging playfield.

Yes, there’s a Kickstarter for the game, but we’re mainly intrigued by what it takes to cram a playable game into so little space. Don’t get us wrong – we love the Retro Pie builds too, but seeing the tricks that early game developers relied upon to make things work really gets the creative juices flowing.

Continue reading “New Game, Old Ways: Cramming An NES Game Into 40 KB”