I spent some time tonight laying out the first hard ‘prototype’ of the display. I’m going to be putting it together on perfboard for now because I have all the through hole components, and doing a PCB would just be nonsense.
The IC sockets I have stand off the board about 1mm so I will be able to route all the signals underneath the chip which will keep things looking nice. I will also be running all the wire on the TOP side of the perfboard. This is a personal preference and not how most people do it.
The LED matrix will plug into a female header and cover all wiring and IC’s.
Hopefully I’ll be able to start wiring it up tomorrow.
The library to control the screen is almost finished. If you’re looking closely, you will notice an Adafruit DS1307 development board getting ready to be used.. Once I find a suitable coin cell battery, this thing will be useful.. A clock! After this i’m going to work on creating a prototype board to package this thing up a little nicer.. I think this thing needs a Conway’s Game of Life implementation as well.. That could be the startup routine? So many options!
Creating the MatrixLED Library
When I started writing the MatrixLED library I had ZERO preconceived notions about how it should be implemented. I just started coding some stuff to get it to do some other stuff. I ended up creating a 128 byte buffer that allowed me to store and manipulate 16 ‘frames’ (8 bytes per frame * 16 frames = 128 bytes).
This worked and was very easy to implement but it was rather bloated. I would take in an ASCII string, look up the equivalent ‘frame’ for each character and write those 8 bytes to the buffer. The actual screen was mapped to the first 8 bytes of the buffer. This means I needed to keep track of how big the buffer had grown and resize my manipulations accordingly. I started thinking about how I could do this in place and realized it was possible without an external buffer. I rewrote the code and have made some decent progress.
As of right now there is an 8 byte screen buffer that is mapped directly to the matrix. There is no shifting of data into the ‘screen’ area. This frees up space and cpu cycles. I’m not convinced that I will be able to implement all of the features I want without some type of scratchpad, but at least I can add one later if I need to.
I’m going to spend some time tomorrow polishing up the marquee function, and start working on some user input.. My goal is to be able to move a pixel around the screen by the end of tomorrow.
Videos will follow.
Be aware, the second link has not been tidied up.. It works completely tho so that is why it remains the master branch.
Worked on the code a bit more. Eliminated the ghosting and tidied up the buffer and display method. Decided to implement a marquee effect. For now it only rotates the active portion of the display but ill work on applying it to the full buffer. It’s kind of nice to work on a project for an hour here and there with no deadlines!
Wrote a quick and dirty Excel VBS sheet that lets me create the fonts and graphics for the display. This should quicken the tedious work and allow me to focus on algorithm instead of drawing out everything by hand and converting to machine speak.
Going to take a break from this project for a bit.. Homework is calling my name.
Display is pretty much finalized. It’s a bit over-engineered due to the fact that I’m only using parts on hand, and I don’t want to burn up the MinimusAVR board that i’m using. If I can find a suitable shift register, I’ll implement a serial protocol but for now I’m just dumping the columns to the register. A shift register would also allow me to utilize the green LED’s as well.. Meh, more code.. One day.
I have a slight ghosting issue but the display code is so simple I don’t want to mess with it. The problem is that I’m using a 4017 to scan the rows and I haven’t implemented a way to ‘turn it off’ for the next byte of data.. Once again, more code for another day.
Discomfort to those who ruin the curve.