Support for 16x2 and 20x4 LCD displays

[thijstriemstra]

HD44780U Data Sheet: http://www.adafruit.com/datasheets/HD44780.pdf

[thijstriemstra]

@rm-hull sent one your way: http://www.ebay.com/itm/191623809073

[DougieLawson]

I've got a load of code for HD44780 LCDs at https://github.com/DougieLawson/RaspberryPi/tree/master/Unified_LCD

[rm-hull]

@DougieLawson - the bare metal stuff looks interesting in that repo, does it boot up ok? A wee while ago I had the idea of writing a bare metal forth machine for the RPi (actually got quite far making it work on i386, but I ran out of steam, so its mainly just sat on a shelf bit-rotting these days)

@thijstriemstra - So looking at that HD44780 datasheet and the pic on ebay, looks like there are two main challenges here:

• Implementing a parallel interface with software bitbanging, else using something like an MCP23017 chip like Dougie's implementation
• Translating the Pillow ImageDraw canvas draw method for 'custom' graphics, and an overlay for text (similar to how the max7219 device works with its sevensegment wrapper)

[thijstriemstra]

@rm-hull I'm currently using the https://github.com/dbrgn/RPLCD library for this, but I'd like to use a single luma.core API. There are probably some clues in that library.

[DougieLawson]

@rm-hull used to boot OK on a RPi1B, so it would probably run on a Zero. I haven't looked at that code since Jul 2014. There's lots of modern bare metal stuff (probably better than my hack) on https://github.com/ultibohub/Core & https://github.com/rsta2/circle

[rm-hull]

@thijstriemstra http://www.ebay.com/itm/191623809073 <- arrived

[thijstriemstra]

Cool!

[combs]

just a thought, maybe it makes sense to draw a distinction between character-based LCDs (HT1621, HD44780, HPDL1414) and graphical LCDs in the codebase. They seem very different under the hood and in usage.

I think I can swap ssd1306 and pcd8544 just by changing the constructor, but ssd1306 to hd44780 would take quite a bit of work in user code :)

[rm-hull]

Yes HD44780 is possibly a step too far in its default character mode, but think they do have some GDRAM that could be equated to a drawable canvas. The HT1621 is only usable by wrapping it with the sevensegment class.

[combs]

oh huh! AFAIK hd44780 only has 8 customizable characters. Maybe with some trickery, like changing them partway through a line. Like in the "racing the beam" days. ha!

[thijstriemstra]

@rm-hull so this is blocked by rm-hull/luma.core#41?

[rm-hull]

Yes, would need to implement that in core first I think

[dhrone]

I'm a bit late reaching out but wanted to share that I'm close to finishing the implementation of a solution to this as well as rm-hull/luma.core#41. As soon as I finish cleaning up the code, documentation, and writing the test cases, I should be able to request a pull.

I've added the following classes...

luma.core.interface.serial:
parallel(pulse_time, gpio, RS, E, PINS)# yes I appreciate the irony in the name
- Implements the bit-banging functionality that a RPi/HD44780 requires if using a bus style interface (supports 4 and 8 bit modes)

pcf8574(bus, port, address, pulse_time, backlight_enabled) # subclass of i2c
- Implements the bitbanging style communications needed for the PCF8574 i2c backpack

luma.core.virtual:
character(device, font, undefined) # implements a text interface for character displays similar to the sevensegment class

luma.lcd.device:
hd44780(serial_interface, width, height, framebuffer, default_table, undefined, exec_time, bitmode) # subclass of device

• Implements a graphics style interface into the hd44780 (limited by the amount of CGRAM available which is typically 8 characters)
• This can be surprisingly useful with careful screen design. To leverage successfully...
  • Design your screens so that only eight unique 5x8 images are displayed at one time
  • Fill remaining screen regions with 5x8 images that come from the embedded font table
  • Make sure that alignment of the regions adheres to the 5x8 character structure of the display
• Includes embedded font tables that replicate the A00 and A02 font tables that are common on HD44780 devices
• Maps unicode values to the appropriate glyphs in each of the tables
• Auto-assembles the font tables into a master font which allows all of the glyphs across the two font tables to be leveraged
• Includes a text interface (implemented using the character class)

ws0010(serial_interface, width, height, rotate, framebuffer, exec_time, bitmode) # subclass of device

• This is the controller that the Winstar WEH and WEG displays leverage which supports the HD44780 command-set but...
• Can be driven as a full graphical display. This class leverages that capability
• Includes the four ws0010's font tables (English_Japanese, Western_European_I, English_Russian, Western_European_II)
• Maps unicode values to the appropriate glyphs in each of the tables
• Auto-assembles the font tables into a master font which allows all of the glyphs across the four font tables to be leveraged

weh001602a(serial_interface, width, height, rotate, framebuffer, undefined, font, default_table, char_font, exec_time, bitmode)

• The weh displays are intended for character displays
• This wrapper class to ws0010 adds a text interface (using the character class)

If I'm heading off in the wrong direction let me know. Otherwise, I'll try to get this wrapped up in the next week or so.

[rm-hull]

Actually, that sounds fantastic. My first question was going to be about doing something like the sevenseg interface, but you already pre-empted that!

[dhrone]

Ok, I'll try to get it finished then!

[thijstriemstra]

As soon as I finish cleaning up the code, documentation, and writing the test cases, I should be able to request a pull.

Holy shit, I hope you will! Don't hesitate to open a pull request early so we can provide feedback and/or contribute.

[dhrone]

I've got a module placement question for you. The code I'm working on supports the HD44780 compatible devices (LCD) as well as the Winstar ws0010 devices (OLED) which are largely HD44780 compatible but have enough differences to make them their own class but also leverage a couple of shared classes.

So the question is, does it make sense from a LUMA perspective for the Winstars to be part of the luma.lcd project? That's where I've currently placed them so that I don't have to create dependencies between the luma.lcd and luma.oled projects. Do you support that alignment or would you prefer the winstar devices be placed in the luma.oled project?

[thijstriemstra]

LUMA perspective for the Winstars to be part of the luma.lcd project?

Yes, +1

That's where I've currently placed them so that I don't have to create dependencies between the luma.lcd and luma.oled project

If there is any danger of creating dependencies between sub-projects: put it in luma.core.

[rm-hull]

If you look at https://luma-oled.readthedocs.io/en/latest/api-documentation.html you can see this hierarchy diagram:

Perhaps like @thijstriemstra says, put the base class in luma.core, maybe called something like luma.core.device.character_device ?

And then in luma.oled, luma.oled.device.ws0010 extends luma.core.device.character_device.
For luma.lcd, luma.lcd.device.hd44780 will need to inherit from both luma.core.device.character_device and luma.core.device.backlit_device.

---

I now regret not creating a single repo with all drivers regardless of type, not least because we could've just had a simpler namespace and less tangled releases, but then someone else came along and nicked the luma package name in pypi (https://pypi.org/project/luma/)

Hey ho...

[thijstriemstra]

but then someone else came along and nicked the luma package name in pypi (https://pypi.org/project/luma/)

Yea what a douchebag.

[dhrone]

Ok, I'll restructure accordingly.

[dhrone]

TLDR; Can I add pypi:cbor as a dependency to lcd.core?

One of the classes that my two drivers use is an embedded_font class. Right now it is VERY specific to the two drivers so I am looking to generalize it a bit since it will be living in core now. It requires that I store the binary font data for the displays which I am placing in const.py. I am currently using the PIL font format which is limited to 256 glyphs per font so there are some ugly workarounds that I've leveraged to extend beyond this. So, I'm creating my own font format that largely follows the PIL font but removes the limitation. To do that, it would be good to have an easy way to store binary data and I came across the CBOR protocol which seems perfect for the purpose. So the question is whether you would object to adding a dependency from luma.core to pypi:cbor. Let me know if this is ok, otherwise, I'll just continue to use the PIL format. Alternatively, if you have a recommendation on a way to convert bitmap data into Truetype fonts that would be another way to go.

[thijstriemstra]

Can I add pypi:cbor as a dependency to luma.core?

The last release for cbor was in 2016 and there are quite some issues: https://bitbucket.org/bodhisnarkva/cbor/issues?status=new&status=open so it seems unmaintained to me. I'm +0 on this..

[dhrone]

Check out cbor2

[thijstriemstra]

cbor2 looks much better, even has a C extension and the maintainer is someone I worked with before.

[thijstriemstra]

This is fixed now.