The last 3 of the rev 1.1 boards are back from OSH Park and assembled. The chassis that I designed for 9 displays is now populated and looks good.
I started working on the application code for using these beasts while I was waiting for the boards to come back. It will be a GPS driven clock. I also built a breakout board for an ambient light sensor chip to use for automatically dimming the clock.
In the previous log file, I mentioned doing a PCB for a different driver chip that would be a less expensive board. After totalling the costs on the bill of materials, the new boards come out at about 40% of the cost of the rev 1.1 boards.
The new PCB design is a 2 layer board because there is a lot less routing with a single chip than 3 chips, and the heat sinking did not appear to be the problem I was expecting on the original design. Using only 2 layers reduced the cost of the PCB by 50% . A single jumper wire was needed to route one signal on 2 layers, so that one blue wire is a feature, not a mistake :)
Prototype boards for the new design came back from OSH Park and assembled easily enough. I took care of several convenience issues with the new design like having jumper selectable address and terminator enable. To keep size down on the jumpers, I used the 1.27mm header and shunt blocks.
Because of the way the matrices of LEDs are implemented in the LiteOn displays, I had to rotate the matrix of the green LEDs by 90 degrees. The red matrix is wired as a common cathode matrix. If the green matrix had been wired as a common anode matrix, it would have matched the intended configuration of the IS32FL3730 chips, but no joy. The displays have two 5x8 common cathode matrices, one red and one green. I wound up connecting the red matrix in the conventional way and connecting the green matrix with the column driver outputs connected to the LED row inputs and the row driver outputs connected to the LED column inputs. This effectively rotates the green matrix 90 degrees. In use, the time penalty of rotating the character generator matrix 90 degrees while updating the display is probably more of a problem than the space incurred with a second character generator data set, so a second character generator data set with the data already rotated will solve that problem.
Rotating the matrix also has some implications about current control when multiple LEDs are lit in a single column, but that needs more testing to see if it will be a problem. I have a home written tool that allows sending I2C write transactions controlled by a simple text file with a lot of flexability. It uses the Total Phase Systems Aardvark to go from USB to I2C, SPI or GPIO. The tool called VarkBlaster is useful for exploring configuration and control of parts like this. I wrote a few scripts that drive the display with varying numbers of LEDs lit per row and per column, and there was no difference visible to me in the LED itensity.
Using the character generator array that I developed for the rev 1.1 IS32FL3738 based boards, I wrote a tool that translates that into the register bit formats for the two matrices in the IS31FL3730 chips and displayed a couple of characters from each array to sanity check it. So far so good. The character generator arrays form a lookup table mapping ASCII code to register values to display the character. In general, the brightness seems a little low but I have not started experimenting with the LED current control register yet.