Using a OTP chip for a 7 or 8 segment LED display?

[corrado33]

I recently made a purchase of lots of stuff on surplus, and I got a couple of 8 segment LEDs.  Well, I have a couple 2 digit ones and a couple of 4 digit ones. 

What's the best way to control these?  Obviously I don't want to devote so many I/O ports to them, so I was thinking of getting another chip and simply communicating to it using the Tx and Rx pins.  (I don't remember the protocol... USART? UART?  Something like that).

But, if I'd do this it'd be dumb to use a reprogrammable chip to do it, since one time programmable chips are cheaper, and a reprogrammable chip would be overkill. 

If I did it this way, would I be able to communicate to other things too?  Could I simply use transistors to communicate to different things? 

Would it be possible to do it in other ways?  I seem to remember reading something a while ago that was designed to do exactly what I'm doing, but I don't remember what it's called so I can't search for it...

A crazy idea that just popped into my head was using some sort of PWM then (somehow) use another chip to analyze the PWM signal then make decisions based on that.  Of course, that'd be if you didn't need the PWM ports (which are much less plentiful than the general I/O ports).  I wonder what would happen if you ran PWM into an ADC port of another MCU...  I mean sure if you look at the voltage it'll average out to something, but the MCU is much quicker than you, so would it just see the 5V on or 5V off?  I know, I'm crazy and it'd probably never work.   

[Soeren]

Hi,

What's the best way to control these?  Obviously I don't want to devote so many I/O ports to them,

That depends...What is "many"?

But, if I'd do this it'd be dumb to use a reprogrammable chip to do it, since one time programmable chips are cheaper, and a reprogrammable chip would be overkill. 

If you produce hundreds of thousands, the difference will be worth it, but in your case...
Are you sure you get it right in the first go?
How many cents can you save?
What if you later wanna change the functionality even the slightest?

Go with a flash based controller - shouldn't set you back more than $1..$2 tops, if you select an appropriate chip.

If I did it this way, would I be able to communicate to other things too?  Could I simply use transistors to communicate to different things? 

Not quite sure what you mean here?

Would it be possible to do it in other ways?

Depending on how many lines you wanna dedicate to the task...
A display driver IC like one of those from the CMOS 4k series is cheap. It will drive the segments from 4 lines of I/O. Then you need to mux the displays. For a 4 digit display, you can either use 4 lines, or 2 lines with a 3-8 line chip - and for each digit you need a transistor.

Personally, I like the idea of a dedicated chip much better and then you can make it with SPI, IIC or whatever you like (or even a selection to choose from).

Using one I/O line per segment (including a decimal point) and one per digit means 12 lines for a 4 digit display. 1..2 lines is needed for the input and perhaps a couple of I/O more if you want to be able to set it up for different protocols - lets say 16 pins for 4 digits (18 pins for 6 digits) and finally, 2 pins for power - using a chip with internal RC oscillator (nothing time critical here) means that it could be made in a 18..20 pin chip. As you probably will want to use Atmel chips, I cannot tell you which is best suited for the task in relation to the price, but I'm sure Atmel has a selection tool somewhere on their site.

A crazy idea that just popped into my head was using some sort of PWM then (somehow) use another chip to analyze the PWM signal then make decisions based on that.  Of course, that'd be if you didn't need the PWM ports (which are much less plentiful than the general I/O ports).  I wonder what would happen if you ran PWM into an ADC port of another MCU...  I mean sure if you look at the voltage it'll average out to something, but the MCU is much quicker than you, so would it just see the 5V on or 5V off?  I know, I'm crazy and it'd probably never work.   

Or... You could make a small shocker circuit and strap it to your arm in a place where it will fire the right nerve to make your finger flick. Then keep ha finger over a calculator "+" button - might take some time to display "9999" though 

Slightly more sensible, you could make a counter circuit in eg. CMOS4k's and clock out pulses in accordance with the number you want to display - a reset followed by 9999 pulses clocked at eg. 1MHz would be updated in 1/100'th of a second, so would look stable.

[corrado33]

That depends...What is "many"?

Well, connecting it with 1 I/O pin directly controlling each segment LED (so 8 per digit), I'd be using 32 pins to control a 4 digit display!  That's too many!

If you produce hundreds of thousands, the difference will be worth it, but in your case...
Are you sure you get it right in the first go?
How many cents can you save?
What if you later wanna change the functionality even the slightest?

In order...
True enough.
I'd get it right on a reprogrammable chip first.  
I see where you're going with this.
Fine, you win.  

If I did it this way, would I be able to communicate to other things too?  Could I simply use transistors to communicate to different things?  

Not quite sure what you mean here?

Basically if I'm using the Tx and Rx pins of my main MCU to communicate with this other display driver chip, will I be able to communicate with... let's say... something over bluetooth also using the Tx and Rx pins?  I'm not that familiar with communication on these chips.  (Ok so I've basically just gotten it to output something to hyperterminal... once)  Are there other pins I could use for communication too?  Fine I'll go look at the data sheet.... Ok looks like I could also communicate with the programming pins (MOSI, MISO, and SCK).  But I guess my main question is can I somehow use the Tx and Rx pins to communicate to two different things?  Two other MCUs perhaps.  

EDIT:  I just read about I2C.  Never knew what it was before.  I do now...

Depending on how many lines you wanna dedicate to the task...
A display driver IC like one of those from the CMOS 4k series is cheap. It will drive the segments from 4 lines of I/O. Then you need to mux the displays. For a 4 digit display, you can either use 4 lines, or 2 lines with a 3-8 line chip - and for each digit you need a transistor.

Ok I found these.  They look like an option.  I still like the MCU idea though.  These display driver chips are exactly what I was thinking of originally.  

Personally, I like the idea of a dedicated chip much better and then you can make it with SPI, IIC or whatever you like (or even a selection to choose from).

Agreed.

Using one I/O line per segment (including a decimal point) and one per digit means 12 lines for a 4 digit display. 1..2 lines is needed for the input and perhaps a couple of I/O more if you want to be able to set it up for different protocols - lets say 16 pins for 4 digits (18 pins for 6 digits) and finally, 2 pins for power - using a chip with internal RC oscillator (nothing time critical here) means that it could be made in a 18..20 pin chip.

You lost me here.  How can I use one I/O line per segment.  And how does that add up to 12 lines for a 4 digit display?  If you're talking about using a MCU for the "display driver", why can't I just hook each segment up to an I/O port (through a resistor and maybe a transistor)?  Therefore for a single digit display, I'd need a MCU with 8 I/O pins, and for a 2 digit display I'd need one with 16 I/O pins etc?
  

[TrickyNekro]

Using one I/O line per segment (including a decimal point) and one per digit means 12 lines for a 4 digit display. 1..2 lines is needed for the input and perhaps a couple of I/O more if you want to be able to set it up for different protocols - lets say 16 pins for 4 digits (18 pins for 6 digits) and finally, 2 pins for power - using a chip with internal RC oscillator (nothing time critical here) means that it could be made in a 18..20 pin chip.

You lost me here.  How can I use one I/O line per segment.  And how does that add up to 12 lines for a 4 digit display?  If you're talking about using a MCU for the "display driver", why can't I just hook each segment up to an I/O port (through a resistor and maybe a transistor)?  Therefore for a single digit display, I'd need a MCU with 8 I/O pins, and for a 2 digit display I'd need one with 16 I/O pins etc?

It's called multiplexing, you switch on the display pass the data, hold that state for some time, switch off the 7seg and go to the next and do the same. Do it fast enough and you won't see the difference. Each display must be updated 25 times a second (25Hz)
25 x 4 = 100... That means that you need a system that runs at 100Hz at least so that the 4digit 7seg don't flicker.

I just hope that wasn't really overwhelming.

[corrado33]

Ahhhh... multiplexing.  I read about that, even googled it a few times.  I was going to mention it but didn't know enough about it to say anything useful. 

So can I "multiplex" (is that a verb?) with just the atmega or would I have to buy a multiplexer? 


Hmmm, I guess I could multiplex with the atmega... shouldn't be that hard.  Makes more sense now.

[Soeren]

Hi,

The 12 lines was for a 4 digit display with decimal points (i.e. 8 segments/digit)
This circuit kinda illustrates what I mean - use an NPN transistor on each digits common cathode, that's the lower connector (use a PNP from the positive line and invert the rest if they're common anode displays)

(click for the page it was found on - it's readable there)

And yes, it's called multiplexing - a bit like "time slice multitasking", first you turn one digit on, then the next and so on. POV makes it look like a steady display, although 100Hz might be way too flickering - try 500 Hz for a good steady display - and hammer the segments with the max. current the controllers port can handle (not 8 times what a single I/O can handle - see datasheet), as the average current will be low due to the mux'ing.

[corrado33]

Ha, I guess I could have searched for a schematic.  I started drawing one up as soon as I submitted my last message haha.

Looks good though, as I currently am messing around with a dual digit display, I'll see if I can implement it. 

[corrado33]

Using one I/O line per segment (including a decimal point) and one per digit means 12 lines for a 4 digit display. 1..2 lines is needed for the input and perhaps a couple of I/O more if you want to be able to set it up for different protocols - lets say 16 pins for 4 digits (18 pins for 6 digits) and finally, 2 pins for power - using a chip with internal RC oscillator (nothing time critical here) means that it could be made in a 18..20 pin chip. As you probably will want to use Atmel chips, I cannot tell you which is best suited for the task in relation to the price, but I'm sure Atmel has a selection tool somewhere on their site.

You know, now that I understand it, all of this makes complete sense.  Is that a chicken and the egg scenario?  lol

I got it to work though.  Got it running off of timer0 at 488 Hz.  I think I'm just going to make one of the timers (most likely timer 0) my display/pause dedicated timer unless I'm REALLY in a pinch.  I like that idea.  Too bad it's the simplest one and I need to figure the other two out... haha  I've gotten PWM working before, I just need to figure out how to turn the timer itself on, without the PWM... just a normal timer...  EDIT:  5 Minutes of tinkering and I realize turning timer1 on is exactly the same as turning timer0 on... just different registers haha

Anyway I have another question.  You said...

and hammer the segments with the max. current the controllers port can handle (not 8 times what a single I/O can handle - see datasheet), as the average current will be low due to the mux'ing.

So in this case the "controller" is the AtMega8 (or whatever chip I'd use).  And on the datasheet for the atmega8 it says, MAX specifications..

DC Current per I/O Pin ............................................... 40.0 mA

.

So I should calculate my resistor to provide 40mA to the LED?  (Well, actually the AtMega is sinking, not driving... is that the right wording?)

The datasheet for the display says typical ratings are 20mA at 2V, but I want 40mA so...

R=(Vs-Vl)/I......... = (5-2)/.040 = 75 Ohms.  So the next resistor up from 75 ohms will be good... right?

EDIT: Man I'm glad I didn't have a blue or white display...  I guess I could always just put transistors on them too.  I'd need to use NPN transistors, right?  

[Soeren]

Hi,

So in this case the "controller" is the AtMega8 (or whatever chip I'd use).  And on the datasheet for the atmega8 it says, MAX specifications..

DC Current per I/O Pin ............................................... 40.0 mA

.

Yes, as long as you have less than all the pins in a port supplying/sinking current, the max for a single pin is valid.

So I should calculate my resistor to provide 40mA to the LED?  (Well, actually the AtMega is sinking, not driving... is that the right wording?)

The datasheet for the display says typical ratings are 20mA at 2V, but I want 40mA so...

R=(Vs-Vl)/I......... = (5-2)/.040 = 75 Ohms.  So the next resistor up from 75 ohms will be good... right?

The opposite of sinking is sourcing. When you call it "driving", it could be either.
You need to both source and sink when you multiplex a display, if you run all lines directly off the controllers pins.
Yes, use a 82 Ohm resistor for 36.6mA

EDIT: Man I'm glad I didn't have a blue or white display...  I guess I could always just put transistors on them too.  I'd need to use NPN transistors, right?  

Or you could use transistor arrays with 7, 8 or 9 transistors in a single DIP packages.
You'd use NPN for the side going to ground and PNP for the side going to Vdd ("Vcc"/+5V)

[corrado33]

Thanks!