kwdaily / shiftreglcd123

Automatically exported from code.google.com/p/shiftreglcd123
0 stars 0 forks source link

Faster 3 wire mode #1

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
3 wire mode has the advantage of latched outputs
so backlight control is steady vs flashing in the case of two wire mode.

When using 3 wire mode, it is possible to have direct control over E
rather than have to drive E from the shift register.
This reduces the SR updates to 1 per nibble and if you want to
give up backlight control, it can be 1 SR update per byte.

To do this you wire
AVR pin to lcd E pin
AVR pin to SR data pin
AVR pin to SR clock pin
lcd RS pin to SR data pin.

You clock in the data.
Set the data pin for the RS state.
Raise and lower E directly.

If you give up the backlight control you can even do 8 bit mode
on non latching parts like the 74ls164
or the latching 4094 (doesn't slip a bit like the HC595)

HC595 would have to run in 4 bit mode with the wiring
shifted down to compensate for the bit slip
when rclk and sclk are tied together.

See this page for an example of how to wire this up:
http://frank.bol.ucla.edu/AVR2LCD.htm

--- bill

Original issue reported on code.google.com by bperry...@gmail.com on 13 Feb 2012 at 8:29

GoogleCodeExporter commented 8 years ago
Yes, I went back to good old SRLCD way of connecting E directly in 3-wire mode 
(Not for LCD3Wire, but that's just for compatibility with that way of hooking 
it up).

Nice one about the LCD RS line to SR data though, didn't think about that one. 
Still, I think I'll keep this in 4-bit mode with backlight, for now at least.

And yes, 2-wire mode backlight can flash, but I didn't really notice it too 
much or found it too disturbing, but I then again I haven't looked at it much. 
I guess adding a capacitor or RC net to the backlight control (transistor base) 
helps smoothing it.

Original comment by raron...@gmail.com on 14 Feb 2012 at 5:07

GoogleCodeExporter commented 8 years ago
The flicker depends alot on how fast you drive the shift register and how
hard you drive the lcd and which characters you are sending.

If you use the standard shiftOut() function in Arduino on AVR based processors
which uses digitalWrite(), shiftOut() takes over 100us per byte.
On a pic32 you don't really notice the flash as much because it is so much 
faster
than the AVR plus the pic has set/clear registers so it is a single write
to set or clear a bit vs on AVR having to mask interrupts,
read the byte, OR the bit, and write the byte back out then restore interrupts.
The pic32 is over 10 times faster with digitalWrite().

In two wire mode
I played quite a bit with trying to use an RC network to control a transistor.
It does help but the problem is that the when doing constant writes,
like say doing rapid animation with custom characters, 
(which is what my demo sketch does), the majority
of the bits shifting through the register are zeros since you have the
zero clear byte and the custom characters are mostly zero bits.
It causes the RC network to discharge since the effective duty cycle on
the backlight pin is pretty low.

The flicker is more noticeable when you turn off the display and
continue to write to it. (probably not a normal thing to do).

I found you could tune it to favor on or off which could help eliminate
the flicker at that end, but I never figured out how to make it work at
both ends given the eventual issue of duty cycle on the backlight pin
and the circuit has no way of really knowing when to charge or discharge.

Original comment by bperry...@gmail.com on 14 Feb 2012 at 5:36

GoogleCodeExporter commented 8 years ago
Sounds about right. I tested a digitalWrite() HIGH - LOW loop, and it produced 
a 100 kHz frequency on a 16 MHz Arduino (It was even a small fraction lower 
with the new Arduino 1.0, not much but just below 100 KHz vs just above 100 kHz 
when compiled on an older Arduino-0022 IDE. Almost not worth mentioning though).

And yes, I use the Arduino shiftOut() function. I don't feel confident enough 
about using any direct port mapping and having it work on different Arduino's, 
so I choose the safest and slowest route (I only have Atmega 328 based 
Arduinos).

Thanks for the input about backlight. As you say, probably not normal to turn 
off the LCD and then write to it (causing backlight flickering, and probably 
more with an RC network to the transistor).

Original comment by raron...@gmail.com on 14 Feb 2012 at 6:42

GoogleCodeExporter commented 8 years ago
I've played with the 2-wire backlight flicker issue, and came up with a RC net 
that almost works. See attached schematics.

For a FPS below 20, of which I've only tested 10 and 14 FPS, one can see the 
flicker a little, but for my eyes it is much better than without the RC net 
shown.

I can also just discern some flicker at 20 FPS, but it's not near as bad than 
without the circuit.

For higher FPS it seems stable and on. I tested 30 and 40 FPS, and my 20 column 
2 line LCD wouldn't go faster with my little test program (The visibility of 
the LCD characters become a bigger issue at 40 FPS, the last characters written 
to it are almost invisible).

But at > 30 FPS the flickering is almost unnoticeable again anyway without the 
RC net (differs from person to person). But without it, it is not off at all 
when "off", just dimmer.

And it is not completely off anyway when "off", but this is unnoticeable (for 
me) in even a dimly lit room (Haven't tested extensively though). In complete 
darkness some faint flicker is visible below 20 FPS, and a very faint stable 
light is visible above 20-ish FPS. At 40 FPS it is slightly brighter, but still 
very dim. And still pretty unnoticeable in a dim room (adding another diode to 
the transistor base fixes this at higher FPS).

Thanks again for pointing it out!

Now i've started to play with the idea of implementing reading the Busy Flag 
(BF), on either the clock or data line. It will add a bit of complexity though. 
And I don't think this is useful in 1-wire mode, as that is pretty slow anyway.

Also, something I thought about, when LCD D7 is configured as an output (BF), 
that's probably not too good being connected directly to another output (the 
shiftregister)? Maybe just add a small-iosh resistor between those two outputs 
too.

Original comment by raron...@gmail.com on 15 Feb 2012 at 5:38

Attachments: