Using 8-bit parallel interfacing for hd47780 compatible lcd's, has anybody put pullup resistors on the databus to help with the transient delay? Would this even help at all?
If the port is set as an output, the port will actively pull high as well as low. So, there should be no benefit except higher power consumption.
Until Black Lives Matter, we do not have "All Lives Matter"!
Not worth it in my book as well
the 'other' Jim
I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie
"The critical shortage here is not stuff, but time." - Johan Ekdahl
"Step N is required before you can do step N+1!" - ka7ehk
"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman
"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?" - Lee "theusch"
Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-) - Source Unknown
Please Read: Code-of-Conduct
Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user
I've never had the need to have pull-ups on the "LCD bus".
-None of the Jims
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
I don't recall seeing any data the the slew rate is different for the AVR IO pins to drive high or low. But, if you wish, you can download the IBIS model files from atmel.com and examine the characteristics of the buffer drivers for the AVR.
If I wanted to "speed things up a bit" the rise time of the data bus to an LCD is not the first place I would focus my attention. In fact, its probably not a place I'd even look at at all. Perhaps if you could explain in more detail what you are seeking to do there might be other, more productive, suggestions.
Short answer: No resistor(s).
JC (Neither Jim, nor Jim, nor Johan)
Edit: OK, the tag line doesn't make any sense now as Kevin beat me to the post...
To amplify a little on DocJC's suggestion, it might be worth while to understand What it is that you want to "speed up"? Electrical bus speed is rarely an issue for LCDs. Speed issues are more likely in the software that pumps the data onto the bus. So, if you can explain a bit more what you are after or what the problem is, we might be able to help.
The E pulse needs to be 500ns. Thats half a micro second. Not 500usec. Not 500ms. What usually happens is that somebody wants to use an lcd, they get an example thats a couple of years old that was for a 4mhz cpu and all the delays were hardcoded or tweaked until it worked, then no more optimization was done. This same example on a 16mhz cpu would run 4x slower right off the bat. Also, some of the library routines set each bit of the data with a macro, so the data lines can be hooked up all crisscrossed willynilly in a mixedup mishmash. It runs about 4x faster if you keep the data bits in a nibble in bigendian order and just store em in the port. My test shows I can write chars to the lcd about 10k per sec... same as a 115200 serial line.... this is many times faster than the lcd soup can turn black to see the chars, which is something like 15ms per screenfull.... very slow. Rant over.
Imagecraft compiler user
© 2020 Microchip Technology Inc.