Row driving

Row driving is accomplished by using a 4->16 multiplexor switching 16 mosfets which drive each row. Each mosfet is rated at something around 200-400mA which should be more than enough to drive 40 LEDs at a 1/16th duty cycle at full current with all of them on. Current limiting is accomplished by the column driving/sinking chips and will be explained next.

Column Driving/Sinking

Current capacity was a big problem with my previous designs using the 74HC595 chips for column sinking. The chips could only sink so much current at once and would start limiting it at a certain point. This lead to unequal brighness and low visibility. I found a solution to this on one of the pages at this site. It showed a demonstration of a display using an MBI5027 shift register to sink columns. This shift register is capable of sinking 50mA per output pin and limits current by use of a set resistor on one of the pins. It also has short/open circuit fault detection. The only problem with this chip is that it isn't very available. The only place I could find it was on this King Fish electronics or something like that. They used UPS for shipping which was a minimum of $10. I was not about to pay $10 shipping for a few $1 chips, so I put out a plea for help on one of the various forums I troll and got a response about this MAX6979 chip from Maxim-Dallas. It does the exact same thing as the MBI5027 and even adds a watchdog so that it blanks the display if serial input stops for over a second (could save my modules if my controller crashes). What's more, it was only $0.26 more than the MBI chip and it was sampleable. I have not yet gotten this chip (I think it is in the mail) and I can't wait to try it out.

The shift registers are arranged in a chain and data is entered rightmost pixel first. The previous row's data is displayed even during clocking and isn't replaced until an entire new row is ready.

The Display

I have spent most of my time debugging the software for this. Until I got an oscilloscope this was very slow going and my code was very error prone. Even with an oscilloscope I tend to make mistakes like not blanking the previous row before turning on the next one (causes ghosting) or clocking out the data backwards. So far I have only experimented with going right to left, but as I write it has occured to me that arranging the shift registers in the opposite direction and outputting the data left to right would be easier on my mind (and would avoid having to flip my arrays). In either case, the basic sequence this uses to output a row is as follows:

1. Clock out the new row with the rightmost bit first
2. Turn off the row currently on off
3. Shift all the new data into the latches on the shift registers
4. Turn on the new row and repeat step 1 with the next row keeping this row turned on during step 1

Switching steps 3 and 4 causes slight ghosting and that was probably one of my larger mistakes when I was first writing the code a while back. The rows are stored as two arrays of 40 16-bit words using a row mask. Only one array is actually displayed at any given time and the array that is not being constructed with graphics data is being displayed. After the graphics array is constructed the active array switches and the opposite array is writen to. This prevents screen flicker, makes animation smoother, and allows for a constant framerate without fear of interrupting a write and getting something funky displayed for a frame or so. This is a commonly used technique that I first learned when programming BASIC with I was about 10 or so and applying it to this is not difficult as long as I have the memory.

Adding "color" to the pixels is one of the possible features of this. Instead of having each array be 40 16-bit words it will have 40 32-bit words. This doubles the memory requirement and starts to approach the memory limit of the 18F4550 (remember there are two arrays). The row displaying sequence will be quadrupled so that instead of displaying 16 rows it effectively displays 64 rows, 4 for each actual row. This shouldn't reduce the overall brightness of the screen since all it does it add PWM to each individual row with 2-bit resolution giving 4 "colors".

Data will be written to the display using an 8-bit master-slave parallel bus between the display board and the clock board. I have not yet come up with a control sequence, but the basic functionality will be like the Parellel Slave Port that I have seen on a few higher end microcontrollers. I am leaning toward something along the lines of the following for a control sequence:

1. Master sends commands that specify where to start writing data and how much data will be written
2. Master enters data mode and writes raw data to the bus. The address pointer is incremented with each byte sent
3. After the specified number of data bytes the slave enters back into control mode
4. The master can either issue more writing commands or send a "refresh" command that will switch which array is written to and display whatever data it has just written.

The program is going to be interrupt driven with the row displaying on a timer so that the framerate is constant. Switching arrays will only happen after an entire frame has been displayed, so there will have be a few flags between the bus "process" and the display "process" to facilitate this. Hopefully the controller won't be overwhelmed, but I plan on running at the full 12MIPS using the fastest crystal possible and the PLL.

Obviously, most of this code is not yet written but I do have a good idea of what I have to write and after getting a hardware prototype working it sould be relatively easy to put this code in.

The Clock iteself

I haven't even started writing the software for this, but it will be probably even more complex than the display software. I plan on using one of the 24HJ series of PIC microcontrollers to handle this to try and process as much as possible. Some features that this clock will definately have and I have already figured out are as follows:

• Timekeeping using a RTC with a supercap as a backup power supply
• Multiple alarms (maybe up to 32 or so?)
• Number changing animations
• Menu system

Other possible features that I could add given enough time:

• Multiple fonts for numbers
• Use an SD card with uncompressed WAV files on it to get alarm "ringtones" (I have done something like this before, but never using an SD card or actual WAV files...only arrays of numbers)

Outlandish features that could only be added if my current programming experience is significantly increased:

• Get and read RSS feeds using wifi
• Sync a calandar with a computer wirelessly
• Who knows...