Hallo liebes Forum, habe mich die letzten Tage sehr intensiv mit BeRTOS beschäftigt, eigentlich eine nette Sache. Um gleich in das kalte Wasser zu springen, habe ich mir für das gerade rumliegende KS0108 GLCD einen Treiber gebastelt, mit dem ich meine ersten Versuche unternehmen wollte. Das klappt auch soweit ganz gut. Ich kann die Raster-Daten auf das Display schreiben, siehe Bilder. Nur bei den Schriften klappt es leider nicht. Ich habe daraufhin versucht das Problem zu verstehen und vermute, daß es etwas mit dem Programmspeicher zu tun hat, wo die Daten für die Schriften hinterlegt sind. Im Bild sieht man den "Datenbrei" bei der Textanzeige. Die Linien und Quadrate werden korrekt gerendert, der Text nicht. Kann mir jemand helfen das Problem irgendwie einzugrenzen? Hier noch ein paar Infos: Die CPU ist ein ATmega128 @ 16 Mhz. Die KS0108 Routinen habe ich von diversen Quellen übernommen und angepasst, das sollte eigentlich nicht die Ursache sein. Quellen können gerne gepostet werden. Wenn ich den gleichen Code als QT-App kompiliere (gut, einige Anpassungen, zwei unterschiedliche main.c und *.mk Dateien angelegt, aber gleiche cfg und hw Daten, sowie gleicher BeRTOS Ordner) da klappt es, siehe Bild. Ich schaffe es irgendwie auch nicht die fixed-size Font zu aktivieren... Leider scheint das Projekt seit mehr als einem Jahr still zu stehen. Jedoch gibt es einen Hinweis in der developer mailingliste: https://lists.develer.com/pipermail/bertos/2012-October/003897.html doch leider hilft mir das nicht weiter... Vielen Dank für Eure Hilfe, Hari Nachtrag: Getestet wurde mit avr-gcc 4.7.2 auf Ubuntu 13.04 (3.8.0-33) UND auf XP mit WinAVR gcc 4.3.3 per Cygwin. Beide kompilierten ohne Fehlermeldungen. Das Resultat ist mit beiden das gleiche: Pixelsalat. Habe mich anhand des APRS-Beispiels orientiert und alles doppelt und dreifach gecheckt. Auch GFX_CLIPPING und CONFIG_TEXT_RENDER_OPTIMIZE bringen keinen Unterschied...
:
Bearbeitet durch User
Habe mein Problem inzwischen selbst eingrenzen können: Irgendwie funktionieren die Macros der Entwickler nicht ordentlich mit meiner Entwicklungsumgebung und sie haben vergessen (?) an einigen Stellen die Definitionen zu ändern, um Daten aus dem Programmspeicher zu holen, daher wird Pixelmüll dargestellt. Es ist mir nun gelungen, Schriften und Grafiken korrekt darzustellen. Doch nochmal von Anfang an: Das Rastern der Glyphen erfolgt durch die Funktion gfx_blitRaster in der Datei bertos/gfx/bitmap.c:197. Die Makros in der letzten Zeile sind definiert in der Datei bertos/gfx/gfx_p.h, dort steht in Zeile 136:
1 | #define RAST_READPIXEL(raster, x, y, stride) \
|
2 | ( *RAST_ADDR(raster, x, y, stride) & RAST_MASK(raster, x, y) ? 1 : 0 )
|
das habe ich geändert in
1 | #define RAST_READPIXEL(raster, x, y, stride) \
|
2 | ( pgm_read_byte(RAST_ADDR(raster, x, y, stride)) & RAST_MASK(pgm_read_byte(raster), x, y) ? 1 : 0 )
|
Interessant (und lästig zugleich) ist die Tatsache, daß die mitgelieferten Makros PGM_READ_CHAR bei mir NICHT IMMER funktionierten, zumindest war beim Debuggen ein Unterschied feststellbar, das untersuche ich aber später. Für die proportionalen Schriften sind noch 2 weitere Arrays im Programmspeicher abgelegt:
1 | static const PROGMEM uint16_t luBS14_offset[] und static const PROGMEM uint16_t luBS14_width[]. |
In der Datei bertos/gfx/text.c:112 findet die Fallunterscheidung statt, ob eine proportionale oder fest-breiten Schrift dargestellt wird. Dort habe ich dann folgendes geändert:
1 | /* Proportional font */
|
2 | glyph_width = pgm_read_byte(&bm->font->widths[index]); /* TODO: optimize away */ |
3 | glyph = bm->font->glyph + pgm_read_word(&bm->font->offset[index]); |
Damit die Zentrierung des Textes auf dem Display korrekt berechnet wird, muss noch in der Datei text_format.c in Zeile 248 das hier stehen:
1 | glyph_width = pgm_read_byte(&bm->font->widths[index]); |
Et voilá, jetzt läuft's. Verzeiht, wenn ich vorzeitig hier um Hilfe gebeten habe ohne vorher nicht alles selbst versucht zu haben, es alleine hinzubekommen. Doch dazu sind doch Foren da... Remember: Peter schrieb: > Der Lerneffekt beim selbständigen Lösen einer Aufgabe ist viel grösser > als beim nachvollziehen eine vorgekackten Musterlösung...
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.