5

I would like to boot a Rasperry Pi in headless mode and then use a notebook-sized monochrome LCD display attached to the HDMI port as a DIRECT output device, bypassing the OS. In particular, I would like text labels and numeric data to appear in fixed locations on the screen with the ability to regularly update the numeric data by writing to that location from a Python program (this will be a text-based instrument panel for an experimental home-built airplane). It seems like a simple and obvious thing to do, but I have been unable to find any clues how to do it. Most references I have found to directly writable LCDs are for 40x2 (or smaller) character displays, whereas I need considerably more real estate for displaying multiple variables simultaneously (possibly some simple graphics too, but I can live without it if necessary).

I would consider an arrangement in which the OS does share the monitor, but only if it can be made to completely disappear after the program is started, ensuring direct and exclusive access to the screen for the aforementioned real-time display.

In the old days working with an IBM/DOS computer, I could control the non-windowed screen display very simply by poking characters or bit data into specific physical memory addresses. I'm basically trying to find a way to achieve equivalent functionality with today's hardware, presumably through a layer of software that knows how to talk to the hardware. Sample pseudocode:

  1   open screen device on HDMI port and set any relevant modes
  2   specify a starting screen address (row and character no.) and write a
      N-character string to that location
  3   repeat

Any pointers?

2

2 Answers 2

3

After seeking advice in a number of venues, both online and offline, and running into mostly dead ends, I ended up deciding that my best option was NOT to try to separate the display from OS control and write to it using a low-level interface, as that seemed to be fraught with complexities.

Rather, it satisfies the intent of my question (if not the details) to run a program that would launch on boot, open in full-screen mode and simply cover up everything else until the program terminated.

For that purpose, the Tkinter/Canvas module for Python seems to offer the "friendliest" environment for not only creating the full-screen window but also writing arbitrary text and simple graphics to arbitrary locations on the screen. It's much easier to use than any alternative I have seen so far.

A minimal working example was posted here by someone else: https://stackoverflow.com/questions/47856817/tkinter-canvas-based-kiosk-like-program-for-raspberry-pi

I have already found that I can do pretty much everything I wanted to do starting with that example.

2

What I think you mean is that you do not want to have a GUI running on the HDMI display. You will instead turn off any local logins on the console and then run an application, probably with the NCurses library which provides the sort of low-level CLI interface that you desire except that you use functions that produce the display desired into the buffers that it provides. NCurses role in this is to provide an abstraction so that the content is transferred to the display hardware (or framebuffer) in as fast and efficient manner as possible - what- and where-ever that hardware is...

There are also parts that handle getting input from the user and you could make it easier to test and construct by doing it as a program that runs from the text login console and eventually prevent it from exiting and prevent the Alt-F key-presses that normally cause Virtual Termnal switching.

4
  • I think the question needs to be updated with an explanation as to whether there are real time display changes required so that if the airplane is changing altitude rapidly or heading rapidly the display status can be in real time and synchronous with real world events. Not sure how much overhead and delay would come from NCurses and a terminal window. Commented Dec 14, 2017 at 5:13
  • Regarding SlySven's comment: I'm aware of ncurses and have thought about it as a solution to my problem. What I'm not clear on is whether I could have a remote login to the Pi for general interaction with the OS while letting ncurses take control of the physically attached monitor. Regarding RC's comment: I don't think the overhead and delay would be too significant, as long as no process comes along and suspends or blocks the ncurses output for more than a second or two. Also, unless I'm mistaken, ncurses does not support any kind of graphic output to the screen. Commented Dec 14, 2017 at 19:05
  • It seems that one possible way to get to where I want to be is to run the Pi with a browser in kiosk mode and then figure out a way to display the data I want in the browers (with automatic real-time updates). danpurdy.co.uk/web-development/… Commented Dec 14, 2017 at 22:03
  • Well, yeah, you could run a GUI on an xserver (look into using xinit(1) with your application run as the client program instead of a window manager) - I understand a tcl/tk combination may be something that could provided you with the sort of widgets you want...
    – SlySven
    Commented Dec 17, 2017 at 0:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.