LCDproc development and user support list

Text archives Help


[Lcdproc] I2c HD44780 patch to read pin config from LCDd.conf


Chronological Thread 
  • From: ethan.dicks at gmail.com (Ethan Dicks)
  • Subject: [Lcdproc] I2c HD44780 patch to read pin config from LCDd.conf
  • Date: Sat, 15 Aug 2015 01:01:54 -0400

On Sat, Aug 15, 2015 at 12:07 AM, github at wilberforce.co.nz
<github at wilberforce.co.nz> wrote:
> here is an example config:
> i2c_line_RS=0x01
> i2c_line_RW=0x02
> i2c_line_EN=0x04
> i2c_line_BL=0x80
> i2c_line_D4=0x10
> i2c_line_D5=0x20
> i2c_line_D6=0x40
> i2c_line_D7=0x80

Hi, Rhys,

I haven't done anything with i2c-interfaced LCDs (just serial, USB,
and direct/parallel-I/O) so please excuse what could be an obvious
question, but why a hex bitmap for specifying the lines? Is this
creating a pinmap for 8-bits of a specific I/O expander chip? Is this
a new thing or are you extending an existing mechanism? If it's just
a pinmap, why add complexity here when it's rather normal for LCDproc
to say "wire your LCD with *this* specific pinout" rather than "wire
it any way you want and tell the Config file how you wired it"? I
don't see a problem telling the user that they have to put the data
lines adjacent and in the upper (or lower) 4 bits, for example. Yes,
software can adapt to any hardware configuration, but I'm questioning
the tradeoff of flexibility vs complexity. When we were wiring LCDs
to parallel ports, there were a few specific documented pinouts (more
than their should have been, IIRC, because of people reinventing the
wheel, but that's another problem). We certainly weren't so flexible
as to allow random wiring that was matched up in software, which is
what this looks like to me.

-ethan




Archive powered by MHonArc 2.6.18.

Top of page