Closed thijstriemstra closed 4 years ago
@rm-hull sent one your way: http://www.ebay.com/itm/191623809073
I've got a load of code for HD44780 LCDs at https://github.com/DougieLawson/RaspberryPi/tree/master/Unified_LCD
@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:
@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.
@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
@thijstriemstra http://www.ebay.com/itm/191623809073 <- arrived
Cool!
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 :)
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.
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!
@rm-hull so this is blocked by https://github.com/rm-hull/luma.core/issues/41?
Yes, would need to implement that in core first I think
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
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
Includes a text interface (implemented using the character class)
ws0010(serial_interface, width, height, rotate, framebuffer, exec_time, bitmode) # subclass of device
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)
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.
Actually, that sounds fantastic. My first question was going to be about doing something like the sevenseg interface, but you already pre-empted that!
Ok, I'll try to get it finished then!
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.
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?
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.
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...
but then someone else came along and nicked the luma package name in pypi (https://pypi.org/project/luma/)
Yea what a douchebag.
Ok, I'll restructure accordingly.
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.
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..
Check out cbor2
cbor2 looks much better, even has a C extension and the maintainer is someone I worked with before.
This is fixed now.
HD44780U Data Sheet: http://www.adafruit.com/datasheets/HD44780.pdf