[En-Nut-Discussion] New displays, chained devices, best way or how to

[Ulrich Prinz]

Hallo Ernst!

Ich bin aktuell daran, ein 160x128 RGB Display am EIR in betrieb zu 
nehmen. Hänge aber noch an der Basis, weil NCS7 nicht funktioniert. das 
Display ist am normalen Bus angeschlossen.
Parallel habe ich am AT91SAM7X-EK ein 132x64 OLED am SPI Bus laufen und 
versuche gerade ein 128x64 LCD in betrieb zu nehmen. Wenn diese 
technischen Teile abgeschlossen sind, komme ich sowohl mit Software, 
als auch ein paar möglichen Konzepten.

Bei den Konzepten würde ich sehr gerne darauf achten, dass sie trotz 
aller Abstraktion und Vereinheitlichung auch auf kleinen Systemen 
lauffähig bleiben. Erfahrungsgemäß setzte das wirklich gruselig zu 
lesenden Code voraus.

Letztendlich braucht es für eine basisimplementation aber nur wenige 
Dinge:
1. Displays müssen per fprintf(display, "...", ...) Symbole ausgeben 
können.
2. Symbole müssen invertierbar oder colorierbar sein
3. Symbole müssen frei positionierbar sein

1. funktioniert bereits mit dem kleinen OLED (132x64 DD-32645-2A)
Texte sind eine Verkettung Charactern, Characters sind Symbole oder 
Icons. Mir gefällt der Begriff Symbol besser, da er weniger 
Missverständnisse bei den Windows-Usern hervorruft.
Die Abstraktion von Symbolen ist m.E. wichtiger als alles andere, weil 
Zeichensätze erzeugt werden müssen. Diese Zeichensätze können/dürfen 
aber aus Speicherplatzgründen nur aus den wirklich verwendeten Symbolen 
bestehen und man kann natürli
ch nicht verwendete Zeichen durch eigene 
Bitmuster ersetzen.

Ein Symbolsatz besteht aus einem Satz-Header, der angibt, welches das 
1. und das letzte Zeichen im ASCII Raum ist, dass dieser Satz 
unterstützt. Damit kann ich in der Ausgabe prüfen, ob gültige Symbole 
angefordert werden.

Jedes Symbol hat einen Header, der seine Breite in Pixeln, seine Höhe 
in Pixeln und seine Höhe in Bytes angibt. Diese Daten müssen noch auf 
Vollständigkeit geprüft werden, denn Displays sind unterschiedlich. 
Manche schreiben Bytes horizontal, andere vertikal, die RGB Displays 
brauchen bis zu 3 bytes pro Pixel. Auf diese Art kann man jedoch einen 
Font mit variabler Breite zusammen mit Symbolen aus verschiedenen Höhen 
leicht bauen und nutzen.

Dann fehlt noch
4. Grafik-Funktionen oder Widgets, die dem Display noch den letzten 
Schliff geben.

Was bei der Vereinheitlichung einer Grafik-API sicherlich am meisten 
Kopfzerbrechen bereitet, sind die unterschiedlichen Fähigkeiten des 
Displays. Viele Displays kann man auslesen, wenn man sie am Parallelbus 
betreibt, d.h. auch für and/or/xor Malereien braucht man keinen 
Shadow-Memory. Aber selbst High-End Displays unterstützen dies nicht 
mehr, wenn man sie an den SPI-Bus anschließt. Hier wird nur das 
Schreiben, aber nicht mehr das Auslesen von Daten bereit gestellt. 
Mono-Displays erfordern einiges an Bit-Geschiebe, was bei einem AVR 
ziemlich mühsam ist, weil er kein shl/sh
r mit n-bits unterstützt, 
sondern nur jeweils 1 bit schieben kann. Außerdem haben AVRs nur wenig 
Speicher, selbst das 132x64er OLED benötigt schon 1056 bytes Shadow, 
wenn man Linien per OR über einen Text legen möchte. Auch ist hier eine 
Positionierung von Text pixelgenau in der Höhe mit viel Rechenaufwand 
verbunden. Solange man bei vollen Bytes in der Höhe bleibt, geht es 
jedoch schnell und Platzsparend.

Soviel erst einmal zu meinen Gedanken.

Gruß, Ulrich

Ps: Leider erlaubt es der WEB-Editor von Netscape/AOL nicht mehr, 
sauberes Inlining vorangegangener Mails zu machen, ich kann nix dafür 
und per SMTP komm ich nicht durch den Proxy. Sorry!

-----------------------------------------
Ulrich Prinz, Schmittbachweg 9, 35781 Weilburg


-----Original Message-----
From: Ernst Stippl <ernst at stippl.org>
To: 'Ethernut User Chat (English)' <en-nut-discussion at egnite.de>
Sent: Sun, 29 Mar 2009 6:48 pm
Subject: Re: [En-Nut-Discussion] New displays, chained devices, best 
way or how to










Hallo Ulrich!

Wie geht mit den graphical display routines?
Hast du für dich eine "Architektur" ausgedacht, die du implementiert 
hast?
Ich frage deshalb, weil dies (wenn bzgl. Linzenz möglich) zusätzliche 
Info
auf der Wiki Seite werden könnte...

Beste Grüße

Ernst Stippl
Wien

-----Ursprüngliche Nachricht-----
Von: en-nut-discussion-bounces at egnite.de
[mailto:en
-nut-discussion-bounces at egnite.de] Im Auftrag von Ulrich Prinz
Gesendet: Mittwoch, 04. März 2009 23:08
An: en-nut-discussion at egnite.de
Betreff: [En-Nut-Discussion] New displays, chained devices,best way or 
how
to

Hi!

I'm almost new to nutos, almost as I used it mostly as it is before. 
But
now I'd need to extend it in many ways and I am missing lots of 
how-to's
or best ways.

New display types:
I am implementing a graphical display. I am trying to keep as close to
the LCD structures as I can, but those code ist mostly character
oriented. A graphical display, especially one without own fonts, is
pixel oriented. The LCD code is attached to the term.c what would be
great for the graphical display to. But there are some new commands
needed to use all the features a graphical display features.
So, did already someone solve that and has some code where I can jump
into? Or are there comments how to do that the best way?

Chaining Devices:
The displays I am trying to attach are SPI displays. So I need to
register a new device for the SPI bus. Then I need to register a new
stream device attached to the spi device from before. Is there an
optimal way to do this? Actually I do the NutRegisterSPIDevice and then
I do a NutRegisterDevice. But I think the registration of the display
device itself should keep care for registering itself on the SPI bus in
its init routines.

At all I really miss some guides of h
ow to do some thing inside nutos
the best way. Is there any further documentation available?

Sorry for beeing some more general, but I'd like to avoid posting long
lines of code if there is already a solution at hands.

Ah, I develop these nutos drivers under linux but will backport them to
the windows release for shure and share them to the community. But  I
have massive problems getting the GUI going of the nutos configurator
under linux. Any comments for that too?

Best regards and thanks in advance!

Ulrich
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.7/1983 - Release Date: 
03/04/09
07:41:00

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion