2026-04-28 04:00:44
Springs are great, but making them out of plastic tends to come with some downsides, for fairly obvious reasons. Creating a compliant mechanism that can be 3D printed and yet which doesn’t permanently deform or wear out after a few uses is therefore a bit of a struggle. The complaint toggle mechanism that [neotoy] designed is said to have addressed those issues, with the model available on Printables for anyone to give a shake.
The model in question is a toggle, which is the commonly seen plastic or metal device that clamps down on e.g. rope or cord and requires you to push on it to have it release said clamping force. Normally these use a metal spring inside, but this version is fully 3D printable and thus forms a practical way to test this particular compliant mechanism with a variety of materials.
The internal spring is a printed spiral spring, with the example in the video printed in PETG. You can of course also print it in other materials for different durability and springiness properties. As noted in the video, PLA makes for a very poor spring material, so you probably want to skip that one.
We covered compliant mechanisms in the past for purposes like blasters, including some that you can only see under a microscope.
2026-04-28 02:15:48
When building a project to operate on battery power for long periods of time, having a microcontroller with a reliable and extremely low-power sleep mode is critical. When processing power isn’t needed, it should be able to wait around using almost no energy until an interrupt triggers it. Once triggered, the CPU performs its tasks and then puts itself right back to sleep, making sure the battery lasts as long as possible. Unfortunately, not every microcontroller has sleep capabilities or has an acceptably low level of power use for maximizing battery life. For these systems, a tool like this power manager might come in handy.
The small PCB, called the powerTimer, essentially acts as a middleman for power delivery to another microcontroller. On the PCB is an RV3028-C7 real-time clock, which uses a mere 45 nA of current and can interact with the second microcontroller through a timer or alarm. When commanded, the powerTimer uses an SR latch as its main control circuit, allowing single button presses to change the power state for the second microcontroller. Once the powerTimer powers up the second microcontroller, that microcontroller can communicate back to the powerTimer with a “DONE” signal, and once this signal is received, the powerTimer will cut power and wait for the next interrupt to occur.
The project’s creator, [Juan], had this idea for an ESP32 with a camera module. While it does have a sleep mode, the ESP32 wasn’t nearly low-power enough to get the battery life that he wanted. With a modular system like this, it can be used in many other applications as well. PowerTimer is one of the entries in our 2026 Green Powered Challenge.
2026-04-27 23:30:10
[Shreeyash] asks an interesting question: how many registers does your CPU have? The answer is probably more than you think. The reason? Modern CPUs — at least many of them — execute instructions out of sequence so they can perform multiple instructions per clock cycle. To do this, they may need to execute instructions that change registers that other instructions are still reading. In addition, you might be writing a result speculatively — a branch might make it where your result won’t wind up in the target register. The answer to both of these problems is register renaming.
The ARM CPU he looks at has many physical registers you can’t see. These get mapped to the registers you use on the fly. So when you read a register in software, you are really getting an underlying physical register. Which one? Depends on when you read it.
The RAT, or Register Alias Table, keeps track of the mapping between physical registers and the register names you use. Not only does this allow the CPU to run operations out of order, but it also lets results sit in unnamed physical registers until the time is right for it to become the real register. As a byproduct, moving one register to another becomes fast since you can just copy the alias of one physical register to another logical register.
Not clear? Try reading the post. There are other ways to get the same result (e.g., reservation stations), but the technique goes way back to mainframe computers. While it didn’t appear right away in microprocessors, modern ones often execute out of order and have to have some scheme to address this problem.
If you build your own CPUs with FPGAs, it is possible to do the same trick. There are also RISC-V variants that can do it.
2026-04-27 22:00:58
When it comes to software developers, there are a few distinct types. For example, the extroverted, chatty type, who is always going out there to share the latest and newest libraries and projects with everyone, and is very much into bouncing ideas off others, regardless of whether they know what you’re talking about. Then there is the introverted loner, who prefers to tackle programming challenges by bouncing things around inside their own minds and going on long walks to mull things over before committing to anything significant.
This leads to interesting scenarios when it comes to management-enforced ‘optimization’ strategies, like Pair Programming. This approach involves two developers sharing the same computer and keyboard, theoretically doubling the effective output by some kind of metric, but realistically often leading to at least one side feeling pretty miserable and disconnected unless you put two of the chatty types together.
As a certified introverted loner developer, the idea of using an LLM chatbot as a coding assistant naturally triggers unpleasant flashbacks to hours of forced awkward pair ‘programming’. However, maybe using an LLM chatbot could be more pleasant because you can skip the whole awkward socializing bit. In order to give it a shake, I put together a little experiment to see whether LLM-based coding assistants is something that I could come to appreciate, unlike pair programming.
Any good experimental setup features clear goals and parameters that define what will be tested and what the expectations are. Obviously I come from a somewhat negative angle into this whole experiment, so to make it easy I’ll be picking two fairly straightforward scenarios for the LLM to assist with:
These are topics that I’m fairly familiar and comfortable with, so that I know what questions I have here, and what I’m roughly expecting as output. I’ll be treating the chatbot for the most part as I would use StackOverflow or nag people on IRC, with my main fear being that it’ll be expecting pleasantries from me instead of brutal and cold professionalism. Ideally it’ll be a step above me hurling profanities at a search engine for clearly willfully misunderstanding what I am looking for.
My expectations are that it’ll have some answers for me for the questions I have about how to do certain aspects of the tasks, and may even produce half-way usable code that I can fairly easily understand and double-check using my usual documentation references.
This just leaves one big question, being which LLM chatbot to pick and how the heck any of it is supposed to work, since I have avoided the things like the proverbial plague.
Although I am aware that everyone who is into using LLM-assisted programming seem to like to promote LLMs like Claude, I’d ideally not be signing up to another service. This pretty much just leaves GitHub Copilot, which I have access to already. I have written about this particular LLM chatbot quite a bit since it was introduced, with my generally negative feelings towards these tools increasingly backed up by research.
Biased I may be, but to be a true scientist you have to be able to set aside your biases for an experiment and accept reality in the face of new evidence. Thus, with all biases and doubts firmly pushed aside in favor of the aforementioned cold professionalism, let’s get down to brass tacks.
My pet project for STM32-related programming has for a while been my Nodate project, involving the use of the CMSIS standard headers and the macros defined therein in order to write things ranging from start-up to running the Dhrystone benchmark and deciphering the various flavors of real-time clocks.
Much of this work entails digging through datasheets, reference manuals and piles of reference code, as well as throwing queries at search engines to see what potentially useful results percolate out of that particular resource. Coming across the trials and tribulations of fellow STM32 developers in forum threads and the like can be both heartening and disheartening, but all of it tends to condense into something that you can use to progress in the project.
Perhaps ironically, the moment that I tried to use the chatbot in the browser I got an error with the GitHub status page indicating that some of their systems are down, including those for Copilot.
This raises another interesting point: regardless of whether an LLM chatbot makes for a good programming partner, a human partner doesn’t generally randomly keel over or become unresponsive in the midst of trying to do some work together. If they do, however, that’s absolutely a medical emergency and you should call 911, 112, or your local equivalent emergency number stat.
Anyway, after waiting for services to be restored, I was eventually able to ask the chatbot how to properly set the clock speed on an STM32F411 MCU, after getting tripped up previously by the need to set the regulator voltage scaling (VOS) in the power control register (PWR_CR). This is a power saving feature whose adjusting is required for hitting specific and clearly power-wasting clocks.
Shockingly, the chatbot happily spits out ST HAL code and ignores the ‘CMSIS’ bit, although you could maybe argue that the ST HAL uses CMSIS inside. But then so does Arduino code for many MCUs.
To its credit, it does mention in a ‘Key CMSIS Requirements’ list that you need to set PWR_REGULATOR_VOLTAGE_SCALE1 yet without further detail on where to set it. There is also the tiny detail that this isn’t even the CMSIS macro, which would be PWR_CR_VOS to set both bits for the full range.
Fortunately we can do the digital equivalent of smacking the chatbot upside the head and tell it to do the thing we asked it to do. This being to provide the real CMSIS version. Doing so results in another gobsmacking moment when it happily spits out code that doesn’t bother to include the CMSIS headers, but simply copies every single used struct definition and more into the code as well, bloating it up massively:
This is of course very annoying when it should have used #define macros, and it clearly can generate include statements based on its inclusion of <cstdint>, but the absolutely deadly sin here is that his code isn’t even functional for an STM32F411, as can be observed here:
I’m not entirely sure where it got the PWR_CR_VOS_SCALE1 thing from, with asking a friendly search engine leading to just a handful of results, one of which is for an STM32F407 that runs at 168 MHz max. This is hilarious in light of the comments right above the code. It makes you wonder what example code it pilfered from.
At this point I could probably continue to pick at this generated code, but suffice it to say that my confidence level in its generated code and overall output hovers somewhere between ‘low’ and ‘bottom of a black hole’. I’m more than happy to flip this particular table, rage quit, and not lose what remains of my sanity.
Although I had intended to also do some fun porting to Ada together with my buddy Copilot of some C++ networking code in my NymphRPC remote procedure call library, I found my nerves to be sufficiently frayed and the bouts of near-hysterical laughter out of sheer disbelief worrisome enough to abort this attempt.
I also do not feel that it’d do much more than hammer home the point that GitHub Copilot at the very least doesn’t make for a good pair programming partner, nor as a programming tool, or a search engine, or much of anything. When the only thing that it got me was having to check its output for very obvious errors and shaking my head in disbelief when I found them, it beggars belief that anyone would voluntarily use it.
When we also got reports that the use of such LLM chatbots are likely to degrade human cognition and critical thinking skills, not to mention the worrisome prospect of cognitive surrender, then it’s probably best to avoid these chatbots altogether.
I also agree generally with Advait Sarkar et al. in their 2022 paper that you cannot really do pair programming as-such with an LLM chatbot, but that it offers something different. Something that’s very different from using a search engine and digesting various articles and forum posts along with reference material into something new.
Thus, after using an LLM chatbot for some coding ‘assistance’ I’ll be happily scurrying back to my boring references and yelling invectives at search engines.
2026-04-27 19:00:04
Although the game Pizza Tycoon – known as Pizza Connection in Europe – probably doesn’t ring a bell for many folk, this 1994 DOS title is special enough for [cowomaly] to write an open source engine to bring it into the modern age as Pizza Legacy. Along the way, some questions popped up, such as how to animate the little cars that you see driving around in the simulated city and how the heck this was done back in the day on a 25 MHz 386 CPU.
On today’s GHz+, multi-core CPUs, we can just brute-force shovel pixels, sprites, and even 3D models around without a second thought while dedicating an entire core to pathfinding and other algorithms. Naturally, the original game developers had no such luxury. To understand how this animation was originally achieved, [cowomaly] had to dive into the assembly code of the original game.
The original algorithm was very simple: each road tile has at least one direction associated with it, so that a car that is on such a tile knows which direction it can travel, essentially creating a grid of one-way roads. When there’s a crossing, a random direction is picked, with the extra rule that you cannot do two consecutive turns in the same direction, presumably to keep cars from going around in circles.
Meanwhile, collision detection is simply a matter of checking the list of cars for a potential collision and not moving said car if it’s the case. This check is also optimized to take the road directions and one-way nature into account, with a 10-tick wait if there’s a block. Amusingly, this seems to enable the formation of brief traffic jams to add to that feeling of realism.
Although not a perfect algorithm and with some small bugs due to unchecked conditions with collisions, it’s hard to deny that the effect is very natural car movement, something that games like Sim City likely used as well.
2026-04-27 16:00:00
We use CAD packages in our 3D work, and it’s likely that many of us have become annoyed by the limitations of controlling the view of a 3D object using a 2D interface, our mouse. Joystick-like 3D controllers exist for this purpose, but [David Liu] found them inconvenient. He tried a trackball, but that didn’t improve matters. His response was to take the trackball and change the way it controlled the software, turning it from the equivalent of a ball rolling over a surface to a ball representing the object on the screen itself. He can turn and rotate the object intuitively just by moving the ball.
He started with a Kensington off-the-shelf trackball and adapted its electronics and handy twin optical sensors such that it worked in the required fashion. There was a lot of iterating and tuning to get the control feeling right, but he’s ended up with a peripheral that replaces both mouse and 3D joystick, and leaves the other hand free for those keyboard shortcuts.
He’s making a go of it as a product called the Rotatrix, which is definitely worth a look. But we know the Hackaday community, and we’re sure this will have given some of you ideas as to other new ways to control your CAD models. Here’s to a new era of useful peripherals!
