Framebuffer-Library für Mikrocontroller

[Artjomka (Gast)]

Es gibt ja viele Anwendungen, bei denen ein Display direkt angesteuert 
wird (ohne OS und Treiber dazwischen). Es geht mir im speziellen um 
farbige Grafik-Displays und der Framebuffer liegt natürlich im RAM.

Ich denke mal die meisten Coden sich Ihre Zeichenroutinen dann jedes mal 
selbst und speziell auf Ihr Display zugeschnitten.
Wie realisiert ihr das bei (Farb)-Grafik-Displays mit den Fonts? Bastelt 
ihr euch da selber was?
Jeder bastelt sich einen eigenen Konverter oder zieht sich die Fonts aus 
Beispielen raus und passt den Code auf genau seine Anforderungen an?


Gibt es dafür nicht schon eine Library, die ich nur noch auf meine 
Auflösung und die Farbtiefe/Pixel-Kodierung anpassen muss?

Die primitivsten Zeichenfunktionen sollten enthalten sein, folgende 
Funktionen wären auch noch schön:
- Alpha-Blending (zumindest 1bpp)
- Text-Funktionen (am besten auch mit Alpha-Blending)


Kann mir auch vorstellen, dass es sowas nicht gibt, da bei 
Farb-Grafik-Displays sowieso meist ein Mikrocontroller mit Linux 
eingesetzt wird oder der Mikrocontroller so wenig Resourcen hat, dass er 
gar nicht in der Lage ist das Display über einen Framebuffer zu 
bedienen.

Allerdings bieten die kleineren ARM MCUs genug Resourcen um ein 
Grafik-Display mit schönen Grafiken zu füllen, aber nicht genügend für 
ein Linux-System. In meinem Fall bräuchte ich das für einen STM32F4 und 
ein 96x64 16bpp Display.

[Olaf (Gast)]

> Es geht mir im speziellen um farbige Grafik-Displays und der Framebuffer
> liegt natürlich im RAM.

So natuerlich ist das garnicht. Gerade bei kleineren Microcontrollern 
hat man ja relativ wenig Ram und man koennte auch auf die Idee kommen 
alles direkt im LCD abzulegen. Aber natuerlich ist es moeglich einen 
eigenen Buffer zu haben, manchmal auch notwendig und oft auch schneller. 
Haengt halt von der Anwendung ab.

> Wie realisiert ihr das bei (Farb)-Grafik-Displays mit den Fonts?
> Bastelt ihr euch da selber was?

Klar, man kann sich selber was basteln oder auch fertig kaufen.

> Gibt es dafür nicht schon eine Library, die ich nur noch auf meine
> Auflösung und die Farbtiefe/Pixel-Kodierung anpassen muss?

Es gibt z.b QT Embedded
http://doc.qt.digia.com/qt/qt-embedded-linux.html

Relativ fett, aber dafuer maximalen Luxus.

> Kann mir auch vorstellen, dass es sowas nicht gibt, da bei
> Farb-Grafik-Displays sowieso meist ein Mikrocontroller mit Linux

Das ist Unsinn. Ist gibt auch jede Menge Anwendungen von GrafikLCDs wo 
es kein Betriebssystem gibt.

> Allerdings bieten die kleineren ARM MCUs genug Resourcen um ein
> Grafik-Display mit schönen Grafiken zu füllen, aber nicht genügend für
> ein Linux-System. In meinem Fall bräuchte ich das für einen STM32F4 und
> ein 96x64 16bpp Display.

Naja, so ein MiniDisplay kannst du auch problemlos an einen kleinen 
Controller haengen wenn der etwa 20kByte Ram hat. Was du an Resourcen 
brauchst haengt von deiner Anwendung ab. Es ist ein Unterschied ob du 
ein Video abspielen willst oder ob lediglich ein paar Messwerte 
dargestellt werden. Es ist auch ein Unterschied ob man mit 2-3 festen 
Bildschirmen arbeitet die jedesmal neu aufgebaut werden, oder aber echte 
Fenster braucht wo jedesmal der Hintergrund gesichert wird.

Problematisch wird das ganze dann bei den hoeheren Funktionen. Also dem 
Look&Feel fuer den Anwender. Es ist ein grosser Unterschied ob die 
Hardware eine Maus(1,2,3 Tasten?), ein TouchDisplay, Tasten neben dem 
LCD, oder aber nur einen Encoder mit Knopf bietet.

Olaf