Zurück

Entwicklung FlorianF PRE GUI für Windows/STM32

"Windows Anwendung (in C++) zur Entwicklung des STM32 Display GUI und Testumgebung"

Windows WX Anwendung und Entwicklung des Dispay OS Simulators
Rendering aller Controls mit OpenGL und CPU Fallback

Projektschwerpunkte in der Übersicht

Git Versionskontrolle über alle Projektschwerpunkte

Nach vielen Tests und Erfahrungen in der ersten Version von der FlorianF PRE Software, habe ich mich dazu entschieden von der C# .NET Anwendung auf eine C++ Anwendung zu wechseln. In C# habe ich nach einiger Zeit die grenzen des grafischen Renderns mit GDI+ erreicht. Das Füllen von Pfaden und live Rendering von eigenen Controls war mir zu unperformant und zu langsam. Dazu kam, dass ich mich neben der Programmiersprache C auch in C++ einarbeiten wollte und die Anwendung auch auf Linux lauffähig sein sollte. Nach einigen einarbeitungsstunden in die WINAPI auf reinem C++ habe ich mich dazu entschieden wxWidgets zu verwenden. wxWidgets ist ein Open Source C++ Framework zur Entwicklung von plattformübergreifenden GUI Anwendungen. Es bietet eine einfache API und ist für Windows, Linux und MacOS verfügbar.

Vergleich der Versionen

FlorianF PRE Debugging Tool
(entwickelt in C# .Net)

FlorianF PRE Debugging Tool v2
(entwickelt in C++, Boost, OpenGL und wxWidgets für Windows, Linux und MacOS Support)

Nach einigen Hello World Versuchen mit wxWidgets, habe ich angefangen meine erste Anwendung und Controls mit OpenGL zu rendern um die erweiterte Grafikbeschleunigung der Grafikkarte zu nutzen. Nachdem ich die Panels und Graphen aus meiner C# Anwendung in C++ nachgebaut hatte, habe ich mit der Boos Bibliothek angefangen die Kommunikation mit dem STM32 Controller über UART zu implementieren. Die Kommunikation erfolgt über ein eigenes Protokoll, welches ich in der C# Anwendung und auf dem Mikrocontroller meines Verstärkers bereits entwickelt und eingeführt hatte.

Obere Tabelle zeigt die verschiedenen Versionen der GUI Anwendung und die Entwicklungsschritte. Beim verschieben und neu rendern des Graphen im Filter Fenster war beim C# Projekt schnell das Ende der Performance erreicht. Ohne Grafikbeschleunigung wird das Grid und das transparente Füllen des Polygons nur von der CPU übernommen. Der CPU Thread bzw Kern ist somit die ganze Zeit auf 100% Last. Beim C++ Open GL Projekt ist die CPU Last bei 0-1% und die Grafikkarte übernimmt das Rendern der Controls und des Graphen. Ein Live Rendern von Controls und Graphen ist somit möglich und die Anwendung ist auch auf älteren Rechnern performant. Sie Simulation von Filtern ist also somit auch grafisch möglich.

Entwicklung eines eigenen WindowManagers auf basis der eigenen Framebuffer

Nach einiger Überlegung die Übertragungsgeschwindigkeit des STM32 FMC Displays besser auszunutzen und die höchste Performance der GUI Elemente zu erreichen, habe ich mich dazu entschieden ein eigenes Window basiertes System zu entwickel, was mir ermöglicht sämtliche Controls auf dem Display per Doublebuffer und Redraw Flag zu rendern und nur die geänderten Pixel zu übertragen.

Das Window System in C basiert auf meinen framebuffer Funktionen. Um in der Programmiersprache C mit dynamischen Elementen arbeiten zu könne, habe ich eine C Bibliothek dynVect implementiert, die sich wie ein std::Vector in C++ verhält.

Github Link zur dynVect Bibliothek (in Arbeit)

Mit Hilfe meines dynamischen Vektors der mit ElementSize arbeitet, kann ich beliebige Elemente in einem Array speichern und dynamisch verwalten. Dieses Verhalten ermöglicht es mit dynamische Listen zu erstellen, in der ich zB meine Controls bzw Pointer zu den Fenstern speichern kann, welche neu gezeignet bzw gerendert werden sollen.





Auf der ersten Menü Seite meines Window Managers sind 13 Fenster angeordnet. Die Fenster für Überschrift, Button Bar und Pagination werden nur beim Seitenwechsel einmal neu gezeichnet und an das Display übertragen. Alle anderen Fenster werden nur neu gezeichnet, wenn sich der Inhalt bzw der Status ändert. Vor Übertragung zum Display wird der neue Inhalt in den jeweils Hintergrundbuffer des Fensters gerendert. Ist alles erledigt wird neu ans Display gesendet. Somit ist das gesamte Verhalten des GUI Flackerfrei und performanter als wenn alles direkt ans Display gesendet wird.





Ein weiter positiver Effekt bei der Ferwendung der Fenster ist die Möglichkeit die Fenster zu verschieben ohne den Content neu rendern zu müssen. Somit könne zB scollbare Listen verwendet werden. Das verschieben der sichtbaren Fenster kann dur einfaches Memory Move im LCD Display geschehen. Das neu Zeichnen der freien Flächen muss dann nur noch passieren.

Zurück