09/26/2020 at 21:56 •
Most of the work on the #GPS Driven Clock project is done. It is presented as a separate project.
As mentioned in earlier log files, the dual driver display modules were too expensive, so I developed driver board using a different driver chip (ISSI IS31FL3730) that is about 40% of the cost of the dual driver modules. When I started on the clock project, I had just gotten the first of the single driver modules built up and minimally tested.
This morning, I built up the other two PCBs for a total of 3 of these displays operating. In order to drive the new displays with more than just test code, I ported the software drivers over to deal with the IS31FL3730 chip. The architecture of the new chip is quite a bit simpler than the previous one, so the initialization sequence changed and there is only one chip per module to drive. Because of the way that the display had to connect to the driver chip, the data format for the green LEDs is rotated 90 degrees from the format for the red LED data. I brute forced this with a second character generator table rather than rotatating the data in real time. The character generator tables are 768 bytes per table, which is not too ugly.
The current control register on the new chip is a wierd, discontinuous thing, so I need to write the code to map a linear input value to the required register data format. 10/5/2020 The current control function is written and the display drivers are willing to source up to the 70mA listed on the data sheet. They run kind of warm when doing so though.
The new chips only support 4 different I2C addresses, and I did not put an address translator chip on each board, as the translator chips cost more than 2X the cost of the display driver chips. I have a bus splitter/address translator board laid out already that will let me run 4 separate bus segments with their addresses mapped to unique spaces, so one of those boards will support up to 16 display modules. Also, the power for the displays and the power for the address translator chips are supplied through different connectors on the splitter translator board. This will allow me to run the I2C bus on the microcontroller side at 3.3V and the individual I2C buses to the displays at 5V which should give more headroom on the LED supply from driver chips.
10/8/2020 The boards for the I2C Splitter/Address Translator are back. I built the first one up and verified that it is operating as expected. I need to order some more connectors to finish it. Also, it won't be required until I build up more of the single driver displays.
08/28/2020 at 19:43 •
On the build of the last three boards, one of the boards refused to respind to "pings" on the I2C bus to one of the IS32FL2728 chips. The "ping" is just a read command that gets no data. The other 8 boards had no issues on this with both chips responding as expected through the LTC4316 address translater chip. The board accepted write operations and commands to both controllers normally. The I2C address translation values were picked to not collide with any of the other 8 controllers on the bus. There are some special purpose reserved addresses at the extreme low and high address areas and I avoided them as well.
Thinking that if one of the addresses on the board did respond and the other one did not, the I2C bus was probably good and the IS32FL3738 chip that was not responding had a problem. After lots of un-rewarding inspection of the board and verifying power and I2C goodness to the chip, I replaced the IS32FL3738 chip that was not responding. No joy, it still did not respond. In a fit of irritation, I swapped a few passive components related to the chip with similar results.
I checked the soldering around the address translator chip and all looked fine. Looking at the I2C signals with a scope on both sides of the translator chip, looked about as good as one would expect of an I2C bus with 18 devices on it. I did not put testpoints on the board that would have made it easier to hook a bus sniffer up and examine the translater output traffic, so that was not done.
The application that I am using these parts for does not need to read anything back from the IS32FL3738 chips, so I put the problem aside for a few days. Leaving something that glaring wrong on a project bothered me, so I did not decide to just ignore the issue.
The way that the translator chip was configured, the responsive chip was at 8 bit address 0x5A and the missing response should have been at 0x50. It occurred to me that for some reason, the LTC4316 address translator chip might not be translating the address correctly. I searched the data sheet on reserved addresses on the I2C bus and 0x50 (7 bit 0x28) might be a reserved address. There was no mention of it. I started digging through the I2C spec and saw a mention of a strange PMBus zone read protocol involving address 0x50, but no details. The PMBus document did not mention it either.
Figuring that the problem was only seen on a read operation, it might be related to that zone read thing, so I changed the translation address to put it at 0xD0 and 0xDA. Bingo, both IS32FL3738 chips responded to the ping.
10/10/2020 Was digging through the source code for my address ping tool to make modifications to it for another task, and figured out that the address ping tool treated the 0x50 address as a "special function" address and inhibited accesses to it. I wrote that tool several years ago, and had forgotten how I had inhibited the tests on it.
08/27/2020 at 12:39 •
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.
08/06/2020 at 17:58 •
The rev 1.1 PC Boards are back from OSH Park. I built up all three of them. They are much quicker to assemble since all of the components are on the top side of the board except the sockets for the LED Matrix.
I made sure to keep the bolt pattern and it's relationship to the LED Matrix the same as the rev 1.0 boards so they will both live on a mounting plate and be interchangable with the rev 1.0 boards. I also added resistors to support translating the low nibble of the I2C address that were lacking on the rev 1.0 boards.
I now have 6 of these boards built and operating, and I want 3 more. Those will be ordered this weekend.
The cost on these modules is higher than I am happy with. Separate driver chips (IS32FL3738) are used, one for red and one for green. There are only 4 options for I2C address selection on these driver chips, so I added an I2C address translator to each board to allow running more than 2 boards on an I2C bus. The PCB is a 4 layer board. I chose to use a 4 layer board to get low impedance ground and power distribution to both display drivers and the address translator. Also, the driver chips have a heat spreader pad under them and I wanted to be able to use a ground plane for heat sinking the drivers.
Poking around in the projects on Hackaday, I found a project that is very similar to this one: #PIXIE - Chainable, Dual 5*7 Micro-LED Displays! The display driver chip (IS31FL3730) used on that project is capable of driving both the red and green matrices in the display, so I laid out a board to use that chip. These chips also support 4 choices for the I2C address, but only one chip is needed per board, allowing up to 4 displays on an I2C bus segment. I removed the I2C address translator and added jumpers to select the address and enable/disable the I2C terminators. My concerns about heatsinking the driver chip did not seem warranted with the rev 1.0 boards, the drivers only run a few degrees above ambient temperature. With a single driver chip to supply power and ground to, a 2 layer board makes more sense. With the changes listed above, the parts count is less than half of what the current boards are using, and it will go on a 2 layer board. To get the same functionality as the previous boards, either bus multiplexing or address translators are going to have to go into a system somewhere. A prototype board for the new driver is ready to send out to OSH Park.
The new driver chip handles the two matrices in kind of a strange way. One matrix connects to the driver pins labelled row[8:1} and column[8:1] matching the LED pin designations. This is a common cathode matrix. The second matrix looks to be a common anode matrix, but since both matrices in the LED block are common cathode, I rotated the second matrix, connecting driver rows to LED columns and driver columns to LED rows. It is not clear from the documentation whether the hardware corrects for this in the registers for the second matrix or not. I am just going to have to build one and mess with it. If the hardware does not correct for this, it will be necesary to do the pixel rotation in software.
It is not clear what the maximum LED current is for the new driver. The electrical specs in the data sheet say that the maximum is 40mA, but in the register set description, there is an option for 75mA. Running 40mA per LED may be enough, but that is another thing to test when the boards get back.
The IS31FL3730 uses my least favorite package for assembly at home, the QFN leadless package. None the less, it is worth trying. It is not like there is a deadline or anything.