VFD support in Luma

[PeterWurmsdobler]

Hello,

My apologies in advance for posting that here, but there is currently no luma.vfd ; luma.core seems to be the closest in the absence of as some kind of parent or umbrella project.

How would I go about integrating a VFD display into the code base, a Noritake-Itron GU240x64D-K612A8 which is a graphical unit and can be communicated with over a parallel interface, RS232, SPI and I2C. As it happens I would prefer the SPI as it would provide more bandwidth. My questions:

• where in your code base would it fit into as it is not an LCD or OLED but to a certain degree not so different either?

• what is the abstract interface a driver needs to implement in order to be usable by the higher software layers?

I have already written a C-version of the low level driver for LCDproc some 10 years ago. I would be happy to convert that to python as long as it works over SPI.

Cheers,
Peter Wurmsdobler
Cambridge, UK

[thijstriemstra]

Had to look up what VFD means, but basically old VCR and CD-player type displays? How many types of drivers are there? A dozen or so like OLED nowadays or is it only one or two?

https://en.wikipedia.org/wiki/Vacuum_fluorescent_display:

VFDs can display seven-segment numerals, multi-segment alpha-numeric characters or can be made in a dot-matrix to display different alphanumeric characters and symbols. In practice, there is little limit to the shape of the image that can be displayed: it depends solely on the shape of phosphor on the anode(s).

[PeterWurmsdobler]

Hello and thanks for your response. Yes, VFDs have been used in consumer electronics such as VCR and CD-players in the 80ies, and a bit later in the automotive industry. They are still widely used in medical and industrial applications for various reasons: low cost, wide temperature range, visible in bright sunlight, wide viewing angles, etc. There are quite a lot on the market, e.g. https://uk.farnell.com/c/optoelectronics-displays/displays/vacuum-fluorescent-displays-vfd , mostly by https://www.noritake-itron.jp/eng/products/module . Bottom line: VFD market still alive and growing, but perhaps not as much as OLED.

[thijstriemstra]

Sounds to me this belongs in https://github.com/rm-hull/luma.led_matrix

Thoughts @rm-hull?

[rm-hull]

Hi, so naturally it would fall into a luma.vfd namespace, and I guess since we took a decision some time ago to silo different implementations into different repos and pypi packages, it would make sense to create a separate repo for this. Having said that, it is a decision I now regret (having separate repos/packages) .. it would’ve been simpler overall if there were just one package, but it is what it is, unfortunately.

I think it might be confusing to have these in luma.led-matrix, but I can see why that is being suggested.

In terms of implementation, all your device needs to do is extend the luma.core.device, do whatever initialization in the constructor (using self.command() generally), then in a display method that takes a pillow image, iterating through the pixels and writing data out via self.command and self.data (these abstract over the spi/i2c interfaces)

[PeterWurmsdobler]

Hello and thanks for the explanation. I did wonder what the rationale was in splitting Luma in so many small repos and vend them separately as packages; this appears to be a common trend these days and has some advantages.

To me, what would matter are the levels of abstraction and interfaces. I suppose that the clients/users of Luma (e.g. future pydpiper) would want to use different types of devices in a consistent manner, say:

• create a device object of a certain class and type,
• interrogate device properties such as image size, colour, etc,
• open communication over a certain hardware interface, I2C, SPI, etc,
• write images to the device, perhaps with some frame buffer of some sort,
• and close the communication and delete device in the end.

Communicating the image to the device is specific to certain classes of devices, VFD, LCD, OLED where there may be come communality that warrants some kind of base class and shared functionality. I do not know about LCDs or OLEDs though. That being said, I do not know if device drivers for LCDs, OLEDS, LED matrices are that different all together, and in which respect?

I could also imagine that sending multi-line texts is also part of the device independent interface, and in turn the device configuration tells the user that it can display characters, how many lines at what length. No rendering needed?

As for a for the Noritake VFD, or any VFD for that matter, I would find it consistent with the current division of code and have a luma.vfd namespace, possibly in a different repo?

In terms of implementation, I will have a look at the luma.core.device and see which methods are abstract or need implementation for different devices. I reckon that perhaps some logic to only update pixels that changed is come base class functionality?

[PeterWurmsdobler]

@rm-hull : In order to get something working I have ported an old C interface I once did for LCDproc to python, and it works for me locally. More on https://github.com/PeterWurmsdobler/noritake
Please advise on how that could be integrated with some luma.vfd ; it will need an application layer that makes use of the primitives offered by the Noritake driver, e.g. convert a pillow image into noritake calls.
Cheers, peter.

[PeterWurmsdobler]

@rm-hull in the past weeks, I have been trying to build my own python3 based volumio2 client & VFD controller: https://github.com/PeterWurmsdobler/volumio-vfd . It is loosely based on some pydpiper code and has the concepts of:

• VolumioClient class as a thread producing a PlayerStatus objects into a queue,
• main loop taking items of the queue and feeding an abstract CharacterDisplay,
• CharacterDisplay base class ingesting PlayerStatus objects,
• CharacterDisplayNoritake adapter for the Noritake VFD.

The idea is that CharacterDisplay provides an abstract base class or interface that device specific derived classes implement as an adapter. Perhaps other designs would work, too, with the CharacterDisplay calling on services of an AbstractCharacterDevice that stipulates certain services. In the same vain, I could imagine a GraphicsDisplay that derives from or uses an AbstractGraphicsDevice which in turn is inherited by concrete, device specifics.

The bottom line is, that I would imagine LUMA display devices to be defined by an abstract public interfaces on one side (graphics or character), and call upon some communications protocol on the other (SPI, I2C, UART, etc.). Within a concrete implementation, would be two layers: the bottom layer that implements the command interface to a device or device family and is application aagnostic (e.g. Noritake GU600 family see https://github.com/PeterWurmsdobler/noritake), and the upper layer that implements the LUMA display interface calling on the device family command interface.

I am looking forward to hearing your feedback.
Cheers, peter.

[thijstriemstra]

How would I go about integrating a VFD display into the code base,

Are you still interested in doing this @PeterWurmsdobler?

[PeterWurmsdobler]

Hello @thijstriemstra , thanks for asking, but the answer is no, not any more. I got something working for my media player which suffices for now..