Kevin Cuzner's Personal Blog
Electronics, Embedded Systems, and Software are my breakfast, lunch, and dinner.
Eureka! The Dot Matrix Displays Work!
Running one display block with pixel 0,0 turned off
I have finally managed to get a dot matrix display running full bore without resorting to outrageous voltages such as 18V on 5V logic. I have been working towards this moment for probably 2 or 3 years now.
This uses a pinned version of the hardware described in previous posts and more or less proves that it will work with that hardware with few modifications. The only major difference is that I am not using the same chip for the LED current sink. In the picture on the right it is running at an input voltage of 6.37V@325mA which is regulated down to 5.26V and 4.78V.
One major deviation from the hardware mentioned previously is that the row decoder is running at a slightly higher voltage than the rest of the circuit (5.26V). This is to remedy a problem I noticed with the MOSFETs in which their gates are not fully turned on unless the gate voltage is above the drain voltage. What I ended up doing was running a 5.1V zener off of the input from my power supply to create a higher voltage than the 7805 supplies to the rest of the circuit (including the MOSFETs). This is marvelously ineffecient and seems to be causing the 7805 to heat up, but that also might be from the problem that I will go over next.
The other major deviation is how I am running the column sink driver. I ordered one that I thought was almost the exact same as the one I planned to use on the PCB, but doesn't behave like the datasheet says it should. I ended up having to take away the external resistor and replace it with a direct short to ground. This effectively removed the current cap and now the chip is drawing 120mA by itself (which is bad). In contrast, the chip draws 20mA with a 300Ω resistor, but half of the rows get turned off. This in itself makes no sense since this is the column sink and for something like this to happen it would have to have something to do with the row drivers (i.e. the MOSFETs and accompanying logic), but it consistently shows up when I put a resistor on the resistor pin of the column sink chip. However, if a row starts flickering irregularly all I have to do is increase the input voltage a bit and it goes away. Any ideas as to why this would happen are appreciated (leave a comment).
From a coding standpoint I think I grossly overestimated how hard it would be to strobe this display. The chip is running at 12MIPS and so far is able to render an entire 40x16 buffer at 30fps with a ton of idle time. I have not yet implemented the grayscale dimming functionality, but even that won't add much to the overhead. Looking at my scope I can see that out of the 584uS between rows only ~290uS is actually used for writing to the column sink and switching which row is turned on. This means that my "processor usage" slightly less than 50%. I was expecting it to be significantly more, but now I see that implementing the 8-bit parallel bus which will be the link between this and the "computer" board will be easier than I'd hoped.
The MCC18 built-in libraries
They suck. While waiting for my parts for the clock to come in I have been trying to get my WirelessUSB transmitter to communicate through the USART properly. I ended up discovering that it was having trouble syncing with the start and stop bits and was giving me a bunch of frame errors when receiving, but it had no problem transmitting. I was absolutely puzzled as to why this was happening and I asked around a few forums to see if anyone could shed some light on the subject. One forum (I can't remember which one) said I should try controlling the USART "manually" without using the MCC18 libraries. To my great astonishment, it started echoing back and reading my characters properly without throwing any errors. Obviously, the MCC18 libraries don't work right. I have had similar problems with the MSSP libraries, but I was unable to manually control it at the time because of my lack of experience with it (I could do it now). Basically, I now say: DON'T USE THE MCC18 LIBRARIES
Revision two
After looking at my design of a few days back I decided it definately needed another revision. For one thing, I switced out the serial->parallel chips to a more common chip that I can get off of digikey (497-5746-1-ND) for $3.30 apiece which isn't too bad (it's not the best though...but it will save on shipping). I also got rid of most of that empty space that I was not using and managed to compress the entire thing so that it is as small as it can get unless I drastically change my design.
Dot Matrix revision 2
Major Changes
As you yan see I have moved all of the chips underneath the displays. I had not done this before because I thought the autorouter wouldn't be able to handle it and I would be left with 100 airwires to resolve. However, when I upgraded the chips the package size had to go up from SSOP to SOIC. This drastically reduced the complexity of routing and made it possible to fit everything beneath the displays. I was a bit sad about this change, but I could only find SOIC versions of the more popular chip (I enjoy soldering small chips because of bragging rights).
Another major change is the position of the mosfets. I have moved them from more or less a column into two "blocks" which are more or less symetrical. I had never thought of this before and it made the airwire ratnest much less dense in the long run with being able to position the column sink chips underneath the adjacent dot matrix module. The mosfets I am using are BSS138LT1GOSDKR-ND (say that 5 times fast) and are $0.58 apiece for 20 (they only way I could find them was on digireel, so the price changes with quantity).
The final major change was an error correction. I found that I had accidentally named all of my clock lines CLK. I have probably 4 different clocks and they were all connected together. I had to separate them and that pretty much broke the last design since I didn't feel like layout out the board in exactly that pattern again.
Releasing my designs
I have decided that I am going to publicize my designs if anyone wants them. However, I will not be giving out the eagle files for my own reasons. Eventually I will export the schematic in JPG (I have to clean it up a bit) and I will include the board as gerber and excellon files. This could take time, so don't expect them for a bit.
Fabrication
I am now thinking of how to get this board fabricated. I have found one company, olimex, who will do it for around $40 per board (no minimum quantity) which is really quite cheap. The also allow panelizing and will cut your boards for you if you want, so I might wait until I have the entire clock finished before sending it off for fabbing. The only problem so far is that my board is .3" too wide for their smaller double sided panel. The upgrade is over $100 and adds about 6" on every side to the space which I don't need unless I decided to make two clocks and panelize all the parts into one board. Hopefully it isn't too hard to get these fabricated since I kind of need them to be fabricated before I can do serious testing on my software.
Resurrecting the Dot Matrix Clock
Man, I have been working on this project since probably 2006. This is by far my longest lived project with about 4 different breadboarded prototypes, 2 or 3 different control schemes, 2 differnt types of displays, and 3 different microcontrollers designed for. I think I have settled on a final design and I do have to say that this clock is more like a computer than an actual clock.
Background
A few years back I saw a POV clock made using a PIC16F84 which I thought was pretty cool. The only drawback that I saw at the time was the fact that it depended on moving parts that made noise. I really wanted to make something like that, so I looked into Dot Matrix displays. At first they seemed really expensive and difficult to get, but I eventually learned that surplus sites and eBay had very cheap displays that I could get. I proposed the idea to my mom to see if she would pay for it and she agreed (to a reasonable limit). I expected the project to take 6 months to a year. I was dead wrong. Getting a display to even be bright enough to see was a challange on its own, but eventually I learned enough about how to push LEDs to their limits that I could get a visible display running. Originally I used LPT747R displays, but these turned out to be too dim and even after pumping 18V through my 5V logic (resulting in the literal explosion of a hex inverter, but no damage to any of the other parts strangely) they were still barely visible under normal lighting. I discovered that even though LEDs may seem bright when powered constantly they are dimmed to about 1/16 of their original brightness when ran multiplexed. An added bonus of this is that you can pump about 16 times the amount of rated current through an LED (this reduces the LED life though...and if your display freezes those pixels are shot). The other brightness limiting factor is the maximum current driving capacity of the chips used to supply the current and to sink the current. Using standard 74HC logic didn't work very well since they simply couldn't supply enough current (this is probably why 18V didn't blow up the LEDs...not enough current). It took a while, but I have been able to figure out how to drive enough current through the displays to get them to be bright enough (more on this later). Recently I switched over to some 8x8 dot matrices which have also increased visibility greatly.
The display uses an array of serial->parrallel shift registers driving (now sinking) the rows with either a multiplexor or mosfet array sinking (now driving) the rows. I now use a combination of a multiplexor and mosfet array to drive the rows. The entire system is controlled by a microcontroller (originally a 16F628A, but now an 18F4550). The microcontroller stores two entire screens in memory and displays one at a time. During the displaying process each row is clocked out to a chain of shift registers and once the entire row is out the registers shift their data out to some latches which turn on specific LEDs. The rows are controlled by the microcontroller in some fashion which has varied depending on the current mockup.
The current hardware
The current version of the Dot Matrix clock consists of two main boards: The display board and the controller board. As of this writing I have only completed the PCB layouts on the display board. An 18 pin connector connects the two board. Each board has a microcontroller on it with the display board having a PIC18F4550 and the controller board having either another 18F4550 or a PIC24HJsomethingorother (I haven't decided yet). The displays are 10 8x8 displays arranged into a 5x2 pattern giving me 40x16 pixels to work with. I plan on having 4 brighness levels possible per pixel, but this depends heavily on the amount of memory I will be able to spare for display buffers on the microcontroller. The displays are column-cathode, row-anode so power is supplied to the rows.
The PCB layout as it stands now (and as it will probably look in the next revision more or less) is displayed below. There is quite a bit of unused space, so it is possible that I will upgrade to a 4 layer board and just put the entire clock on one board.
Layout as it stands now
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 Software
As of yet I am not ready to release any of the software for this, but I will give the basics of its operation below. The software is mostly incomplete, but I have most of it thought out.
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:
- Clock out the new row with the rightmost bit first
- Turn off the row currently on off
- Shift all the new data into the latches on the shift registers
- 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:
- Master sends commands that specify where to start writing data and how much data will be written
- Master enters data mode and writes raw data to the bus. The address pointer is incremented with each byte sent
- After the specified number of data bytes the slave enters back into control mode
- 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...
Conclusion
As always, do not take my ideas without asking me first or crediting me somehow. Feel free to use this as a resource for your own projects, but if I see an exact duplicate of my clock out there somewhere that I didn't know about previously it could be bad. The point of this clock is to be unique, so if you end up making a clock based off of information you found here then try to make it unique enough so that it could be distinguished from mine easily.
I am not sure how often I will be able to actually work on this clock, but I will post updates when I reach milestones and such.
Ubuntu Netbook Remix & MS Office
I just got my Aspire One back from Acer Repair (finally) and they managed to fix it this time (third time). I promptly installed ubuntu 8.10 on it to try out Netbook Remix and so far I have to say that I really like it. My screen seems spacious (except for a few programs) and it is easy to see even if light is shining on the screen because of the high contrast of the theme. I don't quite agree with this reviewer with his "fecal brown" statement about the theme. It is more black than the traditional ubuntu orange and the orange that is there is more of a bright orange than a fecal brown.
Netbook Remix with MS Office
Awesome things:
The netbook launcher is probably the best part of this entire package. It works well, looks nice, and doesn't use very many cpu cycles. The framework they used on this (clutter) really has potential in my opinion and if they keep developing applications for gnome with this framework it will probably become the desktop of choice for ease of use alone.
The app switcher with maximus is probably the second best part simply because it takes advantage of the smaller screen resolution. I originally thought that it would be annoying to have just the icon to tell me what the program was, but it really isn't nearly as bad as I thought it would be. It is pretty easy to remember where the icon for the particular window is. Another plus is the fact that the titlebars will take up as much space as possible. Even with long window names (movies on Tudou...looong names) I have not yet managed to get the ... to show up in the title bar.
Not so awesome things:
There isn't very many things I can really see wrong with this except for one bug in the netbook-remix launcher. Whenever something changes in the menus the launcher will close and not reopen until I restart it using alt-f2. However, since the last update this hasn't happened so they might have fixed it.
Microsoft Office:
The screenshot above shows my Microsoft Office installation. This took two-ish days to get working. For the longest time I was trying to use WINE to install it, but to no avail. The rpcrt4 dll would never replace properly and the whole thing would hang up on pipe_wait status with a fatal dll error. I eventually decided to use crossover linux and install it that way. It installed on the first try within 45 minutes. So far the only problem I am having with it is microsoft word crashing when it starts up. This isn't too much of a problem because I only plan on using OneNote on Ubuntu and switching into windows to write papers and stuff if I need to on this computer (I would prefer to use my larger computer for those).
Not so temporary...
Well I have decided to place my actual website on this server. My home server has failed due to router issues and I will probably be redesigning the entire website in the near future anyway since it uses outdated layout techniques. This server is basically the smith-marsden.org website that I work on for my dad's side of the family. I plan on downloading the contents of my server to here over the weekend so that I can try to clean things up a bit and hopefully get this site back on the map.
I will probably post progress on the new smith-marsden site here since that is currently my main development challenge.
Additional features of the new smith-marsden site:
- Ability to invite other users given to everyone
- RSS feeds on letter submissions
- More information stored so that it is all in one place that is private rather than facebook or somethwere else which could be quite public
- New state of the art layout techniques enhance the website
- AJAX allows pages to submit forms without reloading, making page load times faster and looks really cool.
- The entire thing is made using CakePHP, a robust framework.
- More to come as I think of them and make them...
Recent posts
A New BlogA good workflow and build system with OpenSCAD and Makefiles
AVR TPI Programming With usbasp For Dummies
Writing reusable USB device descriptors with some XML, Python, and C
The IoTree: An internet-connected tree