a sad realization…

When you find and fix ten bugs, you get the feeling that you’re close to making it work. But the sad truth is that you probably have ten more to find… and then fix!

gaming platform v1 – the software (top-level view)

Being impatient (apart from lazy) the first thing I wanted to do with the software was to get the LED matrix show something… Anything! So I started working on a very simple routine, that would scan the matrix (row by row) and “draw” a vertical line on the first column. Afterwards, using the overflow interrupt of an appropriately configured timer, I made sure that routine would execute about 100 times per seccond. The first version of my programm was ready. Of cource, it was still very very small and simple. Anyway, it worked (almost) immediately and I was ready to move on. The routine I had written could only draw a line. What about a letter or a whole message? I couldn’t possibly hardwire everything in that subroutine. It wouldn’t even be elegant and I like elegance The subroutine controlling the matrix should be able to read data from someshere else and drive the matrix appropriately. Thinking about this, I came up with the idea of creating a frame buffer: A place where I would describe the condition of every LED of the matrix. My subroutine would read that data and drive the LEDs accordingly. After thinking about this, I was on fire! The ideas were storming in one after another…

One step at a time…

Here is the source code and the hex file –ready to be burnt onto the chip.

gaming platform v1 – the hardware

As I said –or did I conviniently forgot that?– my skills in PCB design and circuit etching are very poor. This is why my “gaming platform” was constructed on a proto board This is also why I have no schematics to share. Anyway, I have plenty of shots and if you’re really interested (and tolerant with my being lazy) you will very soon know everything there is to know about the circuit. Take a look at the board with the LED matrix removed…

One could divide the circuit in four sections: matrix driving, button control, μC programming header and power. Let’s examine them one by one. Let’s start with the one responsible for the driving of the LED matrix…

Things are pretty straightforward here. The two little sockets in the picture –above and below the μC– were cut off from a standard (machine drilled) PDIP socket. This is where the LED matrix is plugged. As you can see, all pins of the LED matrix are directly connected to the pins of the μC. Actrually, there is only one I/O pin of the μC that is *not* connected to the matrix. That’s the upper-right one, which is used for the control of the buttons. We’ll come to this later. The other three pins that are not connected on the matrix, are those for power and reset control of the μC (Vcc, Gnd and Reset). Anyway, if you are wondering about the connection of the μC and the matrix, there are some really ungly traces underneath the proto board. I created them using the soldering iron and plenty of tin. Believe me, they are very ungly and I will show you no photos. Let me take the oportunity here and tell you that the other side of my board is… well… the dark one! I will give you many reasons to hate my board, sticking on the good side

The programming header (that is ISP header, for In-System Programming header) pins are connected to the appropriate pins of the μC. The connection is achieved with a bunch of white wires, routed as the colored lines indicate. If you wish to know the pin-out of the header, take a look at section 6 of this datasheet. Naturally, the header pins are numbered and the programming cable (coming from the programmer hardware) has to be connected with the correct orientation. For that reason the cable has a red stripe indicating pin 1. The red stripe should be aligned with the black one on the right side of the board’s header. You probably can’t see it in this shot, but you can spot it in the first one. It’s more like a black stain on the right side of the header, but I actually put it there on purpose In this section, although dimmed in the photo, belongs the blue polyester film capacitor, just below the header. That was put there to stabilize the power coming from the programmer, when programming the μC. I don’t think it was really necessary, but I put it anyway…

This is the most simple section of the circuit and probably the dumbest of all. Between the μC and the 2-pin header I put for powering the board, I interjected a rectifying bridge. By doing so, the polarity of the power source would not matter. The diodes of the bridge would guarantee that the μC would always have Vcc on the yellow line and Gnd on the green. Pretty clever, huh? Unfortunatelly there is a catch here… The bridge’s diodes suppress the input voltage by 0,7V each. This translates to a total of 1,4V drop of incoming voltage. Great! Now I need an extra battery…

This is the most interesting part of the circuit. The four buttons are simple SPST (for Single Pole Single Throw) tactile swiches. One of the poles of each button is connected to the I/O pin I refered to previously (notice the green line). It’s the only I/O pin of the μC, that is not connected to the LED matrix (from now on, I’ll refer to it as the “control pin”). When the μC wants to read the buttons, sets the control pin high (logic 1). Then, the four I/O pins connected to the output of each switch are defined as input pins and set low (logic 0). Just after that, the μC reads the state of the four input pins… If the user is pushing any buttons, the corresponding input pins will be pulled high due to the connection to the control pin. Otherwise, all pins’ state will low. In other words, if the user is pushing any buttons, the μC will read a logic 1 from the corresponding pins. Otherwise, the μC will read a logic 0 from all of them…

Are we forgetting something? The four buttons are multiplexed with the LED matrix. The same pins that read the state of the buttons are also used for driving the matrix. For this to work, the program running on the μC is driving the matrix (drawing what has to be drawn) for a short time, then stops and reads the buttons’ state for an even smaller amount of time, then drives the matrix again, then stops and reads the buttons’ state again and so on. This is happening REALLY fast! No human could press a button that fast, that the μC would not have the time to detect the pressed button. So, what are the diodes there for?

Imagine a situation, where the μC is driving the matrix and has set high (logic 1) one of the pins that are also connected to the buttons. If at this time the user is pushing the button connected to that pin and –simultaneously– another button, the two pins will be connected through the pressed buttons. Now, if the other pin was set low (logic 0), we’ll have a nice short circuit :-S Of cource, the μC’s pins can source and drain a certain amount of current, which *in most cases* is well below the amount of current the power supply can source. This means that *in most cases* the μC will not reset and it will keep operating the way it was meant to. But what about the matrix LEDs? The short circuit will probably have unpleasant effects, as some LEDs that were meant to be on will go (partially) off and vice versa…. The diodes are there to prevent this situation. No matter what’s happening to the buttons, there will never be a short circuit between any pins! That is because the diodes allow current to flow from the pins and towards the buttons, but not the other way around

I told you I’m lazy! This is a representation of the circuit on a breadboard. I have omitted the ISP header and the power connections, but I guess you can figure them out easily. If you decide to build it on a breadborad (something I strongly discourage you to do), you’ll need eight jumper wires –the six you see in the sketch and two more for powering the μC. By the way, if you intend to use my code, you will also need the specific LED matrix I used (TOM-1088BMR), which I got from futurlec.

Notes:

1. The matrix’ LEDs are directly driven from the μC pins. This is bad practice! First of all, the combination of an over-powered μC and a poorly written program could easily reduce the life span of the LEDs (or even burn some of them out). Apart from that, controlling a whole row (or column) using one pin, means that the LEDs belonging to that row (or column) will share the maximum current the pin can source (or drain — this depends on the interconnection of the LEDs in the matrix). So, when you have two or three LEDs switched on on the same row, they will be more bright than when you have seven or eight LEDs switched on. This is pretty ungly and I knew from the beginning it would happen, but the challenge was to make a more complex and smarter program that could fit in 1Kb –not a better circuit.
2. If you’re wondering about the two green LEDs, they were put there for fun. Sometimes, my taste gets really twisted and even beats my laziness
3. The blue polyester film capacitor (on the left side of the μC) along with the nearby resistor, form a soft-reset network. It’s not really necessary…