I was going to try and put together a barebones parallel port-based eeprom programmer, but I figured since I've never truly tested various parts together yet, that I'd try throwing together some actual physical circuits to make sure I had the workings of some of my IC's down. And it's good I did, because I totally overlooked a tiny circle on a datasheet in the one I'm gonna post about today, which made me spend a good ten minutes just trying to figure out why it wasn't working correctly. Imagine trying to figure out the problem once I had built something much more complicated . . ! And since I thought some folks might be interested in some simple electronics, I decided to "document" it a little more than I usually might have.

Anyhoo, this circuit uses a 74LS393, which is a dual 4-bit binary counter, sometimes referred to as a ripple counter. It's the black chip in the center of the picture below. I only used one side of it, since as you can see, even just using 4 LEDs starts to lead to clutter on such a small breadboard. Since it's a dual counter, you can actually cascade the two counters together, making a single 8-bit counter if you want, or just use it as two seperate 4-bit ones by default. And since it's a binary counter, it counts, you guessed it, in binary.

To see how that works, check out a video I put on Youtube made from my digital camera. Looks like shit (it wasn't even dark in my room!), but you can see the LEDs, and that's all that really matters. Starting with no lights, you have the number "0", and when all four lights are on, you have the number "15". If you want, you can count along with each LED change, and you can see how binary counting works. Each LED represents a binary "1" when on, and of course "0" when off. If I cascaded the other side of the IC to create an 8-bit counter, it'd be able to count from 0 to 255. Note that that makes 256 possibilities, just like a byte you use in terms of storage on a PC. Same thing, since the computer handles your data in binary.

Mind you that the counter itself doesn't actually count automatically like you're seeing in the video. It's being "clocked" by the parallel cable you see sitting to the right, where I'm emitting a clock pulse once every second from my PC, which triggers the counter to do its thing. It's all powered by 5v, being stepped down by a voltage regulator from a 12v AC adapter.

There's really not much else to the circuit, aside from some resistors to limit current/voltage to the LEDs (to keep from burning them out), and one to "pull down" the counter reset pin. That means I'm setting the reset pin of the counter chip to the "off" position by connecting it through a somewhat strong resistor to ground. If I connected it through the same resistor to the +5v, it'd be called a "pull up" resistor, indicating an "on" position, and therefore resetting the counter. Though doing so would keep the counter in a constant state of reset, unless you added in a pushbutton to do just a momentary reset.

This was actually my mistake that I mentioned earlier, because I misread the datasheet. I thought the reset pin needed to be pulled high (as many do), but eventually I figured it out by trial and error, before realizing my mistake and checking the datasheet again to see why. I also blame the circuit simulator I like to play around with, because the counter they use requires the pull-up I initially attempted with mine.

I also wanted to mess around with a circuit designing application I got, so I whipped up the schematic to the one I've been talking about here, so you can see pretty much how simple it really is on paper, yet how big a mess it can turn into when you start sticking wires in a breadboard. On an actual circuit board though it'd look much cleaner, of course.

I also took a normal photo, since the camera looked so bad in video mode.

lol I made the same thing for ENGR 111 lab with that damn robot last yearr, trouble is, our LS393 was a little.. broken. It spit out random values and while it definite did follow some sequence, it wasn't the binary counter sequence we were after, causing it to do really bizzare things when we tried to rig it to more complicated circuits. Once we borrowed another group's chip though, it worked fine.