Moin, ich bin total verwirrt. Ich habe ein Embedded Linux System mit einem VGA TFT und würde gerne Messwerte visualisieren. Ich habe auch erfolgreich mit Buildroot ein Linuxsystem gebaut, das soweit funktioniert. Wie komme ich jetzt am besten zu einer schnellen und schönen Grafikausgabe? Das System basiert auf dem XScale PXA320, der eingebaute 2D-Beschleunigung hat. Es gibt einen Kerneltreiber und das passende Gegenstück in directfb. Ich verstehe nur leider nicht, wie man directfb sinnvoll nutzen kann, weil es noch nicht einmal das Zeichnen von Kreisbögen unterstützt. Dann gibt es cairo. Cairo kann zwar direkt in den Framebuffer schreiben, ist dann aber natürlich nicht beschleunigt. Cairo macht zwar schöne Grafik, ist aber total langsam, weil alle Operationen mit Fließkommazahlen arbeiten, der ARM aber keine FPU hat und das alles in Software abhandelt. Dann gibt es noch X. Angeblich beschleunigt, aber darauf brauche ich dann wieder irgend eine andere Bibliothek, die mir die Zeichenfunktionalität bereitstellt. Ein GUI brauche ich nicht, deshalb würde ich auch ungerne eine Monster-Lib wie GTK, QT oder ähnliches installieren. Das Gerät hat keinen Touchscreen, nur wenige Taster und dient wirklich hauptsächlich der Darstellung von Messwerten. Alles nicht so einfach, als Anfänger kann man schnell den Überblick verlieren. Was würdet ihr mir empfehlen?
Mirkor schrieb: > Alles nicht so einfach, als Anfänger kann man schnell den Überblick > verlieren. Was würdet ihr mir empfehlen? Wenn nicht nur ein ein paar Linien im Framebuffer zu zeichnen sind, sondern eine komplette GUI (Buttons, Widget o.a) notwendig sind würde ich QT-Embedded nehmen. Mit QWS läuft dieses ohne X11-Server und kann direkt in den Framebuffer zeichnen. Da es Plattform-Unabhängig ist kann auf den normalen PC entwickelt und getestet werden und damit müssen die Programmfehler nicht vollständig auf dem Embedded-System gesucht werden. Zum Testen ist auch der vorhandene virtuelle Framebuffer praktisch um den Bildinhalt per VNC über das Netzwerk zu schicken... Außerdem ist eine gute Dokumentation verfügbar und etliche Beispiele erleichtern den Einstieg. Für das Erstellen der GUI existiert hilfreiche Programme wie QT-Creator. http://qt.nokia.com/products/platform/qt-for-embedded-linux/
Also ich verwende auf meinen ARM Computern (TabletPC und PanelPC) in meinen grafischen Appikationen den GTK-PIXBUFF. Somit kannste eine GTK Applikation vollständig in voller grafischer Auflösung auf der Console ohne dem X-Window-System verwenden Grüße Michelle
Ja Leute, wie gesagt, ich brauche KEINE GUI. Also im Prinzip muss ich wirklich nur ein paar Linien und Kreisbögen (und Text!) zeichnen, und das ganze soll möglichst schnell gehen. DirectFB kann keine Kreisbögen. Cairo zeichnet direkt in den Framebuffer und läuft sehr langsam. X ist monströs, genau wie GTK oder QT, wobei ich das alles als Ballast mitschleppen würde, ohne es je zu brauchen. Irgendwie scheint es da nichts passendes zu geben. Wie gesagt, meine Hardware hat einen 2D-Beschleuniger, der dann wohl leider leider brachliegen würde.
Nimm DirectFB und schreib Dir Deine eigene Kreisbogen Funktion die dann DrawLine von DirectFB nutzt. (Oder lock den Surface und schreib direkt rein) HW-Beschleunigung für Kreisbögen hast Du sowieso nicht und der Rest ist dann wenigstens beschleunigt (hängt natürlich vom directFB Treiber ab) Oder vergiss die hw beschleunigung und nimm gtk-pixbuff / qt-embedded oder ähnliches. Die paar Linien die beschleunigt werden werden jetzt auch nicht den großen Unterschied machen. Bei den Texten glaube ich nicht an eine Beschleunigung durch directFB (kann mich aber irren); es sei denn Du nutzt Bitmap Fonts und kannst über Blit die HW-Beschleunigung ausnutzen. Die 2D Einheit in Deinem Controller ist auch eher für "normale" 2D Graphik gedacht. Sprich schnell Bitmaps zeichnen und dabei diese noch zu verändern. Und einfache Linien. Kreise sind doch eher Luxus-Features..
Schau dir SDL an, das is rasend schnell gegenüber anderen Geschichten und kann direkt aufm Framebuffer arbeiten. Damit mache ich meine embedded-Sachen. Nötige Libs dazu im Quellcode <5MB.
Danke für die Hinweise. Ich habe wirklich viel Zeit damit verbracht, verschiedene Dinge zu probieren und bin jetzt an ein ziemlich großes Problem gestoßen: Der Framebuffer vom PXA320 arbeitet nur mit gepackten RGB-Formaten, wobei mein TFT pro Farbkomponente 6 Bit haben möchte. Ein Pixel im Framebuffer sieht dann so aus: 31 . . . . . . . 23 . . . . . . . 15 . . . . . . . 7 . . . . . . 0 ----------ungenutzt-----------R5R4R3R2R1R0G5G4G3G2G1G0B5B4B3B2B1B0 fbset meldet entsprechend: mode "640x480-60" # D: 25.200 MHz, H: 31.500 kHz, V: 59.999 Hz geometry 640 480 640 480 32 timings 39683 142 16 33 10 2 2 accel true rgba 6/12,6/6,6/0,0/0 endmode Wenn ich mit Cairo dem Framebuffer mittels mmap beschreibe, passen natürlich die Farben nicht, weil Cairo von 8 Bit pro Farbe ausgeht und die einzelnen Komponenten natürlich an den Byte-Grenzen ausrichtet. Andere, auch die hier vorgeschlagenen Libs unterstützen dieses für TFTs typische Format ebenfalls nicht. Ich habe das "Datenblatt" (Developer's Manual Vol III) vom PXA320 genau studiert, er kann bei TFTs tatsächlich keine ungepackten Formate. Damit ist er mal so ziemlich inkompatibel mit allem, was ein typisches embedded Linux so bietet. Wie zum Henker soll ich das zum Laufen bringen? Es gibt jede Menge kommerzielle Produkte auf der Basis des PXA320, die auch mit Linux laufen. Irgendwie kann man das Problem also lösen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.