Prototype Effort - Will uGFX work for us?

[Adam M]

Hi,

My company and I are investigating purchasing uGFX for a product deployment. However, I have been having difficulty trying to get uGFX to function in our production environment. Before giving up and moving to an alternative solution, I wanted to see if any had any ideas (or even expected that our use-case might be supported).

Our Production Environment:

• Prototype Board: BeagleBone Black Wireless
• Architecture: armv71
• OS: Debian Stretch 9.3

I figured we would use your SDL2 Linux Framebuffer support. However, your guide for Linux suggests that I must install the i386 SDL-dev package due to uGFX requiring a x32 bit compilation - as such it seems that I don't have a way to get this to work in our production environment.

It appears there isn't an available installation of gcc-multilib that would work on our architecture either.

Let me know your thoughts, and thanks in advance,

Adam M.

[Joel Bodenmann]

Hi & welcome to the µGFX community!

Your use-case & environment is definitely fully supported. µGFX has been designed to run on literally any platform. Your platform is very common among µGFX users.

I don't exactly understand what's keeping you from just using the 32-bit SDL2 package? It is not a "hack" or "workaround".

[Austin]

Hello Joel,

I work with Adam and will be taking up this project. Our biggest question would be if you have a guide to running uGFX on the Beaglebone Black Wireless. In the guide Adam linked it is suggested to use the i386 SDL--dev package to compile against uGFX, however, that debian package is not compatable with the Beaglebone Black Wireless architecture. Are we missing a simple step?

Thanks in advance,

Austin L.

[Joel Bodenmann]

Hello Austin!

The first thing you need to do is figuring out whether you really want to run µGFX as an SDL2 application on your target. In most cases, people running µGFX on Linux on embedded devices use the framebuffer driver. SDL2 requires you to have a desktop environment which is horribly slow & heavy and that's usually not something you're after if you're actually using µGFX. µGFX has been designed to be extremely lighweight and fast. Running it inside a desktop environment brings very little benefits. Whenever you have a desktop environment that allows to run SDL2 application you already have some sort of GUI toolkit such as GTK or KDE. Usually the SDL port for µGFX is only used for development as it allows you to compile & run µGFX as a native application of your host machine. The same exists for Windows and other Unix systems.

So if you're using µGFX on your target because you need something that's extremely fast & lightweight you usally want to use the Linux Framebuffer driver. That driver allows µGFX to directly render into the framebuffer which the Linux kernel will display over some video interface. In that case you don't need any desktop environment, SDL or other package. µGFX compiles without any dependencies!

We don't have a guide specific for the beaglebone black wireless. However, these things always tend to be very similar. You can have a look at the RaspberryPi example as it will be very similar (that example uses the framebuffer driver as well): https://wiki.ugfx.io/index.php/Raspberry_Pi

I hope that helps. Please don't hesitate to ask if you have any further questions.

[Austin]

Joel,

I have been following the raspberry pi guide and have a make file that compiles. the issue now is when I build it, the error " GDISP Fremebuffer: Failed to set video mode" 

Any ideas how to fix this on the Beaglebone Black Wireless?

Thanks!

 

[Joel Bodenmann]

Please have a look at the board file. If you're using the default one it will most likely be /boards/base/Linux-Framebuffer/board_framebuffer.h. As you'll see that message is printed when board_init() couldn't set the video mode. This can have various reasons such as every Linux distribution using slightly different framebuffer compilation flags and so on.

To get things sorted out, you can simply start by commenting out this line at the top of the board file:

#define USE_SET_MODE						// Optional - comment this out to not to try to set the color mode we want

 

[Austin]

Ok I did what you suggested and now it says "GDISP Framebuffer: The display is 16 not 32 bits per pixel"

[Joel Bodenmann]

That's why the board file tried to change the video mode of the Linux framebuffer (which is what you just disabled).

The proper solution is to figure out why it doesn't work on your platform and modifying the board file accordingly (that file is ALWAYS project/application/platform specific anyway). Otherwise, you'll have to change the pixel format that your GDISP driver is using to match the default one of your Linux framebuffer. But then you'll never be able to change it to anything else.

[Austin]

Hey Joel,

I got the hello world to work by changing the RGB888 to RGB565. Now I am trying to do the adding the touch screen part to the example. The screen I am using is a 4d systems 4.3" screen with capacitive touch. I followed the example changing the two lines in the make file but I still receive undefined references in too many places to list. Any suggestions on how to get this example with the touch working on the Beaglebone?

Edited July 25, 2018 by Austin

[Austin]

For Further Info this is some of what shows up on my screen after I do `.build/hello_world`

[Joel Bodenmann]

It seems that you didn't enable all the features in the configuration file that you're using in your application.

Please read through the introduction page(s) in the wiki to learn how things are supposed to work.

[inmarket]

Don't forget to also do a make clean once you have your configuration correct (gfxconf.h)

For Linux based boards there are 3 alternatives:

1. SDL

2. X

3. Linux kernel framebuffer and the Linux kernel event system.

Options 1 & 2 are best for desktop, 3 is definitely best for embedded situations because of its low footprint and good performance. I have always personaly disliked SDL due to its linking nastyness, even though it is faster than the X driver. Still the framebuffer driver is the best solution for a real Linux based embedded device.

As an input driver I believe the uGFX Linux event driver works on the beagle bone black so as long as your capacitive touch screen sends events to the standard Linux event driver everything should just work.

I did some testing when the first beagle bone black board was released. At the time the framebuffer driver in the Linux kernel didn't work at all (kernel/hardware problem) so I ended up using the X uGFX driver for my testing. I am glad to see the Linux kernel framebuffer driver now works (even though at reduced bit depth) on the more modern hardware versions.