Forum > Embedded
LCD Displays on Pi or Beaglebone
DonAlfredo:
Designing a GUI with Lazarus for a SPI LCD or similar will require you to write a whole new LCL widgetset.
Would be rather nice if you did ... ;-)
PXL allows you to write GUI progs that are more or less transparent with respect to the GUI backend.
But no easy WYSIWYG.
PXL can give you easy access to systems without a standard windows manager.
Have a look here.
https://github.com/LongDirtyAnimAlf/AsphyrePXL
This is a PXL clone adapted to be able to run the test-suite of the mORMot on Android.
I have uploaded some APK to have a look at how this works.
https://github.com/LongDirtyAnimAlf/AsphyrePXL/releases/tag/1.0.0
jcdammeyer:
I don't want to develop on an LCD display. I have on hand:
1. 4DCAPE-43T 320x240
2. Manga1 -- HDMI 4.3" 800x600
3. Manga2 -- HDMI 5.9" 1080P
4. Adafruit -- HDMI 800x400 c/w touch
5. 2.8" TFT SPI 320x240 (3 of them)
6. Some very tiny 64xsomething LCD displays
Even the Manga2 is still quite small (cell phone screen) repurposed with hdmi.
For the HDMI screens clearly the Linux OS will provide the support but I don't want the user desktop and yet I'd like to be able to easily build say a screen like the chart image, develop, test on a full blown Pi or Beagle with larger screen and then install into say a PiZeroW for either SPI or a PC.
For example in the attached screenshot you running (simulated data) an app designed on a Pi, moved and compiled and has run on the Beagle and the screen shot is from a WIN-7 PC where I just compiled it a minute ago. Notice it's anchor point is 0,0 without the standard desktop frame. So theoretically if it's designed to be 800x600 it should fill the entire HDMI screen. If recompiled for 320x280 would still fit on the smaller SPI based screens but rendering it is now different from the larger footprint desktop Linux. But the rest of the desktop baggage can't be there.
And the data to fill it could all come via a CANopen USB based dongle that talks to remote devices that have One-Wire sensors. Or via UDP WiFi IOT type stuff.
So one program, multiple displays, special units with paint functions.
I think... I don't want to rewrite a graphical user interface when so much is already there in Lazarus.
And http://www.autoartisans.com/images/screen.jpg is screen shot of an instrument panel for a project back in the late nineties. Written in Delphi and using an Active X Control library of gauges. The company that developed those was sold and the buyer locked up the development for internal use and so they vanished with WIN-XP. We need more of these types of components with Lazarus.
I'm willing to write these but the end use is still not desktop but embedded hardware. And I really don't want to go the Python route creating forms inline. It's a step backwards.
jcdammeyer:
One other attachment. This is from an article I wrote for Circuit Cellar Ink magazine about my CANRF project. Preceded ZigBee and the new IOT stuff. A series of yard lights either solar powered or wired and even containing PIR motion detectors. It was set up as as mesh network with any one sensor then sending messages out to others to also turn on. The PC application was again written in Delphi. Overlaid on a JPG of an aerial shot of the property each light is shown by the icon. And ON/OFF by colour.
Now I'd probably use a number of inexpensive ESP8266 modules that use the Ardunio development and plant a few WiFi repeaters around but a number of different methods.
And there could be small LCD based displays in various rooms showing the status and providing user control to say turn on sections or garden lights on pathways. Not to mention returning information like temperature, RH, rainfall and wind speed/dir. With Delphi it's even possible to write and compile for iPhones, Android so remote access to the images and menus are possible. But it's not really able to target the PiZeroW or the new smaller Beagles.
So that consistent user interface on all modules lends itself well to Lazarus and Free Pascal. And once developers have used it for a while with all the access to the device hardware the desire to go back to Python will seem so antiquated.
avra:
--- Quote from: jcdammeyer on July 19, 2020, 06:43:29 pm ---For the HDMI screens clearly the Linux OS will provide the support but I don't want the user desktop and yet I'd like to be able to easily build say a screen like the chart image, develop, test on a full blown Pi or Beagle with larger screen and then install into say a PiZeroW for either SPI or a PC.
--- End quote ---
Framework to use SPI lcd screens on linux is http://asphyre.net/products/pxl.
For Pi HDMI displays without linux you can use https://ultibo.org/.
And you can always roll your own SPI lcd screen drawing lib.
However, I think that you gave up LCL too easily. Yes, I know that you don't want user desktop, but you can use minimal linux distro that can boot directly into your application without users ever noticing that. There are minimal raspbian editions that can be striped, or you can use Tiny Core and similar Linux striped distros with/without read only feature. According to the screenshots of what you want to achieve, I still think that it would be best to use LCL on some embedded linux window manager.
One of these links could be used to fit the bill:
http://www.tinycorelinux.net/ports.html
http://www.nard.se/
https://dietpi.com/
http://www.linutop.com/software.en.html
https://hallard.me/raspberry-pi-read-only/
https://alpinelinux.org/downloads/
https://www.graphics-muse.org/wiki/pmwiki.php/RaspberryPi/RaspberryPi
https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi
https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4
There are also Yocto, Balena, Buildroot, PTXDist, OpenEmbedded...
jcdammeyer:
Thanks for the links. I have some reading to do.
John
Navigation
[0] Message Index
[#] Next page
[*] Previous page