When it comes to measuring time on microcontrollers, there’s plenty of ways to go about things. For most quick and dirty purposes, such as debounce delays or other wait states, merely counting away a few cycles of the main clock will serve the purpose. Accurate to the tens of milliseconds, they get the average utility jobs done without too much fuss.
However, many projects are far more exacting in their requirements. When you’re building a clock, or a datalogger, or anything that relies on a stable sense of passing time for more than a few minutes, you’ll want a Real Time Clock. So called due to their nature of dealing with real time, as we humans tend to conceive it, these devices take it upon themselves to provide timekeeping services with a high degree of accuracy. We’ve compiled a guide to common parts and their potential applications so you can get things right the first time, every time.
[Liang] began the project after being dissatisfied with existing robot animals they’d seen online. Rather than simply attempt to build a cat from memory, instead, [Liang] decided to first study a real cat to ensure the resulting robot would bear real resemblence to its biological inspiration. [Liang]’s focus was on the skeleton, as replicating the way the real skeleton worked would create a robot with more authentic movement.
Using 3D printed parts and many, many servos, we think [Liang] has done an admirable job at creating a basic robot cat platform. With an ESP32 running the show, the cat can be posed using a web interface to control the servo positions of its various joints. We look forward to future upgrades that enable fluid movement and other capabilities, particularly involving the onboard camera.
I miss my friend Dave DiOrio. He was a chip designer in the 1980’s, which made him one of the true wizards back then. We met my first day when I started at Commodore Business Machines, though my paycheck said MOS Technology on it.
MOS Technology was the birthplace of the venerable 6502 microprocessor, the VIC video chip, and the SID sound chip to name the really famous ones. It also brought us the TED Text Display chip, a whole boatload of Amiga chips, and several other chips that almost did what we wanted them to do.
I worked with magicians whose stock and trade were comprised of half-part quantum tunneling effect and half-part straight-up logic implementation. These magicians weren’t bound by the number of pins available for TTL logic, not like us lowly hardware engineers who had to string 14 and 16 pin chips together to do any real lifting.
Below the spartan offices where the designs were drawn lived the dragon otherwise known as a chip fab, short for integrated circuit fabrication plant. This beast ate sand and made wafers; slices of almost pure silicon in crystalline form with all kinds of intricate things craftily grown on top of them.
Memory Lane: Touring the Abandoned MOS Headquarters
MOS Technology was started in 1969 by Allen Bradley but only became the MOS that I think of when I talk about the good old days when Chuck Peddle and a bunch of cohorts from Motorola, including Bill Mensch, swept in and produced the 6502 microprocessor, which resembled a particular Motorola processor quite a bit, in fact a lot. Lawsuits followed.
Meanwhile the 6502 was taking over several industries as the go-to processor for everything from medical equipment to microwave ovens to home computers. It was while designing home computers that I met Dave while standing above a chip fab. I can still remember the smell of that dragon farting below our feet… its an understatement to say I miss those times.
A couple of years ago I had a chance to return to the old stomping ground as it were, and set foot (legally) inside of MOS headquarters in Norristown, PA — which had become CSG (Commodore Semiconductor Group) by the end. The basement was dirty and flooded and yet we found wafers, one from one of the computers I worked on.
The ground floor was dark and quiet, I stood at the dirty glass entrance doors looking out at a drab street and I quickly moved on before I got hit by some sort of self evident metaphor for life that would have been annoying.
The second floor was where our offices had been. The hot press of design deadlines has long since left this space, now all there is to see is the golf course out the window and a little camp fire someone had made. I got to show this video to Dave, including the view looking out his old office window, and we both smiled at the thought that it was now 35 years later.
Dave has since passed away, the world has one less wizard and as the video shows, the dragon has long since gone quiet.
Sometimes a problem is more important than its solution. Humans love to solve mysteries and answer questions, but the most rewarding issues are the ones we find ourselves. Take [Surjan Singh], who wanted to see if he could calculate the weight of his Saab 96. Funny enough, he doesn’t have an automobile scale in his garage, so he had to concoct a workaround method. His solution is to multiply the pressure in his tires with their contact patch. Read on before you decide this is an imperfect idea.
He measures his tires with a quality gauge for the highest accuracy and pressurizes them equally. Our favorite part is how he measures the contact patch by sliding a couple of paper pieces from the sides until they stop and then measures the distance between them. He quickly realizes that the treads didn’t contact the floor evenly, so he measures them to get a better idea of the true contact area. Once he is satisfied, he performs his algebra and records the results, then drives to some public scales and has to pay for a weigh. His calculations are close, but he admits this could be an imprecise method due to an n-of-one, and that he didn’t account for the stiffness of the tire walls.
Strong opinions exist on both sides about OpenSCAD. The lightweight program takes megabytes of space, not gigabytes, so many people have a copy, even if they’ve never written a shape. Some people adore the text-only modeling language, and some people abhor the minimal function list. [Johnathon ‘Zalo’ Selstad] appreciates the idea but wants to see something more robust, and he wants to see it in your browser. His project CascadeStudio has a GitHub repo and a live link so you can start tinkering in a new window straight away.
The Nintendo 64 made a big splash when it launched in 1996, not least of all for its innovative controller. Featuring a never-before-or-since seen trident design, and with an analog stick smack bang in the center, it changed what gamers expected from consoles from that day forward. Of course, those controllers are now much worse for wear, and technology has moved on somewhat. The latest development from [Ryzee119] aims to rectify this somewhat.
The result of that work is USB64, a tool designed to allow the use of USB controllers on the Nintendo 64. Using a Teensy 4.1, it builds upon earlier work to get the Xbox 360 controller working on the platform. However, the feature set has been greatly expanded, covering almost any use case imaginable. Mempacks are now efficiently emulated, and save files can be backed up to a PC via SD card. Additionally, the GameBoy Transferpak is emulated, meaning data can be transferred between GameBoy ROMs on an SD card and games on the N64. Even the N64 mouse is supported, and can be emulated with a regular USB mouse. Capable of doing all this for all four players, work is ongoing to increase the number of compatible aftermarket controllers for the utmost flexibility. [Ryzee119] also coded up a useful test ROM for the N64, which is invaluable when debugging controller hardware.
Fiber optics are a great way to transfer huge quantity of data at lightning speed. Thanks to the property of total internal reflection, which allows light to flow through a glass fiber like fluid through a pipe, they can be used for communications at long distances and form the backbone of modern communication networks. However, water is also able to pull off the total internal reflection party trick, and [Mike Kohn] decided to see if it could be used as a communication medium, too.
The experimental setup consists of an ATTiny85 that receives signals over its serial port, and outputs the received bits by flashing an LED. This LED is attached to a plastic tube filled with water. On the receiving end, another ATTiny85 reads the voltage level of a photodiode placed in the other end of the tube. When the ADC detects voltage over a certain level, it toggles a pin connected to the serial RX pin.
Hooking the setup to a pair of terminals, [Mike] was able to successfully transmit 9600 baud serial data through a tube full of water with just an LED and a small microcontroller. To verify the success, he ran the test again with an air-filled tube instead, which failed. In doing so, he proved that the water was doing the work.
