The archetypal “blink an LED” is a great starter project on any platform, but once the bug takes hold that quickly turns into an exploration of exactly how many LEDs a given microcontroller can drive. And that often leads to Charlieplexing. A quick search yields many copies of The Table describing how many LEDs can be driven by a given number of pins but that’s just the most rudimentary way to describe it. Way back in 2013 [M Rule] developed a clever trick to describe the number of LED matrices which can be driven by a Charlieplexed array of a given size that makes this process much more intuitive. The post may be old, but we promise the method is still fresh.
[M Rule] was specifically looking to drive those big, cheap single color LED matrices which are often used to make scrolling signs and the like. These parts are typically a matrix of LEDs with a row of common cathodes and one of common anodes. Internally they are completely dumb and can be driven by row/column scanning, or any other way a typical matrix can be controlled. The question is, given known matrix sizes, how many can be driven with a a number of Charlieplexed LED drive pins?
The first step is to visualize the 1D array of available pins as a 2D matrix, as seen to the right. Note each numbered pin is the same on the X and Y, thus the black exclusion zone of illegal drive pin combinations slicing across the graph (you can’t drive an LED connected to one pin twice). The trick, if one were to say it resides in a single place, would be titling the axis anode and cathode, representing two “orientations” the drive pins can be put in. With this diagram [M Rule] observed you can simply drop a matrix into the array. If it fits outside the exclusion zone, it can be driven by those pins!
To the left is what this looks like with two 8×8 matrices, one connected between pins 1-8 and 9-16, the other connected between 9-16 and 1-8. This isn’t terribly interesting, but the technique works just as well with single LEDs and any size matrix, including 7-segment displays. Plus as long as an element doesn’t overlap itself it can wrap around the edges leading to some wild visuals, like 14 RGB LEDs on seven pins to the right.
The most extreme examples are pretty exotic. Check out [M Rule]’s post for the crown jewel; 18 pins to drive six 5×7 modules, six 7-segment displays, 12 single LEDs, and 18 buttons!
If this color coded diagram seems familiar, you may be remembering [openmusiclabs]’ excellent diagram describing ways to scan many of buttons. Or our coverage of another trick of matrix topology by [M Rule] from a few weeks ago.
In the practical world we live in, PCBs are often rectangles (or rectangles with rectangles, it’s just rectangles all the way down). When a designer goes to schematic capture things are put down on nice neat grid intersections; and if there isn’t a particular demand during layout the components probably go on a grid too. Routing even the nastiest fractal web of traces is mostly a matter of layers and patience. But if the layout isn’t being done in a CAD tool and needs to be hand assembled free-form this isn’t always as simple. [M Rule] had this very problem and discovered a clever solution, turning things diagonal.
They changed the fitness criteria to the optimization problem that is controlling a lot of LEDs. Instead of minimum pins to drive the goal became “easiest assembly”, which meant avoiding wires snaking back and forth across the layout, a big source of frustration in a big Charlieplexed design. The observation was that if they turned the a rectilinear LED matrix by 45° and wrapped each connection around at the edges it formed what was essentially a large multiplexed matrix. The topology is pretty mind bending, so take a minute to study the illustration and build your mental model.
It looks a little strange, but this display works the same way a normal multiplexed display does but with the added benefit that each trace flows from one side to the other without turning back on itself at any point. To light any LED set the right row/column pair as source/sink and it turns on!
What if you actually need a rectangular display? Well that’s no problem, the matrix can be bent and smooshed as desired to change its shape. At the most extreme the possible display topologies get pretty wild! We’re sure to try thinking laterally next time we need to design an unusual display, maybe there is a more efficient matrix to be found.
So you’re building a new mechanical keyboard. Or attaching a few buttons to a Raspberry Pi. Or making the biggest MIDI grid controller the world has ever know. Great! The first and most important engineering question is; how do you read all those buttons? A few buttons on a ‘Pi can probably be directly connected, one for one, to GPIO pins. A mechanical keyboard is going to require a few more pins and probably some sort of matrix scanner. But the grid controller is less clear. Maybe external I/O expanders or a even bigger matrix? Does it still need diodes at each button? To help answer these questions the folks at [openmusiclabs] generated a frankly astounding map which shows, given the number of inputs to scan and pins available, which topology makes sense and roughly how much might it cost. And to top it off they link into very readable descriptions of how each might be accomplished. The data may have been gathered in 2011 but none of the fundamentals here have changed.
How do you read this chart? The X axis is the number of free pins on your controller and the Y is the number of I/Os to scan. So looking at the yellow band across the top, if you need to scan one input it always makes the most sense to directly use a single pin (pretty intuitive, right?). Scrolling down, if you need to read 110 inputs but the micro only has eight pins free there are a couple choices, keys E and F. Checking the legend at the top E is “Parallel out shift register muxed with uC” and F is “Parallel in shift register muxed with uC“. What do those mean? Checking the table in the original post or following the link takes us to a handy descriptive page. It looks like a “parallel out shift register” refers to using a shift register to drive one side of the scan matrix, and “parallel in shift register” refers to the opposite.
Continue reading “What’s The Cheapest Way To Scan Lots Of Buttons?”
The HC-SR04 sonar modules are available for a mere pittance and, with some coaxing, can do a pretty decent job of helping your robot measure the distance to the nearest wall. But when sellers on eBay are shipping these things in ten-packs, why would you stop at mounting just one or two on your ‘bot? Octosonar is a hardware and Arduino software library that’ll get you up and running with up to eight sonar sensors in short order.
Octosonar uses an I2C multiplexer to send the “start” trigger pulses, and an eight-way OR gate to return the “echo” signal back to the host microcontroller. The software library then sends the I2C command to select and trigger a sonar module, and a couple of interrupt routines watch the “echo” line to figure out the time of flight, and thus the distance.
Having two sonars on each side of a rectangular robot allows it move parallel to a wall in a straightforward fashion: steer toward or away from the wall until they match. Watch the video below for a demo of this very simple setup. (But also note where the robot’s 45-degree blind spot is: bump-bump-bump!)
Continue reading “Octosonar Is 8X Better Than Monosonar”
[Jeff Joray] wrote in to show off this perpetual Pong device he built. The six by ten LED matrix acts as a game board for Pong but there are no controls. The board simply plays against itself. It’s pretty much a pong clock without the clock.
The brain of the device is a PIC 16F684 which drives the six rows of the display directly. He went with a decade counter (CD74HC401) to scan the rows one at a time. Now what would you expect to find on the underside of this hunk of protoboard? A rat’s nest of point to point wiring? If so you’re going to be disappointed. [Jeff] spent the time to generate a schematic and board layout in Eagle. While at it, he knew he was going to be using protoboard so the artwork is designed to use solder bridging as much as possible. What he ends up with is one of the cleanest mutiplexed one-off projects you’re going to find. See it in action after the jump.
Continue reading “Perpetual Pong”
Reading from a large number of inputs, like this piano keyboard, can be tedious. Even when multiplexing there’s a lot to keep track of. But if you choose the right microcontroller, you may have hardware assistance. Here’s an ATmega640 is using it’s external memory interface to read the key matrix.
You may remember the Open Music Labs article about reading from a shift register using just one pin of a microcontroller. This time around a shift register is still used, but instead of pulling in a long line of parallel inputs, the switches are multiplexed to reduce the number of I/O pins used to read them.
A 74HC573 is used to facilitate the multiplexing. We won’t go into how that part is accomplished; there’s a separate post that explains the process. What’s unique here is that the XMEM peripheral of the AVR microcontroller is used to grab the data. This is intended for external memory chips, but if you get the timing just right, it greatly simplifies reading in a matrix of up to 128 inputs.
When [Dave] installed hardwood flooring in his house, he needed a solution to help automate the monotonous task of routine sweeping. Rather than go out and buy one of the many existing automated sweep robots out there, he decided to use his passion for LEGO Robotics to design and build a NXT based Swifferbot he calls Pulito. His version implements all the important features such as object avoidance using bump sensors, an IR beacon used to automatically return to the charging station, and a photoresistor to monitor the charge of the battery. [Dave] also includes a nifty LEGO sensor multiplexor, allowing him to save on I/O ports, which is almost worth sharing by itself.
Videos after the break.
Continue reading “Pulito: The LEGO Roomba”