open source GUI library based on C/C++ for Embedded MCU

[dizgah]

Hi every one,
Is there any open source libraries for GUI application on the TFT LCD like EMWIN or UCGUI?
It must been as much as possible independent from hardware and small size-footprint?
-----
if not,whats your suggestion how this would be done?
I'm thinking to a semi-description language(some thing like HTML) which there are a descriptor text file ,which is consist of Objects places & actions & also text object-& pictorial objects.
is there any better solution?
WBR.

[Jeroen3]

I know uGFX. Not sure if that is still open source, doesn't look like it is.

[dizgah]

actually i find a free hobby use version in their website but there are not any thing about sources.
is there any one here with an experiences with this tools?is it;s sources close of use compiled .bin libraries?is this support Unicode fonts?

[RogerRowland]

... is there any better solution?

Maybe Nextion? https://nextion.itead.cc/

[dizgah]

is this open source & hardware independent?

[Jeroen3]

Developing a GUI library is a lot of work. And due to the scope of such project it is highly unlikely to be fully open source. There needs to be some kind of full time folks managing the stuff such as with Linux or ChibiOS, and those people need to eat.

emWin is supplied, as pre-compiled library, with some ST and NXP parts. (not sure about freescale)

I did found http://www.embeddedlightning.com/ugui/, which looks like solo project.

[krho]

Nuttx does have NxWidgets and Window management. Everything is released under permissive BSD license.

[Mechatrommer]

is this...hardware independent?

how do you think a library/language/os are made hardware independent? and how many hardware variants do you think in embedded world out there? you can google "lcd arduino gui library" and download some, arduino specific, just if you want to sacrifice the hardware independentness.

[madires]

Is there any open source libraries for GUI application on the TFT LCD like EMWIN or UCGUI?
It must been as much as possible independent from hardware and small size-footprint?

That's an oxymoron There are tons of small libs for different display controllers and MCUs. But as more hardware independed you make a lib, as larger it becomes. If size matters, select a few LCD controllers to support, optimize the drivers and only add features which you really need. Otherwise go for a nice 32bit ARM with plenty of ressources.

[stj]

maybe this:
http://www.rinkydinkelectronics.com/

[rstofer]

One method for making a GUI library reasonably hardware independent is to draw into a virtual space of some arbitrary size.  At the lowest driver level, the virtual window is clipped to the physical display space.  It has been this way since the early Tektronix vector graphics terminals (circa '75) and probably a lot earlier than that.

It is then up to the programmer to keep the display elements in an area of the virtual space that actually maps to the physical display.  I suspect, but haven't looked, that uGUI does it that way because it advertises hardware independence.

The problem with writing a GUI library is you start with the idea of drawing a pixel of some color at a location.  Then you progress to drawing a line by using the pixel drawing routine.  Then you move up a level and draw shapes.  Then you figure out how to flood/fill the shapes.  And so on up until you put a title on a window.  Layers and layers of code.

And then there are the frame buffers where regions behind the area currently being displayed are stored so they can be rewritten.  How deep should the stack go?  We want to keep those spaces rectangular...  How much memory is available?  This doesn't apply to every GUI because, sometimes, the actual display is static.  Perhaps there is a menu bar that calls up a specific display into some region and then it calls up a different display.  There is no need to save constant displays.

The uGUI code is about 7700 lines of C and is probably worth checking out.  It's free software according to the license statement on the file.

[nctnico]

IMHO one of the basic requirements of keeping a GUI hardware and platform independant is to be able to scale a GUI for different screen sizes either at runtime or compile time.

[Kilrah]

Also hardware independent = likely to perform poorly on devices that could do much better. E.g parts that have hardware acceleration for various graphics operations, which is the case for more and more devices nowadays.
If you want to be able to make your lib as hardware independent as possible BUT still make use of hardware capabilities when available it starts getting hairy since you have to plan ahead and look at lots of different existing devices to see what their capabilities are so that your lib implements primitives that can be sent down to the hardware if present.

[dizgah]

Final hardware is based on the ARM cortex M4/M7 and it must be able to drive a 5" or 7" TFT LCD,hardware independent here means library must run on each standard LCD & cortex m4/m7 MCU and not specific to the special one (like Nextion).
Imagine this situation:
There are technicians without programming skills,
Assume this like a simple mini-HMI which usually work on a specific hardware,but if it is required to changes in hardware platform(MCU,LCD,driver chips & ...) library must be as portable as possible to bind to the new hardware in a reasonable time.
this is my approach:
There are a desktop app with  virtual screen.User(technician without programming skill) put objects in  screen,each object has its own property(place,size,action,...),user define properties of each object and save project as state chart diagram(or any other equivalent Sysml-UML diagram),after design finished he/she renders diagrams:desktop app compile designs to a semi-html text,final output consist of descriptor file and resource folder,which deploy to the external memory connected and controlled by MCU.RTOS in running mode handle reading descriptor  and controlling LCD.
this is a blueprint of project with 3~6 month time & 2~3 developer resources.Then is there any better solution/ suggestion?
WBR.

[Kilrah]

Assume this like a simple mini-HMI which usually work on a specific hardware,but if it is required to changes in hardware platform(MCU,LCD,driver chips & ...) library must be as portable as possible to bind to the new hardware in a reasonable time.

But why have the display be part of the hardware?

The Nextion style devices are made precisely for that use case, even if your actual machine controller hardware needs to change no problem, it simply connects to the completely independent UI unit through an interface e.g. serial to send things to display and take commands.

[Kalvin]

One can also take a Raspberry Zero or similar small, Linux-based gadget, add a LCD and develop the GUI using Qt or similar framework. The Raspberry Zero and the GUI application will then communicate with the actual microcontroller doing the heavy lifting.

Edit: Ok, the hardware is already decided. Happy coding

[engineer_in_shorts]

Final hardware is based on the ARM cortex M4/M7 and it must be able to drive a 5" or 7" TFT LCD,hardware independent here means library must run on each standard LCD & cortex m4/m7 MCU and not specific to the special one (like Nextion).
Imagine this situation:
There are technicians without programming skills,
Assume this like a simple mini-HMI which usually work on a specific hardware,but if it is required to changes in hardware platform(MCU,LCD,driver chips & ...) library must be as portable as possible to bind to the new hardware in a reasonable time.
this is my approach:
There are a desktop app with  virtual screen.User(technician without programming skill) put objects in  screen,each object has its own property(place,size,action,...),user define properties of each object and save project as state chart diagram(or any other equivalent Sysml-UML diagram),after design finished he/she renders diagrams:desktop app compile designs to a semi-html text,final output consist of descriptor file and resource folder,which deploy to the external memory connected and controlled by MCU.RTOS in running mode handle reading descriptor  and controlling LCD.
this is a blueprint of project with 3~6 month time & 2~3 developer resources.Then is there any better solution/ suggestion?
WBR.

It depends if your project is outputting a final product and what is the expected quantity and specced BoM limits.
But given the resources and fixed hardware I would look at RamTex or emWin.
There is some of emWin available as a binary library for free from NXP or ST, but that will locked you in on micro choice.

[dizgah]

With using Nextion style devices ,Final product will be depended on a specific manufacturer and this is not desired,Also platform ,hardware,software must be fully documented or open for next levels customization.
Also using ras pi or other other pre-built hardware  does not provide industrial requirement of product.
STEMWIN or EMWIN for LPC is not accepted because it needed programming skills for developing GUI and mentioned technicians don't have this skills.is must be as simple as a Electrical-instrument technician can customize it for his/her usage.
----
Is there any fault or better approach for my scenario ?
thanks for every answers.

[Mechatrommer]

STEMWIN or EMWIN for LPC is not accepted because it needed programming skills for developing GUI and mentioned technicians don't have this skills.

geez...

[Kilrah]

STEMWIN or EMWIN for LPC is not accepted because it needed programming skills for developing GUI and mentioned technicians don't have this skills.is must be as simple as a Electrical-instrument technician can customize it for his/her usage.

That isn't correct, you can use STEMWIN to do the actual drawing on the screen THEN in the scope of your project develop an interface that takes whatever XML-like file and builds the actual UI from it using the library's primitives.

Given there doesn't seem to be anything that does exactly what you want (which makes sense, since it's a niche requirement) it sounds like what you'll have to do regardless of the actual display library you choose, the abstraction being a specific capability of your product.

Seems you want to design an industrial controller like can already be found e.g. Siemens panels...

[engineer_in_shorts]

With using Nextion style devices ,Final product will be depended on a specific manufacturer and this is not desired,Also platform ,hardware,software must be fully documented or open for next levels customization.
Also using ras pi or other other pre-built hardware  does not provide industrial requirement of product.
STEMWIN or EMWIN for LPC is not accepted because it needed programming skills for developing GUI and mentioned technicians don't have this skills.is must be as simple as a Electrical-instrument technician can customize it for his/her usage.
----
Is there any fault or better approach for my scenario ?
thanks for every answers.

Yes, your faults are the requirements rule out pretty much every avenue and you have not told us what is you cost (BoM) constraints or quantity.   

The only other thoughts is :
1. Look at a PLC or industrial controller.
2. Get the relevant signals into the PC and use a higher level approach such as Labview Virtual Instruments.

Pro tip: Just as a suggestion, a electronic project these days is a combination of software and hardware, therefore do not fix the hardware specification until you have evaluated all pros and cons of software part  .

[MosherIV]

Hi

I have been watching this thread with interest to see if there are any open source display frameworks. It appears not. That backs up what my colleague found 3 years back.

Yes, your faults are the requirements rule out pretty much every avenue

I agree.

Final hardware is based on the ARM cortex M4/M7 and it must be able to drive a 5" or 7" TFT LCD

Most systems that use any Cortex M core is usually a 'closed' embedded system that is very hardware target specific.
By closed, I mean most companies develop products where they do not want end users (competitors actually, they are not so bothered about the end user) reverse engineering their code. Most systems based on any of the Cortex M cores are generally single chip (or very few chips) systems to keep the costs down and hence tend to be commercial/closed source.

And as such, most GUI development kits in this area are commercial and non open source.
I have worked with one commercial GUI on the Cortex M4 which has standard API and support for a number of graphics drivers, it is not cheap! Like someone was suggesting earlier, it is based around frame buffers, the top level code draws into the frame buffers and the lower level device driver copies the frame buffer out to the display device. The problem with this arrangement is that the display resolution is still NOT abstracted from the top level, ie the API is still affected by the target display. What else would you expect in an embedded system.

[Jeroen3]

There is a reason many small embedded projects run a beast of an ARM core to run Linux with visualization libraries such as WxWidgets, .NET C# or Qt.
I'd suggest you go that way.

You can also buy an PLC, cheap ones from Wago, or expensive from Siemens. Yet that still requires programming. The link between FBD and GUI isn't drag&drop, it's close though.

[rstofer]

There is a reason many small embedded projects run a beast of an ARM core to run Linux with visualization libraries such as WxWidgets, .NET C# or Qt.
I'd suggest you go that way.

You can also buy an PLC, cheap ones from Wago, or expensive from Siemens. Yet that still requires programming. The link between FBD and GUI isn't drag&drop, it's close though.

There is another thread running that is similar to this one...

Over there I posted that I was coming around to the view that all HMIs should be based on the Raspberry PI.  From a UI point of view, the system windowing, touch screen, keyboard, mouse and even network capability are ideal.  There is a lot of computing power for validating user entry and, ultimately, the output could be an SPI stream to the actual control computer.

Not only is the RPi capable of being the UI, it is also capable of 'creating' the UI.  There's plenty of horsepower for drag-and-drop panel layout.  I wouldn't prefer it but Linux can clearly run with a screen the size of a cell phone.

From the point of view of the control MCU, it receives commands over the SPI bus (could be serial).  This separates the projects into two distinct parts with only a common language protocol between them.  The MCU can be replaced with <whatever> as long as it understood the language and could implement the required actions.  The RPi could be replaced with the next great thing and not impact the underlying system at all.

Cost might be the downside.  OTOH, given the low cost of development and the ease of porting, it could be that the real cost is much less.  It depends on volume.  How many systems?  10, 100, 10000?  Somewhere in the calculation there should be an item for software development and, more important, software maintenance.  How do porting costs compare a few years into the project?

[MosherIV]

rstofer

What you are describing sounds a lot like XWindowing or X11 protocol.

https://en.wikipedia.org/wiki/X_Window_System