LCD Displays on Pi or Beaglebone

[jcdammeyer]

A number of years ago I bought a 4DCAPE-43T for the Beaglebone Black.  I think Rev 7 Wheezy at the time. 
https://www.mouser.ca/datasheet/2/451/en4-4dcape-all_datasheet_r_1_1-1627121.pdf
Support from the company was really not there and I think it's been discontinued. 

It's always been my plan to use Lazarus for this or other LCD displays that are non-HDMI as say instrument panels or information panels.  The trouble is in many cases, like for this one, they configure the cape display as the user interface.  But a full Linux screen isn't wanted nor all the borders etc.   

I would rather develop the Lazarus application to run on the Pi or Beagle and create a frame that has all the stuff I want and has the same dimensions as the LCD display.  So if it's 320x280 then that's the size of the frame and all the components are inside that.   If it's an SPI based LCD display then a call to paint should theoretically be able to grab what is essentially an array 320x280 of say 16 bit or 24 bit RGB values.

And dump it out to the display.  In the case of the Beagle Bone I believe this display can be directly addressed through the device ports but from an abstract perspective the starting point needs to be painting the frame or portions of the frame.  Speed can be increased by only painting the button that's been pressed.  As in only that small chuck of screen image needs to be transferred.

Is there already an infrastructure in place for this sort of thing?  I really don't want an HDMI 800x600 screen to the the Linux User Interface screen. 

So which subject heading under Forum here is the best place to discuss this?  It requires knowledge of Beagle/Pi hardware (SPI devices for example) and the painting of parts or whole of a frame.  In fact the Beagle or Pi might even be of the headless type that doesn't have a user display.  ie. command line.  But still I'd like the graphical features that Lazarus provides rather than a GTK or other tool box.  With those we lose what Lazarus gives us for program development.
Thanks
John

[jcdammeyer]

Perhaps I can add onto this a bit.  The two attached screen shots show two images I'd like put onto an LCD display.  The one with the standard window border is a python program.  The chart is a Lazarus program.  Needless to say the Lazarus once was simple to make.

The Python uses the TKinter library but won't run from an SSH session because there is no graphics screen.  Haven't tried the Lazarus one but I suspect it will be the same. 

So how does one run a Lazarus program and make use of all the excellent components from a command line that won't support graphics.  But captures the graphical image to send out via SPI or direct to ports on the processor.

And if this is the wrong subforum  please point me in the right direction.

[DonAlfredo]

https://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#PXL_.28Platform_eXtended_Library.29_for_low_level_native_access_to_GPIO.2C_I.C2.B2C.2C_SPI.2C_PWM.2C_UART.2C_V4L2.2C_displays_and_sensors

[jcdammeyer]

https://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#PXL_.28Platform_eXtended_Library.29_for_low_level_native_access_to_GPIO.2C_I.C2.B2C.2C_SPI.2C_PWM.2C_UART.2C_V4L2.2C_displays_and_sensors

Thanks! I'll play with that a bit.
John

[jcdammeyer]

I captured the Mandelbrot example and compiled it on the Beagle and PC with Lazarus and made the small changes required to compile it with Delphi 10.3.3

Running it from the command line on the beagle in a console window creates the form and draws the figure.  I think if I wanted that output on a say a small adafruit lcd SPI bus LCD display then I'd have to override the paint method to send the the imagebuffer canvas out.

Code: Pascal  [Select][+][-]

1. procedure TMainForm.FormPaint(Sender: TObject);
2. begin
3.   Canvas.Draw(0, 0, ImageBuffer);
4. end;
5.  

But running that same application from an SSH terminal

debian@ebb:~/lazarus/Mandelbrot$ ./mandelbrot

(mandelbrot:11924): Gtk-WARNING **: cannot open display:


Which suggests that even if I did change paint to deal with hardware a command line version of Debian wouldn't even allow the Lazarus application to run.

I did find
https://sourceforge.net/projects/asphyre/
with examples for output to SPI LCD. displays.  But then I'm back into the Python etc. world where the graphical objects are placed with coding rather than the convenience of Lazarus.

Is there a solution where FormPaint or Paint or Repaint can be set for custom hardware and still load in a non-window environment?  If I plug in the 4DCAPE-43T the HDMI has to be disabled to run it.  And I don't want the entire window environment sent to it.

Or am I stuck with not using the 4DCAPE-43T and use a system that has graphical and just doesn't have a USB keyboard/mouse and HDMI monitor connected.  And have it start up running the Lazarus app that has paint overridden?

Thanks
John

[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]

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.

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

[jcdammeyer]

Here is another example of how easy it is to develop and test on the PC with either Linux or Windows and why I want to use Lazarus as is.

Once I had it working on the PC I did a drag and drop the folder onto in this case a BeagleBone Black running Stretch.  The Beagle has a cable attached to a proto cape that runs to a board with a DS1822 temperature sensor/serial# chip.  The driver on the Beagle automatically updates the file with two lines of information when it's read.

The application loads the File Dialog so you can find the w1_slave file in the folder with the devices serial #.  Then when you click on OK it parses the strings of characters and generate the temperature to update into RackCtls package LED display I found on line by searching Lazarus 7 segment LED display.

The two attached screen shots show the result.  With components like the LEDs and the graphs from Lazarus and an hour to write the application nice user interface applications with small LCD displays are trivial.

I'll add some documentation to the program and zip it up and attach it onto this subject thread.  the program is huge but meant to test the parsing of some of the code.  The LED display was an afterthought.

[avra]

Here is another example of how easy it is to develop and test on the PC with either Linux or Windows and why I want to use Lazarus as is.

That's one of the reasons why I advise sticking to LCL.

The Beagle has a cable attached to a proto cape that runs to a board with a DS1822 temperature sensor/serial# chip.

Have this in mind: https://www.cnx-software.com/2020/07/13/fake-ds18b20-temperature-sensors-counterfeit-clones/

The LED display was an afterthought.

You made me smile showing 3 decimals for the temperature. 

[jcdammeyer]

Have this in mind: https://www.cnx-software.com/2020/07/13/fake-ds18b20-temperature-sensors-counterfeit-clones/

You made me smile showing 3 decimals for the temperature. 

Ha ha.  It comes from the driver in the Beagle.
5d 01 4b 46 7f ff 03 10 8c : crc=8c YES
5d 01 4b 46 7f ff 03 10 8c t=21812

Divide by 1000.

Not worried about fakes.  Mine were quite expensive even in 1000 qty.  The board this particular sensor is connected to came from this:
http://www.autoartisans.com/rings/Barge1a.jpg  The face of each lamp had one sensor in order to provide a unique serial number for each lamp which were on a CAN bus.  We ended up using the temperature too.
http://www.autoartisans.com/rings/temperatures.jpg
The set at YVR airport one day in July had some lamps hit 60C. Very red on the display screen.  I wish I'd captured a screen shot from that day now.  When they were cold they were blue. Hover over the lamp indicator and at the bottom of the screen you'd get the reported temperature.
The lamps on the barge also reported DC voltage so the dual display but this screen shot doesn't shot that. http://www.autoartisans.com/rings/BargeRingsTemperatures.JPG  The set facing North wasn't was warm as the set facing south.

Oh and the PC software?  Delphi-7.  PIC18F processors in the lamps (C code).  Controller M9S12XDP512 (C-Code).

Going to take a closer look at this tomorrow.  Now after midnight here.


          Platform eXtended Library v1.1.0, dated 9-Dec-2017.
             Copyright (c) 2000 - 2017  Yuriy Kotsarenko
                   https://asphyre.sourceforge.net
                   https://asphyre.net

-------------------------------------------------------------------------------

This product requires either Embarcadero Delphi XE 8 (or any later version) or
FreePascal 3.0 with Lazarus 1.4 (or any later versions).

When used with Embarcadero Delphi, the following platforms are supported:

1) Windows 32 and 64-bit
2) Mac OS X
3) Android
4) iOS 32 and 64-bit

[avra]

This product requires either Embarcadero Delphi XE 8 (or any later version) or
FreePascal 3.0 with Lazarus 1.4 (or any later versions).

I have mentioned it for Pi and BB using Laz/Fpc. This is from https://asphyre.net/products/pxl:

Raspberry PI
- Fast access to CPU timer, GPIO, I²C, SPI and UART using direct manipulation of SoC registers.
- V4L2 video/image capture using onboard and USB cameras.
- OpenGL ES rendering with and without X server, including drawing to bitmaps. One of examples shows how to render your visual scene with GPU and then pass it to external display via SPI wiring!
- ...and many other features that are available for generic singleboard platforms.

BeagleBone Black
- Easy access to native Linux Sysfs interfaces such as GPIO, PWM, ADC, I²C, SPI and UART.
- Serial cameras such as VC0706 and LSY201.
- I²C and SPI displays such as SSD1306, SSD1351, PCB8544 (Nokia), HX8357 and ILI9340.
- Character LCDs with direct pin wiring.
- Support for Software SPI and UART (bit-banging).
- Support for SC16IS7x0 (UART controller connected via I²C or SPI), including extra GPIO pins.
- Support for sensors such as BMP180, DHT22, L3GD20, LSM303 and SHT10.
- Networking communications through UDP protocol.
- Video/image capturing through generic V4L2 interface.
- Software rendering for visual effects and user interfaces.

You can completely avoid PXL if you use LCL, since there are other libs for access to GPIO, SPI, I2C, serial...
https://wiki.freepascal.org/Hardware_Access
https://wiki.freepascal.org/Lazarus_on_Raspberry_Pi
https://wiki.freepascal.org/Raspberry_Pi_-_SPI

[jcdammeyer]

This product requires either Embarcadero Delphi XE 8 (or any later version) or
FreePascal 3.0 with Lazarus 1.4 (or any later versions).

I have mentioned it for Pi and BB using Laz/Fpc.
You can completely avoid PXL if you use LCL, since there are other libs for access to GPIO, SPI, I2C, serial...
https://wiki.freepascal.org/Hardware_Access

Yes. And thanks for that link.
But the LCL and the link to
https://wiki.freepascal.org/Hardware_Access
seem more to address windows parallel ports than what is required for the Beagle. I must admit it's been over two yeas since I let the beagles out of their kennel.  Been too busy with work-work projects.  And the changes in how hardware is accessed over the lifetime of that device has been unsettling.  I'm pretty sure the .dts files are still required.  The Buster version is only available as command line not windowing.  Maybe I should wait just in case the Beagle world has changed yet again.

The easy way to the I/O is just with the file operations. 

Code: Text  [Select][+][-]

1. debian@ebb:/sys/class/gpio/gpio68$ ls
2. active_low  device  direction  edge  label  power  subsystem  uevent  value
3. debian@ebb:/sys/class/gpio/gpio68$ cat label
4. P8_10
5. debian@ebb:/sys/class/gpio/gpio68$ cat direction
6. in
7. debian@ebb:/sys/class/gpio/gpio68$ cat value
8. 1
9. debian@ebb:/sys/class/gpio/gpio68$
10.  

So slow I/O for turning on relays or reading switches isn't super difficult but certainly isn't compatible with the Pi.  So the moment we dive into the world of control systems the software becomes somewhat system dependent.
But then that's true to a certain extent for embedded systems of any sort.  Although I follow the same style regardless of whether I'm writing for a PIC18, dsPIC30 or PIC32 and M9X12X.

Generally the port bits are represented with a macro or a function that 'hides' the actual hardware so it can be moved inside the IOMapping.h file without affecting the application.

Code: C  [Select][+][-]

1. if (fPowerSwitch) {
2.    ...
3. }
4.  

The fPowerSwitch may well be a bit in a byte which is kept up to date via a PDO CANopen message from the network or local hardware.  Or it may be local hardware.

In Lazarus or Delphi my guess would be to abstract it with property statements like

Code: Pascal  [Select][+][-]

1.     property PowerSwitch: TPortBit read FPowerSwitch write FPowerSwitch;
2.  

and then

Code: Pascal  [Select][+][-]

1.   if PowerSwitch then begin
2.      ...
3.   end;
4.  

Now once again, depending on the Pi or Beagle or even PC where the power switch is doesn't matter.  It could be on the parallel port of an embedded PC and the LCL ports are used.
Or just as easily on a CANUSB dongle with CAN bus support through the CAN library.
Or SPI bus and a port expansion chip.

But I need to get myself up to to date on how I/O is handled on the Beagle because the changes somewhere around 2017 or so were very significant.  I believe the dts files are still needed. 

At that point I didn't consider using Lazarus between a Pi and a BBB.  But now things have changed.

I'll let you know what I find.