-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add textual LCD display driver support #51912
Comments
@thedjnK I tested it on the component and it is working. Pictures here (scroll down): https://github.com/nuertey/ZephyrOS-WeatherStation |
And I forgot to mention--and this is most relevant to your feature request--that I based my implementation on the official sample: https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/lcd_hd44780 |
It's not really what I'm asking for, I'm asking for a driver class to support implementing these types of displays, the HD44780 is a generic one but the one I'm interested in is UART-based for a noritake VFD. The idea behind this freature request is to get the driver and function pointers created so that a driver for any type of textual display can be implemented, and with drop-in replacement support for any other textual display just by changing the module, DTS and a Kconfig. |
Understood. |
One misc driver that could likely be converted to such class: https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/misc/grove_lcd_rgb |
Architecture WG
|
I think what @thedjnK is really looking for is a package like ncurses above the character display. ncurses has been around a longtime and a subset of the basic ncurses APIs are probably reasonable for this project. The list of functions @thedjnK suggested did not include:
I don't think the ncurses underlying termcap database is required. The Zephyr equivalent is probably a set of macros and defines that describe each display's capabilities and allow unusable features to be compiled out making the code as small as possible. Possibly the terminal capabilities could be embedded in the device tree entry for the device. ncurses also includes a whole set of input functions, but these are probably not necessary for a character display. ncurses is also capable of handling multiple windows this would be useful on a system with multiple character displays. I am not suggesting that we port ncurses, that would be crazy, just use some of the basic ncurses APIs and do our own simplified implementations. Update - I took a look at the ncurses APIs, and I have a suggested subset attached. |
I'm not. |
Every function you asked for is covered by the ncurses API. |
This has nothing to do with ncurses. It's a driver API for a specific class of display hardware: text based displays (as opposed to graphical/frame buffer displays, which are already supported by Zephyr). ncurses is a library for creating text-based user interfaces (TUIs). Now, one might want something along the lines of ncurses in Zephyr, but that would still need to operate on top of a low-level hardware driver API like the one suggested here - and it is out of scope for this PR. |
Is your feature request related to a problem? Please describe.
At present, zephyr has a display driver which is very much suited to graphical LCDs whereby e.g. images can be displayed, however it is lacking for support of textual-based displays, e.g. HD44780-based displays, or those with an SPI/I2C interface that support limited commands, essentially for moving a cursor, writing text or clearing the whole display. It would be beneficial to have a display class that supports the functionality of these basic textual displays, either as a new dedicated interface or by expanding the existing display interface to support the required functionality
Describe the solution you'd like
The driver would need to have the following functionality:
Optional nice to have functionality:
The display configuration would be set via device tree, the type of driver and interface would be needed alongside the number of characters for width, height and likely the character set that the display supports. For HD44780-based displays it would also need the mode to operate in, 4-bit or 8-bit mode.
Describe alternatives you've considered
Use the existing display driver, but the required functionality is just not present
The text was updated successfully, but these errors were encountered: