Interfacing a 16x2 char HD44780 LCD display

[Mark A. Yoder]

I've just recently discovered I have access to lots of 16x2 LCD displays.

I see there are many examples of interfacing it to a Linux machine, but most are via user space.  I'm looking for kernel space examples.  modinfo hd44780 shows a driver is there, but how do I use it.  

Is there a device tree for the hd44780 for a parallel interface?

--Mark

[Dennis Lee Bieber]

On Thu, 29 Oct 2020 11:39:54 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "Mark A. Yoder"

<mark.a.yoder-Re5J...@public.gmane.org> wrote:

>
>Is there a device tree for the hd44780 for a parallel interface?
>

I suspect the true parallel interface has become somewhat deprecated --
most later displays using that protocol have incorporated a sub-board that
does serial<>parallel (I2C or SPI, maybe even plain UART).

One problem is that the parallel mode supports TWO configurations:
8-bit parallel and 4-bit parallel. When you add in the other control
signals, you can easily consume 11 GPIOs (in 8-bit mode; 7 GPIOs in 4-bit).

Since the Beagle doesn't seem to expose a parallel load for GPIOs
(unlike the Arduino AVR and BASIC Stamp which expose PORTx registers), that
leads to 4/8 slow, single-bit, loads. cf:
https://groups.google.com/forum/#!topic/beagleboard/WZxfbaHipWA

Using a PRU might be feasible for this (though where the GPIOs are
exposed may not be contiguous to the bits in the PRU GPIO register).


--
Dennis L Bieber

[Robert Nelson]

There is a relatively new driver for this, i just don't know of anyone
who's worked out a device tree for it..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/auxdisplay/hd44780.c

Here is one example i found, just need to list the gpio's..

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-370-netgear-rn104.dts?h=v5.10-rc1#n146

Regards,

--
Robert Nelson
https://rcn-ee.com/

[amf]

Hi Mark

Seen RCN's response below. I have several of the hd44780 LCD displays also, spent the weekend trying to get it to work with the info RCN provided. Seems the R/W line is always high, thus all the data signals are distorted. If I pull the R/W line low, then the data signals are ok, but nothing is written to the display. I know the displays are good, I wrote a uart-to-parallel with an atmel chip several years ago. if you have success with the Linux driver, I would like to know.

amf

[Fisher Grubb]

Hi all,

I'm in the process of doing a project with the PRUs, only just started, and learning how to do MUX and pad settings etc, using TI's hands on labs, plus have seen some of your work Mark.

I'll be later using a 20 x 4 char LCD which is the same interface & protocol.

Is that something you'd like me to post back here if/when I get it all working?

As long as I can get MUX and other settings done to allow the PRU access to the pads/pins, then should all be fine.

Fisher

[amf]

Just wanting to follow up on this. The LCD display is working, just had to remove the R/W parameter from the dts and tie the LCD R/W to ground. The driver does not seem to support reading from the display, so no harm in doing it this way.

amf

[Mark A. Yoder]

Thanks to all for following up on this.  

amf:  What device tree are you using?

--Mark

[amf]

Hi Mark,

I do custom builds with yocto, the meta data is from jumpnowtek. kernel version linux-stable_5.7

In addition to the info that RCN provided, I added the pin mux stuff to define all the gpio pins.

looked at the driver for the R/W issue, seems they do not set the R/W bit, they do set the RS bit, so maybe just need to add the same for the R/W bit.

amf

[amf]

I may not have answered your question, the dts is bbb-4dcape70t