Moin! Da die verschiedenen Embedded Linux Boards immer billiger und immer schneller werden, überlege ich ein Messgerät auf Basis eines solchen Boards zu bauen. Natürlich macht es weder Sinn die Bootzeit unnötig durch ein X-Windows zu verlängern, wie es Sinn macht einen HDMI Monitor zu verwenden, um ein paar Daten darzustellen. Da ist es schön, dass der gute Greg im Staging Bereich des Linux kernel das fbtft so lange duldet, bis ein entsprechendes drm System geschrieben wurde. Oder für Nicht-Kernel-Entwickler: Kleine LCDs oder OLEDs sind rein technisch kein Problem. So habe ich jetzt ein framebuffer device auf dem ich mit wenigen Zeilen Code ein paar Linien malen kann. Ich habe aber aktuell noch keine Ahnung, wie ich Schrift auf dieses Display gezaubert bekomme... Natürlich kann ich die Console auf das Display umleiten, aber das ist weit weg von einer komfortablen Darstellung... Es gibt einige Projekte, die nebenbei auch Schriften aufs LCD packen können, aber die meisten Projekte befassen sich mit Spielen oder 2D/3D Beschleunigung und man muss eine Unmenge "Zeugs" drum herum installieren, damit man das auf dem PC laufen lassen kann, und beim Portieren auf das ARM Board geht dann die Hälfte verloren... Auf der anderen Seite gibt es ein paar Projekte, bei denen vorhandene Schriften in ellenlange C-Dateien exportiert werden und diese werden dann mit in die Software compiliert und "Von Hand" dargestellt. Gibt es einen guten Weg, irgendwo dazwischen? Was nutzt Ihr um eine kleine Oberfläche mit ein paar wenigen Menüs zu bauen und auf einem Graustufen oder Color LCD darzustellen? Und noch etwas wichtiges. Ich würde das ganze gerne weiterhin in C machen, also ANSI C. Die kernel Module und die framebuffer Test-Software und die eigentliche Mess-Software, alles war in C kein Problem. Bin gespannt, auf welch einfache Idee ich gerade nicht gekommen bin ;) Gruß Ulrich
Mit QT kannst du ohne Window-Server direkt per Parameter -qws auf den Framebuffer schreiben.
Ulrich P. schrieb: > Gibt es einen guten Weg, irgendwo dazwischen? Was nutzt Ihr um eine > kleine Oberfläche mit ein paar wenigen Menüs zu bauen und auf einem > Graustufen oder Color LCD darzustellen? ncurses https://de.wikipedia.org/wiki/Ncurses
@Bitwurschtler: Console / ncurses sind meiner bescheidenen Ansicht nach identisch. Auf einem 256x64 OLED bekommt man damit nix vernünftig dargestellt. Auch kann man nicht gleichzeitig unterschiedlich große Schriftarten darstellen. @Chris: QT habe ich mir auch schon mal grob angesehen... Allerdings fehlt mir da der richtige Einstieg. Ich habe mal versucht anhand eines RPi Projektes da was zu probieren, aber es artete in eine Patch- und Paket-Installations-Orgie aus... Hast Du Da einen guten Einstig zum Nachlesen / Nachvollziehen, auch gerne in Englisch?
QT habe ich noch nicht komplett selbst gebaut, wir setzen hier das ptxdist buildsystem von pengutronix ein. Da ist qt 4.8 bzw. 5 als fertiges Package enthalten und wird dann gebaut. Es selbst du bauen kommt halt immer auf die buildumgebung an. Zunächst habe ich anhand dem: https://wiki.qt.io/Basic_Qt_Programming_Tutorial angefangen, danach habe ich den Code als package ins ptxdist eingebaut, damit er für ARM gebaut wird und das ganze dann auf dem target getestet. Gruß
Ulrich P. schrieb: > @Bitwurschtler: Console / ncurses sind meiner bescheidenen Ansicht nach > identisch. Auf einem 256x64 OLED bekommt man damit nix vernünftig > dargestellt. Auch kann man nicht gleichzeitig unterschiedlich große > Schriftarten darstellen. Dann was anderes; Nano-X sollte unterschiedliche Fonts drauf haben, allerdings scheint deren Webseite neuerdings nur noch über den Google-Cache erreichbar: http://cc.bingj.com/cache.aspx?q=Nano-X+windows+screenshots&d=4567961386093211&mkt=de-DE&setlang=de-DE&w=ucT9QcV5_JEdRPUF7oz9Jh_TtaS5j3TL https://en.wikipedia.org/wiki/Microwindows
Ulrich P. schrieb: > bei denen vorhandene > Schriften in ellenlange C-Dateien exportiert werden und diese werden > dann mit in die Software compiliert und "Von Hand" dargestellt. Du wirst kaum einen Font verwenden können, ohne die Daten dafür zu speichern, und ob du die als Array definierst oder aus einer Truetypedatei nimmst ist weitgehend egal. Auch die Pixel eines ganz einfachen 5 x 7-Fonts musst du irgendwo her haben, und je schöner der Font desto grösser die Datenmenge. Was anderes wäre ein Terminal wie VT100, das hat seine Fonts selber in der Firmware, dafür kannst du ausser einfachen Textseiten auch nichts darstellen. Man bekommt halt ziemlich selten was umsonst. Georg
Qt wäre auch für mich die erste Wahl. Gestartet ist es mal als Toolkit für X11-Anwendungen, kann aber seit langer Zeit auch direkt auf Framebuffer Devices laufen. Allerdings ist es C++, erfüllt also nicht alle Anforderungen des TE zur Gänze. Aber irgendwas ist ja immer.
Chris schrieb: > QT habe ich noch nicht komplett selbst gebaut, wir setzen hier das > ptxdist buildsystem von pengutronix ein. Da ist qt 4.8 bzw. 5 als > fertiges Package enthalten und wird dann gebaut. Auf der linux-emebeded Seite gibt es dazu eine Reihe von Beiträgen.
Ganz ohne Linux, sozusagen die große Hose für ganz kleine Mikrocontroller: FT800 (FTDI).
Moin zusammen und schon mal Danke für die vielen Vorschläge! @Bitwurschtler: Ich kenne mich in Linux selbst sehr gut aus, wenn Linux zu groß ist für die Aufgabe, setze ich NutO/S ein. Wenn das zu groß ist, spitze ich den bare-metal gcc an und im Notfall geht ARM auch locker in Assembler. Aber Danke für die Idee. Schaue ich mir auf jeden Fall rein aus Interesse an einer Vielfalt an. Aber eigentlich lebe ich ganz gut ohne Windows. (Nein, ich habe nix gegen Microsoft, sie machen hervorragende Hardware wie Tastaturen und Mäuse) Außerdem ist in Linux eine Menge Vorarbeit bereits getan und auch die Mess- und Steuerung via Netz ist schon fertig. Es geht nur um eine Oberfläche. @Georg: Die Datenmenge ist überhaupt kein Problem. Das Modul, das ich verwende hat einen iMX6DL und neben 1GB RAM auch 4GB eMMC. Die Problematik ist auch nicht, dass das Programm zu groß werden könnte. Es ist so, dass man unter Linux ja viele Fonts zur Verfügung hat, die später unter X verwendet werden können. Ich hatte gedacht, es gäbe eine kleine Software oder Library, mit der ich dann vorhandene Fonts einfach darstellen kann. Ich hatte gehofft auf den Umweg verzichten zu können, die Fonts erst einmal in Code zu konvertieren und dann "zu Fuß" passend darzustellen. @Axel Schwenke: Ja, ich denke ich werde mich da in QT umschauen. C++ kann man nutzen, muss es aber nicht. Die Idee ist, die eigentliche Messaufgabe weiter in sehr effektivem C zu fertig zu machen und dann über localhost eine API zur Verfügung zu stellen. Dann kann man sich in QT in C++ austoben, um eine schöne Oberfläche zu programmieren. So muss man da nicht mischen. Allerdings kann man reinen ANSI C99 Code auch sehr schön an C++ anhängen. @Joe F: Netter Chip, werde ich mir in die Bookmarks packen. Leider bekommt man sehr viel Cortex-M3 für wenige Cent mehr Aufpreis, im vergleich zu den 5€ FT800. Aber dafür muss man es nicht selber machen. Bei einer Kleinserie sicherlich gut zu wissen.
Bitte 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.