Pull up resistor question

[G. Hoffman]

I'm working on a project with a bunch of stuff on the same 8 bit parallel buss.  The μC is a PIC16F887, and it is going to have 9 LCD screens, 6 74HC574 latches, and is also the inputs for a 8X3 switch matrix.  The only question I have is, do I need to use larger pull-ups?  Even though they are all high-z inputs, they are still adding capacitance, and I'm a bit concerned about the charging time.  I can't find the equivalent capacitance of the LCD screens (EA DOG-M series), though I do know the latches add 10pf each, and I believe the LCD's inputs are CMOS, so they must have a fair bit of capacitance, right?  So, normally, I would use a 10k pull-up, but do I need to use a smaller pull-up with all the added capacitance?  And if so, how much smaller?  I think my Fosc will be 20mhz, so does that mean I need to get my charge time down below 0.2 μS?  That seems a tall order, given just the 60pF from the latches gives a 10k charging time of 600 μS.  Most of the LCD's could be put on an SPI serial buss, if I really had to, but

Or am I worrying about nothing?  Should I just try it and see if I have a problem?


Gabriel

[R.G.]

Specifications on datasheets.

A slightly less Zen-koan way of saying this is that all digital inputs have specifications on how much capacitance they have, as well as how much DC current they allow through (TTL has lots, ECL has more, and CMOS has almost no DC at all). They also specify how hard (in DC current) they can pull up and/or down. They also specify what the fastest and slowest speeds they work well with on rising and falling edges. Note that outputs driving a bus also have a capacitive load associated with them, even if they are tri-stated off.

With a collection of different logic families and loads, there is no other route for doing it right than assembling the set of datasheets, adding up the capacitances and DC loading, and then seeing if the specifications on each driver that drives each net can drive it fast enough to make it switch within the worst of the necessary times.

Back at your original question. There is no way to tell but to add it all up and see if it's all within all of the specifications. Notice that building it and having it work does not mean it will work in general, because you may have extra-good devices in your prototype and get barely-within-spec devices for any further builds.

But +3 points for figuring out a valid if underappreciated question to ask.

[G. Hoffman]

Well, I'm glad I am not just imagining things, at least!!!!

The problem I'm having is finding the required specs for the LCD screens.  The manufacturer's data sheet is a joke, and for this information just gives a link to another companies data sheet for the ST7036, which would be fine but they don't seem to have everything I need.  It tells me timing information, but as well as sink and source data, but it doesn't have any spec I can find for capacitance.  I've got what I need for the latches (TI data sheets always seem very user friendly!)

I can't take too much credit for think of this independently, though.  I've recently been reading Microchip app notes for SPI buses, and they make a point of bringing this matter up.  I couldn't think of any good reason for it not to be an issue with a parallel buss, though, so I asked.  If I could find a large LCD screen that ran on SPI for a reasonable amount of money, I'd stick with SPI and save myself a whole bunch of soldering, but it just seems too complicated to do one screen parallel, and eight others serial.  Too much programing!

Thanks for the help, R.G.  You were who I was most hoping would answer.


Gabriel

[R.G.]

The problem I'm having is finding the required specs for the LCD screens.  The manufacturer's data sheet is a joke, and for this information just gives a link to another companies data sheet for the ST7036, which would be fine but they don't seem to have everything I need.  It tells me timing information, but as well as sink and source data, but it doesn't have any spec I can find for capacitance.

Yeah. Datasheets are also very informative when they don't say something.  Not finding pertinent specs on a data sheet can mean:
- it's not important
- the maker doesn't know
or more likely,
- the maker doesn't want to go to the expense of testing and guaranteeing, or they don't think it would help sales.

In the case of LCD screens, I suspect that there is a generic capacitance per unit area of the pixel. You may be able to find figures on generic capacitance per unit area for LCDs and get a guestimate pending actual measurement of the screens you get.

This brings up a point: LCD screens have fairly tight timing issues. The pins you use for LCD screens probably can't be used for other things anyway. So the capacitance may not matter (item 1 above) because the pin has to be used for the LCD. It's a guess.

I'll find out in the near future. I'm working on some LCD stuff now.

[G. Hoffman]

Yeah. Datasheets are also very informative when they don't say something.  Not finding pertinent specs on a data sheet can mean:
- it's not important
- the maker doesn't know
or more likely,
- the maker doesn't want to go to the expense of testing and guaranteeing, or they don't think it would help sales.

In the case of LCD screens, I suspect that there is a generic capacitance per unit area of the pixel. You may be able to find figures on generic capacitance per unit area for LCDs and get a guestimate pending actual measurement of the screens you get.

This brings up a point: LCD screens have fairly tight timing issues. The pins you use for LCD screens probably can't be used for other things anyway. So the capacitance may not matter (item 1 above) because the pin has to be used for the LCD. It's a guess.

I'll find out in the near future. I'm working on some LCD stuff now.

Thanks!

The more I think or it, the more I'm thinking that I'll use SPI for the LCD screens.  3 wires to each screen seems a lot better than 11 (8 lines data, R/W, RS, and Enable!), even if it does make the programing a bit more complicated.  The SPI interface should be standard for all of this, and I'm already going to have the MSSP going for some other peripherals (an external EEPROM and an Ethernet encoder)


Gabriel

[R.G.]

The more I think or it, the more I'm thinking that I'll use SPI for the LCD screens.  3 wires to each screen seems a lot better than 11 (8 lines data, R/W, RS, and Enable!), even if it does make the programing a bit more complicated. 

Oh. You're using an LCD controller chip/module? I thought you were driving LCD segments directly. If you're using a character module,
1) you can assume the inputs are the same as the "standard" Hitachi controller, something like a 66780.
2) you can drive it with four instead of 8 data bits; they'll all do nybbles.

My answer was clearly colored by my working on a direct-to-the-glass LCD display.

[G. Hoffman]

The more I think or it, the more I'm thinking that I'll use SPI for the LCD screens.  3 wires to each screen seems a lot better than 11 (8 lines data, R/W, RS, and Enable!), even if it does make the programing a bit more complicated.

Oh. You're using an LCD controller chip/module? I thought you were driving LCD segments directly. If you're using a character module,
1) you can assume the inputs are the same as the "standard" Hitachi controller, something like a 66780.
2) you can drive it with four instead of 8 data bits; they'll all do nybbles.

My answer was clearly colored by my working on a direct-to-the-glass LCD display.

Yes, definitely controller chips (an ST7036, though they are built into the actual glass display, chip-on-glass I believe they call it), which is a modernized version of the Hitachi stuff, and it also has SPI serial ports built into it.  I wish it had I²C, but the version built into these LCD's dosen't support it.  I need the 8 wire parallel buss for other stuff, though, so I may as well just run it all around, right?  Though, it would save me some soldering, I suppose.


Gabriel