It is way too late for this I know, but there might be someone trying to convert AC signals for LCD into TTL signals to drive 7-segment LED. I have come across this issue when my boiler controller LCD lost so many segments that it was difficult to read the temperature and settings. I have studied the protocols and signals levels driving LCD display and I think I have come up with a way to convert signals.
First of all, you need to know how many segments are driven by one signal line and how many 'common' signals you have. Also, you need to know what combination of segment signal and common signal turns on/off segment on the LCD. This can be determined with multi-meter or even better with scope. Your original LCD driver must be functional and you should be able to drive the display (too much writing how to do it, but it is simple process).
Now, the circuit to convert LCD signals to LED (TTL) is not going to be simple as it was suggested above. The segment is ON when the differential voltage across common signal and segment signal is more than 2/3 of supply voltage of the driver. This could be only for 2ms or less. The segment is OFF if this differential voltage is less than 1/3 of supply voltage. This is simple - right?
Now, you need to capture this pulse, hold it long enough (latch it) and output this to the respective LED segment. You need to remember, that you need to detect differential signal between common line and segment line. I think this is it.
I am not expecting that anyone will post here any more and I am not expecting anyone to try building this. It is not worth it unless you are desperate or have too much time on your hands. I certainly have not built it.
Actually this is a very common arrangement. Each digit has its anodes connected together, and the segments for all digits have their cathodes connected. The controller enables one of the common anodes, drives the segments, and waits, then turns off the cathodes and moves on to the next common anode. This arrangement and control method is called multiplexing, and the linked article will give you a lot of information. The part in question is a common anode display, but common cathode displays are just as common.
Multiplexing allows you to drive a large number of display elements with fewer wires than individual addressing, at the expense of a more complex control algorithm. You can go a step further by doing something called Charlieplexing which allows you to drive even more elements with less I/O if you can turn off the drivers (as opposed to just setting them high or low, which is the requirement for a multiplexed display controller).
Now that you know it's called a multiplexed display, you should have no trouble finding all kinds of example circuits or microcontroller code fragments to implement it.
Best Answer
You probably just need a chip like the TCA9554.
1to the corresponding PIO bit will turn the segment on.oto the corresponding PIO bit will turn the segment on.Just noticed that the TCA9554 has a polarity inversion register. This makes things a bit easier in that you can set all the bits to invert polarity in the common anode case, and then a
1bit always means "turn the LED on".So, in the code, you just do the following (omitting the address step for each transaction) to initialize:
0x010x00-- Clear all outputs.0x020xFF-- Invert all outputs (only do this for common anode).0x030x00-- Set the pins to outputs.Then to set a digit, you just send the bits that light up the correct segments. For example, if P0 is hooked to segment 'a', P1 to 'b', etc. through P7 to 'h', you write
0x010x3Fto display a '0'.So you don't want to drive just one digit, like the title says? Well, you have a few options.
Lots of chips
You could always go with the brute force solution, and have 20 chips. This is for when you want to have all the segments driven all the time. It's also the most expensive. As noted, there's a problem where this particular chip can't have more than 8 addresses. The availability of the TCA9554A, which offers 8 more addresses, doesn't help either; you're four short.
You could deal with this by using more than one I2C bus, and having some of the chips on one bus and some on the other. That assumes you have more than one I2C bus.
You could also deal with this by using chips that have a lot more I/O pins. For example, the TCA9535, which has 16 I/O pins and thus can directly drive two digits per chip, and can have one of eight addresses, along with the TCA9539, which can drive two displays each and have one of four addresses. Between these, you can drive up to 24 digits.
One problem you will have by parking all these chips on the I2C bus is excessive loading. Since I2C uses a pull-up resistor to drive the line back high, the capacitive load of so many chips will slow down your rise time. Further, there is a lower limit on that pull-up resistor because your I2C master can only sink so much current before burning out. This is why most of these chips aren't available in more than eight addresses: putting more than eight loads on an I2C bus is questionable at best.
Which leads us to the solution that just about everyone uses when dealing with an array of LEDs...
Scanned Display
Since your users are humans, and thus use human Mk I eyeballs, there is an interesting effect you can take advantage of called "persistence of vision." In a nutshell, this means that so long as a light source lights up at least once every 4-8 ms or so, it is perceived as a steady, non-flickering source. What this means for us is that we can throw the one-output-pin-per-LED requirement out the window. So long as we light LEDs up at least once per couple milliseconds, we'll be fine.
For a 20-digit display like this, arranged as a 5x4 display, I'd wire it up to turn on only one row of five digits at a time, and switch to the next row every 2.0 ms or so. This means there's a total of 40 segments to drive at a time, with four pins needed to drive the rows themselves. Total of 44 I/O pins, or three TCA9535s.
So now what you do is wire the displays up as an array. Do this as follows:
Now on the software side, you need some kind of function that gets called every 2 ms. For microcontrollers, the usual thing is to set up some internal timer peripheral to interrupt at this interval, then have the ISR set a flag (or give a semaphore or whatever) to kick off a display update (because that much display updating isn't going to fit in an ISR by itself). The code that is triggered by that flag generates the 48 bit pattern needed and writes it out over the I2C bus to the TCA9535s.
The bit pattern is as follows:
Each byte is generated the same way as above for a single-digit case. The order of operations should be:
And that's it. The I2C transactions to do all this need to finish in that 0.1 ms we calculated above, to keep the off-time of the displays to a minimum. That usually means your I2C bus needs to be running pretty fast. Like many I2C devices, the TCA9535 can run up to 400 kHz; you should try to run at this speed or as fast as possible, since you need 32 clocks per chip to set its pins, and thus about 150 clocks (.375 ms) to update the whole display. If the time to update the display is too much of the total row time, then you need to scan the display slower (i.e. more ms per row). Your limit there is how slow you can go before your users see the display flicker.
Side note
This is one place where an SPI port performs better, because: