Single Backlight

A LCD works by electronically controlling the opacity of a membrane. When you array these, you get pixels.

For a color display, this happens three times with three filters red, green and blue.

Because LCD only controls how much light passes through, a backlight is a critical component of the display system. This is commonly done with a single backlight which illuminates the entire screen region and its brightness can be controlled. We are all familiar with this in our phones and laptops.

Local Dimming

Local Dimming is the simple idea of using a grid of backlights instead of one single backlight.

This is particularly valuable to HUDs because the intention is to be entirely transparent except for the region or content of interest.

Turning off a region of the backlight grid makes that part of the windshield transparent.

Big Fast Many

Controlling an LED is easy, but there were challenges with this project.

There were lots of LEDs, let's say 100.

They are high power, let's say one watt,

All of them need to be dynamically changing brightness very fast, let's say 60 Hz.

Possible Solutions

I could think of various solutions to this but suffice to say that when you add the constraint of physical size and cost, it's best to leave it to the EE's and ME's. My colleagues chose the solution architecture and I was tasked with creating the firmware to make It work. This is usually how it goes with my clients. I join a project to get it done, not scope it out. This is not to say I don't participate in architectural discussion. I do, but it tends to be more in the domain of software rather than hardware. A lot of decisions are made for "business" reasons, ie. relationships with vendors, "secret back door deals" just kidding : ).

Architecture

The architecture was focused around the use of a particular component, an LED Driver, which is able to drive an array LEDs with high current and change all of their brightnesses at high speed. In addition, there is a daisy chain mechanism which allows for scaling up the number of LEDs and LED Drivers. We had 6 of these drivers chained together on the SPI bus.

SPI Daisy Chaining

This was interesting to work with. I had never seen this before.
The MOSI signals go to the next devices in the chain, and then the last one goes back to master. So it's kind of like SPI in the sense that it's a shift register, bytes go in and out at the same time. But instead of the typical 1 byte delay, it's a N byte delay for N devices in the chain.

Development

I started development by acquiring evaluation boards of these LED drivers and creating a proof of concept system using the old generation hardware. Fortunately, the same microcontroller would be used in the new hardware. Also, I used regular off the shelf LEDs and a lab power supply. I was running at low power because I was more focused on my firmware being correct so that when the new hardware was available, we could go to testing immediately and we would not be waiting or worried about the quality of my firmware.

New Hardware Arrives

When the new hardware arrived, it was an interesting experience for me because of how many different parties were interested in the firmware. Optical engineers cared about the brightness. Mechanical engineers cared about heat dissipation Software engineers cared about the interface for the host computer to control this controller.

Testing

The backlight controller is meant to be integrated into a larger automotive system. It was very important that it followed the rules of protocol and behaved as expected. Not only this, the host side software also was being updated. Because of this, I had a physical host computer in my shop for testing. This required me to gain an understanding of the greater architecture as well as how to do basic tasks such as loading new software on the host and configuring it, and starting and stopping the control of the backlight controller.

Deliverables

Before delivering the finished firmware source and binary, there was one tool that I created for the greater team so that they could choose the specs and behavior they would like for the final released firmware binary, This tool basically allowed a nontechnical user to instrument all of the behavior of the firmware and hardware. This way, they would be able to report back to me and I could capture their requests into the firmware.

Conclusion

In conclusion, this was a great project and experience for me. It was a pleasure working with engineers of different disciplines, and I always enjoy the opportunity to help people do their jobs better.