The LCD needs a minimum voltage to change status. A module designed for
5 volts (the most usual) has an LCD with a threshold higher than 3.3 V, so if you supply the module (and hence the HD44780) with 3.3 V the LCD will stay blank.
The LCD needs a minimum voltage to change status. A module designed for
5 volts (the most usual) has an LCD with a threshold higher than 3.3 V, so if you supply the module (and hence the HD44780) with 3.3 V the LCD will stay blank.
I don't remember anyone ever suggesting that you supplied the module with 3.3v.as a POWER SUPPLY.
The argument was whether the 3.3v *logic output* of the GPIO would be enough to drive the chip when the chip was being supplied with 5v.
The answer is, on the spec, yes.
Are R-Pi GPIOs 5-volt tolerant?. If not, you can connect the module only if you don't read from it. This means using a delay instead of checking the BF flag before writing.
No, they are not
Exactly. We need to use ist either in readonly mode or add an additional level converter chip.
Sven
In 4-bit mode you can do it with just eight resistors.
No need for resistors in readonly mode.
See schematic at adafruit:
Sven
They're not 5v tolerant - well - they might be for a few nanoseconds ;-)
Most drivers I've seen on most microcontrollers don't bother with reading the status bit anyway - when I put mine together I tied the r/w pin to 0v forcing the display into read only mode. The timing for the long-time operations is published anyway (e.g. clear, home) so trivial to impement. Only 6 wires needed for 4-bit mode to the display. I also worked out that you can connect multiple displays to the Pi too - just need one more wire per display and off you go (that was a specific request from a client).
The question in-hand is whether they ought to be part of the kernel or have some other driver that you can use to use "standard" curses, etc. libraries, but hey, they Pi is all about programming and interfacing (to a lesser degree), so just get on & program... And who's to say (e.g.) my C driver code isn't "standard" anyway - it's my standard ;-)
Gordon
I was wondering pretty much the same thing. What's wrong with a user-mode app taking input from a named pipe, or if it really must be a terminal a pty? No need at all for kernel programming with all the hassle that imposes.
What I don't know is if there's a sufficiently generic GPIO framework that we can say:
Take hd44780lcd.ko Plug in GPIO 73 into R/w Plug in GPIO 34 into D0 GPIO 45 is an interrupt Now create /dev/hd44780lcd0
and make it work, given that the 'plumbing' between the LCD driver module and the SoC is something the user controls. From what I've seen, OpenWRT makes a meal of this because every router, even using the same SoC, has a different pin to enable wifi power/talk to the SPI flash/drive the LEDs, and every router has a different C file in the kernel to describe this. But it doesn't work if the user can change that mapping.
Theo
Good point: However, I don't (yet) need an HD447800 or equivalent. When I do, I'll want something like the display used in the device formerly known as the Squeezebox Touch (which looks like a 4.2 LED panel) or (slaver, slobber) a 4.2" or 5" eInk display - either mono or colour would do nicely.
I was really hinting that Sven might like to work on writing a driver that appears as a device file in a similar fashion to the serial drivers and that, like them, can be configured by a utility program that sets parameters in the device file.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required