Being able to track down a bug in a mountain of source code is a skill in its own right, and it’s a hard skill to learn from a book or online tutorial. Besides the trial-by-fire of learning while debugging your own project, the next best thing is to observe someone else’s process. [Uri Shaked] has given us a great opportunity to brush up on our debugging skills, as he demonstrates how to track down and squish a bug in the Wokwi Arduino simulator.
A user was kind enough to report the bug and include the offending Arduino sketch. [Uri]’s first step was to reduce the sketch to the smallest possible program that would still produce the bug.
Once a minimal program had been produced, it was time to check whether the problem was in one of the Arduino libraries or in the Wokwi simulator. [Uri] compiled the sketch, loaded it onto a ATtiny85, and compared the behavior of the simulator and the real thing. It turns out the code ran just fine on a physical ATtiny, so the problem must have been in the Arduino simulator itself.
To track down the bug in the simulator, [Uri] decided to break out the big gun—GDB. What follows is an excellent demonstration of how to use GDB to isolate a problem by examining the source code and using breakpoints and print statements. In the end, [Uri] managed to isolate the problem to a mis-placed bit in the simulation of the timer/counter interrupt flag register.
In a kind of reverse twist on the doorbell, [TheStaticTurtle] whipped up a system to mute his computer’s microphone whenever someone opens the door to his room. He lives in France, where the government announced a strict lockdown last Friday. Like many university students around the world these days, he is now forced to take online classes. Even though he has his own room, occasionally someone will barge in and announce something, often to [TheStaticTurtle]’s embarrassment. When his classmates suddenly heard “Do you want some pie?” the other day, it was the last straw.
His first decision was to sense the door opening with a magnet and sensor, which he stuck to the door and frame with hot glue. He then ran a long cable to his desk, where it connected to an ATTiny 85 with a DigiSpark boot-loader. He wrote firmware to simulate special key combinations, which were then registered with his audio routing software Voicemeeter Potato. We presume he isn’t using an external mic, in which case muting might have been easier to accomplish with a hardware switch. All in all, this is a pretty clever and timely hack. Should you be in a similar predicament and want to try this out, he’s published the source code on GitHub.
When we last saw [isaac879]’s levitating RGB time fountain, it was made of wood which meant that it would absorb water and didn’t really show off the effect very well. His new version solves this problem with an acrylic case, new PCB and an updated circuit.
Like the original, this project drops water past strobing RGB LEDs creating an illusion of levitating, undulating colored water droplets. The pump at the top creates the droplets, but the timing has a tendency to drift over time. He thus implemented a PID controller to manage the pump’s drip rate, which was done by having the droplets pass by an infrared diode connected to an ATTiny85. The ’85 used the diode and PWM to control the pump motor speed and communicated to the Arduino over I2C.
The video shown below shows the whole process of designing and building the new time fountain. Everything from circuit and PCB design to 3D printing to assembly is shown along with narration describing what’s going on in case you want to build one yourself. If you do, all the files and components required are listed in the info section of the video.
There’s more that [isaac879] wants to do to improve the time fountain, but V2 looks great. It’s sleeker and smaller than the original and solves some of the design issues of the first. For more inspiration, check out some of the other levitating water fountain projects that have been posted over the years.
The circuit is nothing wild – an ATtiny85 microcontroller interfaces a handful of buttons and LEDs to handle the basic Simon gameplay. The real value is in [APA]’s retelling of the development process. It’s an accurate recounting that makes us relive some of our own follies of early projects. There’s the confusion between SMD and through hole versions of the same part, forgotten pull up resistors, as well as hours lost trying to figure out why a chip won’t write, only to learn the bootloader hasn’t been burned yet.
In the end, [APA] was able to push through a rush order and deliver the gifts on time, despite the many pitfalls along the way. The final game provided some laughs around the dinner table at Christmas, so we’d say the mission was definitely accomplished.
While the current generation of smartwatches have only been on the market for a few years, companies have been trying to put a computer on your wrist since as far back as the 80s with varying degrees of success. One such company was Seiko, who in 1984 unveiled the UC-2000: a delightfully antiquated attempt at bridging the gap between wristwatch and personal computer. Featuring a 4-bit CPU, 2 KB of RAM, and 6 KB of ROM, the UC-2000 was closer to a Tamagotchi than its modern day counterparts, but at least it could run BASIC.
With extremely limited published information, and no toolchain, [Alexander] did an incredible job of figuring out the assembly required to interact with the hardware. Along the way he made a number of discoveries which set his plans back, such as the fact that there is no way to directly control individual pixels on the screen; all graphics would have to be done with the built-in symbols.
The culmination of all this hard work? Playing Tetris, naturally. Though [Alexander] admits that limitations of the device’s hardware meant the game had to be simplified a bit, he’s almost certainly having more fun than any of the UC-2000’s original owners did with this device. He’s setup a GitHub repository for anyone who wishes to join him in this brave new world of vintage wrist computing.
In the strongman game, you smash a lever with all your might using a hammer. A puck on the other end of the lever then shoots up a tower, hopefully high enough to hit a bell, winning you a prize. In [avishorp]’s games the puck, tower and bell are all replaced with an LED strip. In the swipe game, the faster you swipe your hand sideways over two optical proximity sensors, the higher the LEDs light up. In the drum game, the speed with which you drum on a rubber disk with embedded accelerometer, the higher the LEDs light up. The chase and response games both involve buttons that you have to rapidly hit, to similar effect.
For the brains, each game is controlled by an Adafruit Trinket board. [Avishorp] chose to use the PlatformIO IDE instead of the Arduino IDE to write them, preferring its modern editor, but he didn’t like that it doesn’t print and that it doesn’t tell you the final file size. The latter issue caused him to overwrite the bootloader, something that he understandably considered a major inconvenience.
Check out his page for more details, Fritzing diagrams, links to code, and all game videos. Meanwhile we’ve included clips of the drum and swipe games below.
And if it’s more carnival games you’re looking for, how about this adult-sized Sit ‘n Spin made using a rear differential and axle assembly out of an old car or truck. Or maybe you prefer something less likely to make you woozy, in which case you can try fishing with the Bass Master 3000.
[Mitxela] wanted to build a different kind of mouse, one that worked like an Etch-a-Sketch toy with one X knob and one Y knob. Armed with some rotary encoders and a microcontroller, that shouldn’t be hard. But when you use a pin-limited ATtiny85, you are going to need some tricks.
The encoders put out a two-bit Gray code and close a button when you depress them. Plus you need some pins for the V-USB stack to handle the USB interface. [Mitxela] decided to convert the encoders to output analog voltages using a simple resistor DAC. That would only require two analog inputs, and another anlaog input could read both switches.
One problem: there still wasn’t quite enough I/O. Of course, with AVRs you can always repurpose the reset pin as an analog pin, but you lose the ability to program the device at low voltage. And naturally, there’s a workaround for this too, allowing you to keep the reset pin and still read its analog value. You just have to make sure that value doesn’t go below about 2.5V so the device stays out of reset. Once that was in place, the rest went easy, as you can see in the video below.