Hier meine WinAVR Sourcen zur Ansteuerung des Nokia 6100 GLCD's und
Kompatiblen.

Enthalten ist ein Fonteditor zur einfachen Erzeugung von Mehrfarben
Fonts oder dem Import von Windows Zeichensätzen.
Die Library kann also mehrfarbige Fonts ausgeben. Dieses Feature kann
dazu benutzt werden eigene Icons/Bitmaps darzustellen. Desweiteren sind
effiziente Zeichenroutinen für Rechtecke, Ellipse, Linien usw.
enthalten. Die Ausgabe der Grafikroutinen kann um 0°,90°,180° oder 270°
gedreht werden, es ist also egal wie ihr das LCD auf euren Boards
aufbaut. Die Library unterstützt durch Konfiguration auch mehrere
Slaves am SPI. Die Fonts können auf einfache Weise auf externen Medien
verwaltet weren, zb. I2C EEPROMS usw.

Mehr könnt ihr in der Readme lesen.

Gruß Hagen

Version 1.1.
- komprimierte Fonts sind nun möglich, die Kompressionsrate beträgt
zwischen 30% bis zu 50% und bei ganz großen Fonts sogar weit über 200%.
Mit meinen Mehrfarben-Fonts konnte ich mehr als die Hälte an Speicher
einsparen.
- Fontroutinen wurden becleant und sind jetzt effizienter
- Fontroutinen unterstützen nun auch Fonts mit 8,16,32,64,128 und 256
Farben, eg. 1,2,3,4,5,6,7,8 Bits per Pixel.
Dazu muß aber in glcd.h der Wert COLOR_TABLE_BITS angepasst werden.
- komprimierte Fonts werden schneller und effizienter angezeigt als
nicht komprimierte Fonts
- Der Font Editor wurde komplett überarbeitet:
Bei großen Fonts hatte der alte Editor starke Probleme mit der
Performance, beseitigt.
- Der Editor kann nun Fonts mit bis zu 16 Farben erzeugen. Es sind
theoretisch aber mehr möglich.
- Der Editor unterstützt nun auch das Füllen von Pixelbereichen.
- Der Editor unterstützt und erzeugt automatisch komprimierte Fonts,
wenn diese weniger Resourcen verbrauchen.
- Der Editor hat nun eine Zeichen-Vorschau.
- In glcd.h wurde zusätzliche #define's eingefügt mit denen es möglich
ist bestimmte Grafikfunktionen zu deaktivieren, das sind
  USE_LINES -> glcdLine()
  USE_ELLIPSES -> glcdEllipse()
  USE_FONTS -> alle Font Funktionen
  Dadurch kann man den Resourcenverbrauch tunen.
- USE_ISR, damit kann eingestellt werden ob das Chip Select Signal des
PCF8833 automatisch nach Beendigung der SPI Transmission
  zurückgesetzt werden soll. Normalerweise muß man dieses define
aktivieren falls mehrere Slaves am SPI hängen. Es zeigte sich aber
  das ohne USE_ISR, also mit dauerhaftem CS Signal für den PCF8833, die
Störanfälligkeit bei langen Zuleitungen zum LCD erhöht wird.
  In meinen Test's betraff dies immer das Ein/Ausschalten der
Schreibtischlampe. Wurde USE_ISR nicht definiert so kommt es beim
  Display Test Program sehr schnell zu Abstürzen des LCD Controllers.
Leider gibt es keine Möglichkeit den Status der Übertragung
  zum LCD querzuchecken. Deshalb empfehle ich USR_ISR zu definieren,
auch wenn dadurch die Performance ganz leicht runter geht.
  Auf alle Fälle hat USR_ISR die Anfälligkeit des LCD's enorm
reduziert, in fact selbst 1000'maliges Ein/Ausschalten meiner
Schreibtisch-
  lampe hat keine Absütze mehr provoziert. Fairerweise muß ich aber
sagen das 1.) die Zuleitungen zum LCD ca. 50cm lang sind, das 2.) die
  Lampe direkt ca. 25cm über dem STK500 Board angebracht ist, 3.) die
Lampe eine normale Glühbirne ist und 4.) der Schalter einer von
  diesen Leitungs-Schnappschaltern ist. Gleich neben dieser Zuleitung
liegt meine Logitech-Funkmaus.
  Irgendwelche Entstörmaßnahmen wie zusätzliche Kondensatoren oder
Pullup-Widerstände wurden nicht benutzt, und das STK500 und somit das
  LCD + ATmega32 16MHz wurden auf 2.7V Vcc eingestellt !! Bei diesen
Testbedinungen ist es eigentlich logisch das eventuelle Störungen
  auftreten müssen. Um so erfreulicher ist es das mit dem USE_ISR
keinerlei Abstürze vorkamen, besonders wenn man bedenkt das das
  LCD mit dem benutzten 8MHz SPI eigentlich overtuned wurde (PCF8833
kann laut Datenblatt nur 6.5MHz SPI).


Die Font Komprimierung:
  Für eine effiziente Komprimierung auf AVR's habe ich mich von
vorhinein für ein einfaches RLE = Run Length Encoding entschieden.
  Weil eben die Dekomprimierung sehr effizient ist. Ich konnte aber
keine normale RLE Komprimierungen wie sie in Windows-Bitmaps
  benutzt wird verwenden. Es zeigte sich das diese Verfahren zu
schlechte Kompressionsraten für Fonts liefern und zudem noch
unhandlich
  bei vielen verschiedenen Font-Farbtiefen sind. Desweiteren reagieren
fast alle RLE Verfahren nicht dynamisch auf die Erfordernisse
  die die zu komprimierenden Daten stellen. Ok, man hätte ja eine
Huffman Codierung benutzen können, aber auch diese wäre ziemlich
  ineffizient in unserem Fall, auf Grund der sehr großen Lookup
Tabellen.
  Nun, die Font Routinen benutzen ein RLE Verfahren mit dynamisch
angepasster Längentabelle. D.h. bei der Komprimierung werden 4 Längen-
  codes ausgewählt so daß die erzielte Komprimierung die bestmögliche
ist. Dabei werden die am "häufigsten" vorkommenden Pixellängen mit
  gleicher Farbe als 2 Bit Werte codiert. Sogesehen ist das von mir
benutzte RLE Verfahren auch eine Mini-Huffmann-Codierung.
  Insgesammt gibt es nur 4 solcher Längen in einer Tabelle mit 4
Einträgen. Logischerweise ist der erste Eintrag in dieser Tabelle
  immer die Länge 1, sprich 1 Pixel mit der aktuellen Farbe.
Erstaunlicherweise arbeitet das Verfahren ziemlich effizient,
  und ich konnte Komprimierungen erzielen die weit über 200% lagen.
Insgesammt benötigt diese dynamische-RLE-Komprimierung nur 4
  zusätzliche Bytes. Oben habe ich das "häufigsten" separiert um
auszudrücken das dies nur eine starke Vereinfachung des Verfahrens
  ist. Tatsächlich werden nicht unbedingt die häufigst vorkommenden
gleichfarbigen Pixellängen als Längentabelle benutzt sondern
  die jenigen die mit absoluter Sicherheit die tatsächlich beste
Komprimierung ergeben. Dazu wird mit einem speziellen "Such-
  Algorithmus" alle Kombinationen der auftretenden Häufigkeiten
durchgespielt, und die kompletten Fontdaten mit jeweils allen
  Kombinationen komprimiert. Diejenige Längenkombination mit der
höchsten Komprimierung wird dann gewählt. In einem normal großen
  Mehrfarbfont gibt es ca. 100 verschiedene Pixellängen. Davon muß nun
eine Kombination von 3 Längen gefunden werden die die höchste
  Komprimierung liefern. Jede der möglichen Kombinationen kann die
beste Kombination sein, unabhänig von ihrer eigenständigen
  Häufigkeit. Eine andere Annahme als Suchstrategie ist grundsätzlich
falsch, auch ich hatte dies erst übersehen. Denn alle nicht
  in der RLE-Längentabelle erfassten Pixellängen müssen ja
zusammengesetzt werden aus diesen 4 Längenangaben, und die Reihenfolge
des
  Vorkommens der einzelnen Längenhäufigkeiten in den Fontdaten ist
ebenfalls ausschlaggebend. Dies ist auch der Grund warum die
RLELänge[0]
  immer 1 sein muß. Eine druchschnittlich gute Komprimierung erhält man
bei einer Längentabelle der Form (1,2,4,8). Allerdings auch hier
  kann es durchaus sein das zb. beim jeweiligen Font die Längentabelle
(1,2,5,13) doppelt bessere Komprimierungen ergibt !!
  Der Suchalgorithmus zur Komprimierung der Fontdaten muß also nicht
nur die Häufigkeiten der einzelnen gleichfarbigen Pixellängen
  berücksichtigen, sondern auch deren Auftreten in den Fontdaten und
das möglichst clevere Zerlegen aller nicht in der 4 Bytes
  Längentabelle codierten Pixellängen. Dies geht nur mit einem
testweisen Komprimieren der Fontdaten. So, dies erklärt auch warum
  bei sehr großen Fonts der Font Editor eine längere Zeit zur
Komprimeirung der Daten benötigt. Allerdings dürfte dies nicht so
  enorm stören da diese Komprimierung im Hintergrund in einem eigenen
Thread abläuft. Auf alle Fälle ist die benutzte RLE Codierung
  weit effizienter als die in Windows-Bitmaps oder in PNG Bitmaps
benutzte, das habe ich getestet.



Nachdem ich die MAP Files des durch den WinAVR Compiler erzeugten Codes
genauer analysiert habe musste ich feststellen das er an einigen
Stellen enorm ineffizient optimiert und der Linker noch ineffizienter
arbeitet, schade :(
Besonders erschüttert war ich über den Resourcenverbrauch der
integerierten rand() Funktion. Mehr als 800 Bytes an Code ist definitiv
viel
zu viel für einen stink normalen LCG (linear congruential generator).
Aus diesem Grunde habe ich mal meinen LFSRG aus meinen Delphi Sourcen
portiert. Nach der ersten, reinen C Umsetzung, musste ich
wieder feststellen das der WinAVR Compiler aus einem so einfachen und
echt Hardware-nahem LFSR unmöglichen Code erzeugt. Deshalb findet
ihr den LFSR als Assembler Source im Ordner \lfsr\. Wenn man den C
Overhead entfernt, der die Register sichert, kommt man auf einen
reinen
Assemblercode von 72 Bytes ! Der Source könnte also auch für ASM Freaks
sehr interessant sein.

Das von mir benutzte mathematische Verfahren ist
1.) schneller als der LCG von rand()
2.) wesentlich code effizienter als rand()
3.) hat bessere statistiche Eigenschanften, er ist also zufälliger als
ein LCG
4.) ist kryptographisch weit sicherer als der LCG von rand()

Das Verfahren ist ein LFSR-SG, also ein Linear Feedback Shift Register
Shrinking Generator mit einer Periode von 2^63 -2. Diese Periode
IST IMMER garantiert, egal wie die Seedregister belegt sind. Der LCG()
von rand() hat eine maximale Periode von 2^31-1 diese ist aber
abhängig vom Seed des Generators, kann also wesentlich kürzer sein. Für
die "Nicht-Mathematiker", wenn man die Seed Register mit einem
beliebigen Wert füllt dann muß man 2^63 -2 Bits erzeugen bis die
Seed-Register wieder den Anfangswert bekommen. Man kann also
9223372036854775806 Bits nacheinander erzeugen ohne statistische
Wiederholungen in der Zufallsfolge. Das sind 1023 Penta Bytes ==
1023 * 1024 Terra Bytes !!

Damit der LFSR-SG arbeitet benötigt er zwei nicht reduzierbare Polynome
(irreducible polynoms) im GF(2) -> Galois Field 2.
Um euch die Erzeugung bzw. Auswahl solcher Polynome leichter zu machen
habe ich in der Datei lfsr.inc jeweils 1000 solcher Polynome
hinterlegt. Diese Polynome sind auf ihre "Nicht-Reduzierbarkeit"
geprüft und wurden zufällig erzeugt. Wichtig ist nur das ihr
als Polynom_S und Polynome_A in der Datei lfsr.S aus der richtigen
zugehörigen Tabelle auswählt. Dabei wird das LFSR S mit dem Polsynom_S
betrieben, welches ein Degree von 32 besitzen muß. Das LFSR A wird mit
Polynom_A betrieben welches einen Degree von 31 haben muß.
Die kryptografische Sicherheit dieses LFSR-SG beträgt 126 Bits, solange
die benutzten Polynome NICHT für Aussenstehende bekannt sind !
D.h. die Funktion lfsr() kann als Source benutzt werden für eine
einfache XOR Verschlüsselung, man muß aber sicherstellen das die
beiden
Polynome A & S nicht öffentlich bekannt werden. In den Registern lfsr_S
und lfsr_A kann man den Verschlüsselungs-Schlüssel ablegen.
Dieser Schlüssel hat dann eine effektive Länge von 63 Bits + die 63
Bits der beiden Polynome ergeben 126 Bits. Sind dieser Schlüssel
und die Polynome für einen Angreifer nicht bekannt so muß er eine
Bruteforce Attacke auf 126 Bit Schlüsselraunm durchführen.

Als Randbemerkung: die BasicCard's, das sind SmartCard's einer
deutschen Firma, benutzten lange Zeit das gleiche Verfahren. D.h. der
Code
ist kompatibel mit den in diesen BasicCard's eingesetzem
Zufallsgenerator.

Gruß Hagen

minor changes:

- Atmega128 support hinzugefügt
- Test-DEMO geändert

Gruß Hagen

PS: danke für die viele Verbesserungsvorschläge eurerseits :)

Kannst du mal ein paar neue Bilder posten ?
Ich meine von irgendwelchen Displayspielereien :-D in Farbe ?

Au mann, viel Spaß beim Download. Es ist ein ganz schöner Aufwand gute
Bilder vom LCD zu schießen. Meine Casio QV-5700 hat einfach eine zu
gute Auflösung und im ersten Moment dachte ich das durch die
Interferenzen echt schlechte Bilder rauskommen. Mit Blitz kann man das
Display schon garnicht knipsen.

Hier im ersten ZIP seht ihr die Ausgabe eines 4 Farbenfonts innerhalb
eines Clipping-Bereiches, d.h. die Zeichen werden in der Zeichenroutine
auf das äußere Rechteck beschnitten. Dann seht ihr eine Textausgabe in
proportionalem Font innerhalb eines Frames mit Schatten. Dies
Textausgabe benutzt für den Zeilenumbruch und Ausrichtung am linken
Rand die automatischen Funktionen der Library. D.h. für diesen Text
ruft man nur glcdPrint_P(PSTR("text, bla bla hier")); auf, In den
letzten Bildern seht ihr übergroße Fonts, sozusagen Icons/Images in 4
Farben. Allerdings sind diese 4 Farben hauptsächlich so gewählt das ein
Anti-Aliasing stattfindet.
Das allerletzte Bild gibt die echten Größenverhältnisse wieder, relativ
zu einem 17" Monitor mit 1152x864 Bildschirmauflösung.

Gruß Hagen

So, und damit man mal sieht was meine DigiCam beim obigen letzten Bild
gesehen hat, hier noch mal ein Bild un-gestützt.

Allerdings musste ich es beschneiden und die Jpeg Kompressionsrate rauf
setzten damit ich es von 4 Mb auf 1 Mb runter bekomme.

Gruß Hagen

Achso, beim Bild mit der "Uhrzeit" ist das dunkle Blau das was das LCD
unter Schwarz versteht !! Sogesehen sieht man schon in der
Farbdarstellung gravierende Unterschiede zu den Farb-TFT-Display's der
heutigen Handheld's.

Gruß Hagen

Hallo Hagen,

schöne Bilder, kommt das blau statt schwarz eventuell von
der Hintergrund-Beleuchtung?

Eine Frage hab ich noch, wo bekommt man diese riesigen
Euro-Münzen?  :-)

Gruß,
Arno

Nein, meine ich nicht. Das LCD ist ein STN Display und eigentlich sind
das technologisch gesehen "Auslaufmodelle". Das Display hat immer
einen Blaustich bei dunklen Farben, egal ob mit oder ohne
Hintergrundbeleuchtung. Ich habe alles ausprobiert,
Kontrasteinstellungen, Farbtemperatur, Hintergundbeleuchtung hell,
super hell und dunkel bis aus eingestellt, das schwarz ist und bleibt
eben bläulich. Allerdings! fällt das nicht so sehr auf wenn die
Dunkelblauen Bereiche nur ein Pixel breit sind, heist also Rahmen oder
Linien neben anderen hellerern Farben.
Interessant ist aber der Fakt das Rot, Gelb, Grün farblich sehr satt
rüber kommen und eben keinen Blaustich haben.

Ich habe mal die Farbeigenschaften mit denen meines Palm's IIIc und
Tungsten T verglichen, bei diesen beiden Display's wird eben das
Schwarz auch Scharz dargestellt.

Wie gesagt ich vermute das es in der STN Technologie begründet liegt.

Und jo, das LCD ist klein, aber immerhin noch besser und größer als
mein Siemens S55 Display. Aber aich hier, das S55 stellt schwarz nicht
bläulich dar. Die Baugröße kann aber durchaus auch ein Vorteil sein,
denn eines hat das Display auf alle Fällen -> eine sauscharfe und
unverwaschene Anzeige.

Eventuell liegt es ja an meinem LCD ?? Maximilian was sagt's du dazu
?? Oder man benötigt noch einen speziellen Filter vor dem LCD aus
Plastik ??

Gruß Hagen

Die Größe ist schon ok und wenn man nicht weiß das blau eigentlich
schwarz sein sollte, merkt man das kaum.
Ich spiele mit dem Gedanken dieses Display in meinem geplanten
Eigenbau KW-QRP-Transceiver zu verwenden als Multifunktionsanzeige.
Aber bis das Ding fertig ist dauert es noch etwas.

Gruß,
Arno

Eine Erklärung gäbe es noch: Nachdem ich mal meinen Tungsten
aufgeschraubt habe konnte man sehen das die "weißen" LED's der
Hintergrundbeleuchtung beim 6100 LCD doch ziemlich blaues Licht
erzeugen. Die Hintergrundbeleuchtung beim Tungsten hat wesentlich
weißeres Licht. Wer weis.

Gruß Hagen

so auch ma wieder da
mhmm also ich weiß jetzt nich in wieweit das auf den fotos vielleicht
noch verfälscht ist, aber ich denke mein Display ist nicht ganz so
blau.
aber wie gesagt kann sein das das täuscht.

meine leds hab ich noch nicht genauer betrachtet, aber wenn deren licht
zu blau wäre, sollte doch eigentlich das weiß blau sein und nicht das
schwarz.

Die Bilder treffen sehr gut das Blau, ähm Schwarz meines Displays.
Die LED's betreibe ich auch nur mit 6.2 Volt, über'ne Zenerdiode.
Alleine wenn nur die Hintergrundbeleuchtung an ist und das LCD ansich
aus, leuchtet es dunkelblau.

Nungut, da die anderen Farben sehr gut rüberkommen, und ich meistens
einen weißen Hintergrund benutze, kann ich damit leben.

Der Unterschied in den weißen LED's fällt aber nur im direktem
Vergleich auf. Ich dachte auch erstmal das die LED's gutes weißes
Licht liefern. Erst beim direktem Vergleich mit der Tungsten
Beleuchtung viel mir der Unterschied auf. Aber dann echt drastisch. Die
weißen LED's des Nokia's sind wirklich bläulich. Die Tungsten LED's
leuchten irgendwie mir einem wärmerem Weiß.

Gruß Hagen

Version 2.0 ist fertig.

Die Lib ist jetzt eine echte Link-Bibliothek und somit hat der
gcc-Linker die Chance nicht benutzte Funktionen weg zu optimieren.
Die Lib wurde komplett neu gecodet in handmade Assembler. Dies hat zur
Konsequenz das die Funktionen weitaus efizienter als ihre C Pendants
sind und zusätzlich noch der Codeverbrauch von 4500 Bytes auf maximal
2800 bytes reduziert wurde. Im besten Falle kommt die Lib zur
Ansteuerung des LCD's mit 600 Bytes aus. D.h. es war mir möglich ca.
50% code einzusparen im vergleich zum WinAVR gcc Compiler und zusäzlich
die Performance zu steigern und sogar die Features zu verbesseren.
Schade das gcc so mittelmäßig ist.

Mehr im ZIP File, Readme.txt und Install.txt.

Gruß Hagen

Version 2.1.

- kleinere unwesentliche BugFixes in glcdEllipse()
- Performance von glcdLine(), glcdEllipse() wesentlich verbessert
- mehr Dokus
- Test DEMO leicht geupdated
- einige Optimierungen in den Font Routinen die Codegröße reduzieren
und Performance erhöhen.

Gruß Hagen

... na wer schlägt sich denn da wieder die Nacht um die Ohren ?!

Ist ne coole Sache mit dem Display... Ich hoffe meins kommt auch bald
an!

Soein Display in Groß (4") würde mich mal reizen !!

Wie wärs wenn du uns mal ne nette Grafik-routine für verbreiterere
controller als den KS108 z.B. HD61830 oder T6963 zaubern würdest?
Da lässt sich doch dann sicher auch viel portieren ?
grin

gute n8

Kofi

Ich arbeite meistens Nachts :)
Nich so schnell, ich programmiere erst seit 4 Wochen auf AVR und MCU's
im allgemeinen.

Ich würde noch warten, bis die heutigen Handys in einem Jahr
Auslaufmodelle sind. Und schon gibts dann 128x160 und 160x240
Display's wie Sand am Meer, also schon QVGA. Die weitere Entwicklung
dürfte klar sein. Bisher sind mir die Dinger mit rund 40? noch zu
teuer.

Die KS108, HD61830 oder T6963 habe ich in meinem Leben noch nie gesehen
geschweige denn verbaut. Würde ich so'n Ding besitzen gäbs
wahrscheinlich auch eine Grafik Library dazu. Allerdings sind das nicht
meistens nur monochrome Display ??


Gruß Hagen

Ja sind es... aber ungeschlagen günstig im vergleich zu Handy Displays.

http://www.lcd-module.de/giff/grafik/p128-6n7.jpg (30€)

Damit es bei den Handydisplays Sinn macht müsste schon das Display
eines P800 / P900 herhalten ... (dann gleich mit Touchpanel-Auswerrtung
g)

http://homepage.hispeed.ch/p800_info/p800/pics/Angepasst.JPG

Gruß
Kofi

30 Euro sind doch teuer!!!
Ich habe für mein Nokia 6100 Farbdisplay 23 Euro bezahlt.
Natürlich gibt es noch viele andere gute Handydisplays, aber das
Hauptproblem ist es, an die Datenblätter zu gelangen.
Somit hat das Nokia 6100 Display zur Zeit das beste
Preis-Leistungs-Verhältnis.
(P.S. die echten Profis warten noch, bis es die Farb-OLEDs
günstig zu kaufen gibt)

An Hagen: Wie lange hast du eigentlich gebraucht, um die Routinen
zu programmieren? Auch der Fonteditor hat es mir sehr angetan.
Mach weiter so!!!

MartinK

Ist immer schwierig, man sitzt ja nicht zu hause neben einer Stechuhr.
Also am FontEditor habe ich ca. 3 Tage gesessen, wobei der jetzige Font
Editor schon sichtbar unterschiedlich zur 1. Version ist. Dabei ging
ca. 1 Tag = 9 Stunden für die neue Font Komprimierung drauf (muß ja
auch erstmal erdacht werden :) Allerdings, in Delphi code ich
professionell schon seit dem es auf dem Markt ist. Es wäre schon'ne
Schande länger als 3 AT dranzusitzen.

An den GLCD Sourcen, ca. 2 Wochen insgesammt, ich habe ja nebenbei noch
Geld zu verdienen.
Da die Portierung vom C nach Assembler erst kürzlich war habe ich da
bessere Zahlen. Insgesammt hat es mich 4 Tage intensiv (ca. 12h pro
tag) gekostet, über Ostern die meiste Zeit, um die C Source nach ASM zu
portieren. Nachdem die größsten Hürden genommen waren ging's ruckzuck,
Atmels in Assembler zu codieren ist eine der einfachsten
ASM-Geschichten der Welt im Vergleich zu vielen anderen Assemblern
(Motorola usw.).
Viel viel mehr Zeit, ca. 10 Stunden, habe ich dagegen verbraten um
durch die WinAVR gcc assembler Syntax durchzusteigen, die optimalsten
Mittel der codierung zu finden -> Macros funktionieren zb. auf Grund
der Registerdefinition im gcc-as nicht korrekt. Erst nachdem man die
Registernamen neu den Registerindizes zuweist funktionieren auch
Macros. WinAVR hat da scheinbar Mist gebaut und den direkten Zugriff
auf Ports und Register über Defines verhindert. Nungut, ich meine wenn
man Assembler codiert dann sollte man ALLE Freiheiten haben, ein
Assemblercodierer ist IMMER Schlud wenn irgendwas nicht funktioniert.
Nachdem das alles geklärt war, und der Source schon fertig im Kopf ist,
muß man ihn nur noch einhämmern und die kleineren Tipp-Bug's finden.
Dann noch 1 Tag "Source-Schönmach-Doku-Tag".


Gruß Hagen

Da das mein erstes gößeres Projekt für Atmels ist, ich also vorher noch
nie mit Atmels oder irgendwelchen anderen MCU's gebastelt habe, bin
ich eigentlich mit dieser Einarbeitungszeit von 2 Monaten ganz
zufrieden. Die Software ist auch nicht das Problem für mich, es ist die
Hardware :(

Wie lange hat es bei euch denn gedauert ?? Vielleicht bin ich ja viel
zu optmistisch :)

Gruß Hagen

> Damit es bei den Handydisplays Sinn macht müsste schon das Display
> eines P800 / P900 herhalten ... (dann gleich mit Touchpanel-
> Auswerrtung g)

Dies ist richtig, allerdings rechne mal nach 240x320 Pixel in 16Bit =
154KB Display-RAM zu beackern. Eine 32x32 Bitmap würde 2Kb Speicher
fressen und denoch nur 1/75'tel des Displays ausmachen.
Ich halte die 176x220 Displays vom Nokia 6600 oder Siemens SX1 für
ausreichend. Ein 9x14 Font waagerecht ergäbe ein 24x12 Zeichendisplay
das super gut abzulesen ist. Der Preis dieser Displays MUSS aber erst
auf unter 32? fallen. Derzeit liegen sei bei 80?.
Vorher schätze ich aber mal das die Nokia 6100 Display's für 15-10? im
Ausverkauf zu haben sind.

Gruß Hagen

Eine wichtige Bemerkung zur Library:
Die Lib nutzt ja Hardware SPI als Master. Wenn in der glcd.inc die Pin
Konfiguration verändert wird, so das das ~SS Pin NICHT benutzt wird, so
ist es trotzdem wichtig diesen ~SS Pin als Output zu definieren, oder
immer auf High zu setzen falls es ein Input ist.
Genaueres könnt ihr in den Datenblättern nachlesen.

Gruß Hagen

Hallo,

hat schon jemand versucht, den C Code umzuschreiben für das 3510i?
Wäre sehr von Interesse.

mfG

Matthias

Hallo Matthias,

läuft bei mir schon einige Zeit mit einem 3510i. Hatte ich in dem
Nachbar-Thread http://www.mikrocontroller.net/forum/read-4-71176.html
auch schon geschrieben. Hatte auch eine erste Version an Hagen
geschickt. Eigentlich wollte Hagen dies in die Lib einarbeiten, hatte
aber noch keine Zeit dazu.

Meine Version ist wohl noch nicht so aufgeräumt wie sie sein sollte,
aber ich kann sie Dir gerne zukommen lassen.

Volkmar

hallo,

gibt es eine ähnliche library auch für den msp430 oder müsste man sich
das selbst umschreiben.

mir würde auch ein einfaches beispiel zur ansteuerung reichen. den rest
der grafiklib kann man dann selbst entwickeln

Hallo
hat jemand Datenblätter für  Nokia 6600 oder P800 Display?
Gruß,
oleg

Weis jemand wie das mit dem Color Set/RGBSET funktioniert, also wie ich
z.b. eine Farbtabelle mit den 256 Farbwerten eines 8bit Bitmaps in den
pcf8833 übertrage ? Die Angaben im Datenblatt sind leider sehr wenig
und mit diesem "8bit auf 12bit mapping" kann ich überhaupt nichts
anfangen :/
Ich hab gelesen das es in der Grafiklib eine funktion dafür gibt, nur
mit Assembler kenne ich mich nicht wirklich aus :)

MfG
Thomas W. aka Deramon

Im Grunde dürfte das egal für dich sein, denndie interne Collormap musst
du so oder so initialisieren im 8Bit Modus. Zudem eine 8bit Bitmap die
du auf deinem Rechner schon farbig siehst muß nicht zwangsläufig
genauso auf dem Display erscheinen, denn dessen Farbqualitäten sind
doch recht eingeschränkt.

Um nun in der GLCD die Colormap zu verändern benutzt du die Funktion

glcdDisplaySetColors(const uint8_t *red, const uint8_t *green, const
uint8_t *blue, uint8_t flashstored);

red, green, blue zeigen dann auf Speicherarrays wobei red und grenn
arrays mit 8 Bytes sind und Blue verkürzt nur 4 Bytes enthält. Dies
liegt hauptsächlich daran das das LCD von vornhereineinen Blaustich
hat.

Intern baut der Displaykontroller daraus eine Tabelle mit 256 Einträgen
auf. Jeder Eintrag hat dann 12 Bit Breite, und entspricht somit einer
12Bit Farbe ala 4 Bits pro Farbe.

Wird nun ein Pixel im 8Bit Modus gesetzt so stellt dieser Farbwert im
Grunde nur ein Index in diese Tabelle dar. Der Controller empfängt
diesen 8Bit wert, transliert ihn über diese Tabelle in einen 12Bit
Farbwert und speichert diesen dann im Displayram.

Die Arrays[] red/green/blue stellen also im Grunde pro Farbe deren
Graustufenverlauf dar.

Um zB. eine Windows-Bitmap in ihrer Farbe möglichst exakt auf's
Display zu übertragen müsstest du erstmal eine 12Bit Farbtabelle
anlegen die die realen Farbverhältnisse auf dem Display darstellt.
Sprich das Display stellt nacheinander alle seine möglichen Farben dar.
Diese werden abphotographiert und in eine reale Farbtabelle konvertiert.
Nun hat man also eine Farbtabelle die die Realen Verhältnisse der
Farbdarstellung des Display repräsentiert. Dabei wird man festestellen
das BLAU viel viel stärker vertreten ist als Rot oder Grün. Nun, mit
hilfe dieser Tabelle muß man nun auf dem PC die Bitmap in ihrere Farbe
so konvertieren das die möglichst stark an die Ausgangsbitmap
herankommt. Die dazu benutzten Farbwerte der 12Bit Tabelle muß nun
komprimiert werden auf eine 8Bit = 256 Farbwerte. Nach diesem Schritt
kann man nun aus der konvertierten Bitmap heraus die nötigen Werte für
die arrays red/green/blue berechnen und mit obiger Funktion an das
Display senden. Nur über diesen Weg bekommt man die höchstmögliche undf
realste Farbwiedergabe der Bitmap zu stande.

Ich vermute das du eine Bitmap a 128x128 Pixel Displayfüllend
darstellen möchtest, und nun nach einem Weg suchst diese Bitmap
möglichst farbtreu darzustellen. Nungut den korekten Weg dahin weist du
ja nun.

Gruß Hagen





Gruß Hagen

Vielleicht nochmal zur Verdeutlichung:
über glcdDisplaySetColors() überträgt man eine Farbtabelle mit 8 Werten
Rotanteil, 8 Werten Grünanteil und 4 Werten Baluanteil, macht im
gesammten 8  8  4 = 256 Farbwerte in der realen Tabelle. D.h. aus
diesen Informationen baut der Controller intern einfach über
Kombination der einzelnen Werte pro Tabelle die 256 Werte umfassende
Tabelle zusammen. Diese Tabelle enthält also nach ihrer Fertigstellung
256 Werte a 12Bit.

Der Vorteil dabei liegt daran das man nur sehr wenige Daten an das
Display senden muß, der Nachteil ist aber der Fakt das man nicht frei
und beliebig ALLE 256 Werte der internen Tabelle setzen kann, sondern
eben nur die Kombination von 8*8*4 Werten. Dh. zB. pro rotem
Farbeintrag kann es nur 4 echte Blaukombinationen in der 256 Tabelle
geben und diese Balukombinationen sind direkt verknüpft pro grünem
Eintrag. Wenn also in den 4 blauen Werten im Array Zb. kein 0x0F
vorkommt so kann es auch kein Rot und Grün geben das absolut weis
erscheint.

Somit erreichst du die beste Farbbrillianz nur wenn du die Pixel im
12Bit Farbmodus setzt und die Bitmap selber in ihrer Farbdarstellung an
das Display vorher angepasst wurde.
Zum Glück ist es mit der Library theoretisch möglich während der
Laufzeit den Farbmodus temporär von 8Bit auf 12Bit und sogar 16Bit zu
erhöhen.

Gruß Hagen

Empfängt der Controller einen 8Bit Pixel so berechnet er daraus die
Indizes in die 8+8+4 Arrays die du über glcdDisplaySetColors()
übertragen hast. Das ist ganz einfach

BlauIndex = Pixel % 4;
RotIndex = (Pixel / 4) % 8;
GrünIndex = ((Pixel / 4) / 8);

12BitRGB = BlauArray[BlauIndex] | RotArray[RotIndex] << 4 |
GrünArray[GrünIndex] << 8;

Gruß hagen

Danke für die ausführliche Erklärung :)
Im moment benutze ich ein c script zur Ansteuerung des Lcds und
compactflash. Die ASM lib hab ich nur kurz mal ausprobiert, hat aber
nicht hingehauen(verwende nicht SS als CS, war aber bisher zu faul ein
neues adapterkabel zu löten)

@Hagen,

ich habe die Tage einen Bug in der glcd festgestellt. Dieser tritt beim
ATmega128 auf wenn die Library in die oberen 64K rutscht. Insbesondere
hängt es (zumindest) and dem Makro ENTER:

// macro to enter a stack with gcc

.macro ENTER unused_regs stack_locals

ENTER:
        clr     XH
        ldi     XL, \stack_locals
        ldi     ZH, hi8(ENTRY)      // there is no way to rescale an
address by 0.5
        ldi     ZL, lo8(ENTRY)      // thus we have to right shift the
address with additional code
        lsr     ZH
        ror     ZL
        xjmp    (_prologue_saves_ + 2 * \unused_regs)
ENTRY:
.endm

Wenn die Adresse ENTRY im oberen 64K-Block liegt, dann wird der Inhalt
von Z falsch berechnet. Leider habe ich auf die Schnelle nicht
herausgefunden, wie man an das 3. Byte der Adresse kommt um das LSB
noch in ZH reinzuschieben. Vielleicht hast Du es ja zur Hand?

Volkmar

versuche mal das

// macro to enter a stack with gcc

.macro ENTER unused_regs stack_locals

ENTER:
        clr     XH
        ldi     XL, \stack_locals
        ldi     ZH, pm_hi8(ENTRY)
        ldi     ZL, pm_lo8(ENTRY)
        xjmp    (_prologue_saves_ + 2 * \unused_regs)
ENTRY:
.endm


es gibt nämlich eine Möglicheit die ich damals noch nicht kannte ->
pm_hi8() statt hi8().

Ob das real hilft kann ich dir nicht sagen da ich noch nie mit einem
ATMega128 zu tun hatte.

Ansonsten mal testweise eine C Source Funktion die im oberen Bereich
liegt mit vielen lokalen Variablen compilieren. Danach mal im *.lst
File nachschauen was der Compiler als Code erzeugt hat.

Gruß Hagen

hier mal version 2.2. du scheinst noch mit 2.1 zu arbeiten. In dieser
Version hatte ich überall schon das hi8(),lo8() durch pm_hi8() und
pm_lo8() ausgetauscht.

Gruß Hagen

shit, obige ist noch die alte version, hier die richtige, sorry.
das ist die demnächst zu veröffentlichende version 2.2. an der eben
noch eventuell zu arbeiten ist. Also nicht stören wenn überall noch
version 2.1. drinnensteht, und die pm_hi8() änderung noch nicht in der
readme.txt auftauchen.

gruß hagen

@Volkmar,
wenn du deine Anpassungen für den ATMega128 in der GLCD fertig hast,
und diese funktionieren könntest du mir diese änderungen dann zukommen
lassen ? Wäre nett, denn ich könnte sie dann direkt in die offizielle
Version einbauen.

Gruß Hagen

Hagen,

mache ich gerne. Ich habe zur Zeit leider nur ein zeitlichen Problem.
Hast Du denn schon eine zeitliche Vorstellung, wann Du die 2.2
offiziell machen möchtest?

Obiges war aber eigentlich das einzige Problem, welches ich wegen dem
M128 hatte (abgesehen von Port-Definitionen). Aber ich habe einiges
wegen dem Nokia 3510i geändert, und noch ein paar andere Kleinigkeiten.
Das wäre sicher interessant für die 2.2. Ich schaue mir Deine aktuelle
Version mal an und den Rest machen wir dann offline, würde ich
vorschlagen.

Volkmar

Nochmal ich,

habe gerade nachgeschaut. Die 2.2 wurde schon mal veröffentlicht (Ende
April). Und das ist auch die, die ich nutze. Der einzige Unterschied
liegt im angesprochenen pm_hi8() und pm_lo8(). Sonst habe ich keinen
Unterschied entdecken können.

Jedenfalls werde ich es, sobald ich dazu komme, testen und Dir Bescheid
geben. Wenn ich es heute abend nicht schaffe (und auch da ist der
zeitliche Rahmen schon eng), wird es erst nächste Woche was.

Volkmar

korrekt es ist die einzigste Änderung, irgendwann tritt jedes Projekt in
die Phase des "Tiefschlafes" ein wenn man es nicht mehr braucht ;)
Und danke das du mir die Änderungen mailst. Bin schon gespannt darauf.
Allerdings, am Font Editor habe ich einige Bugs beseitigt.

Version 2.2 sollte eigentlich offiziell deine Nokia 3510i Änderungen
enthalten. Auch die Anpassungen für den Epson Controller wären schön
gewesen, nur hatte ich bisher in diesem Punkt noch keinerlei Feadback
von anderen (ich selber habe ja kein Epson Display). Aber du weist ja
wie das ist, wenn man es selber nicht konkret benötigt dann lässt man
es zeitlich schleifen.

Gruß Hagen

Volkmar, lass dir Zeit es eilt nicht, bin eh nächste Woche in London.

Gruß Hagen

Kurze Rückmeldung: Mit den Änderungen in pm_lo8() etc. funktioniert es
an dieser Stelle. Der Rest kommt dann wie besprochen später.

Volkmar

Hi,

ich habe ein Problem mit dem Fonteditor.
Wenn ich eine Font im Editor öffne zum bearbeiten, dann kann ich sie
nichtmehr bearebiten. Nur Fonts die ich neu anlege können von mir
bearbeitet werden.
Habt ihr auch dieses Problem, was kann ich da machen? Ich moechte mir
eine Icon-Font anlegen und die Icons nicht staendig neu machen, wenn
ich an einem etwas verändere...

Da gabs noch einen Fehler, probier mal den aus dem Anhang aus.

Gruß Hagen

danke, funktioniert glaube ich besser :-)

so ganz funktioniert das immer noch nicht... :-/

Stimmt, jetzt müsste es aber definitiv funktionieren. Leider kann ich
nicht mit deinen Daten austesten ;)

Gruß hagen

Hallo Hagen,

da ich auch Probleme mit dem Fonteditor hatte (vielleicht erinnerst Du
Dich ;-), habe ich eben mit dieser Version folgendes ausprobiert
(nachdem ich meine alten Dateien auch damit nicht bearbeiten konnte):
- Fonteditor starten
- Neuen Font erstellen, Höhe 5 Pixel
- Zeichen '0' erstellt (3 Pixel breit)
- Font abgespeichert
- Font wieder geladen
- Zeichen '0' ist leer, und ich kann auch keine anderen Zeichen
ändern/hinzufügen

Wo wir schon dabei sind: Ich hätte noch folgenden Wunsch. Mit "Export
font" wird ja die header-Datei für den Compiler erzeugt. Solange man
den Font nur aus einem Modul heraus verwendet, ist die auch
ausreichend. Wenn ich jedoch mehrere Module in meinem Projekt habe in
denen ich den gleichen Font verwende, wird dieser Font n-mal
eingebunden. Kannst Du nicht zwei Dateien exportieren? Eine .h und eine
.c? So habe ich die Font-Dateien bei mir von Hand angepaßt. Hier ein
Beispiel:
----- Datei f3x5.h -----
#include <inttypes.h>
#include <avr/pgmspace.h>

#ifndef f3x5_H
#define f3x5_H

#define f3x5_WIDTH 4
#define f3x5_HEIGHT 5

extern uint8_t _attribute_ ((progmem)) f3x5[];

#endif
----- Datei f3x5.h -----

----- Datei f3x5.c -----
#include <inttypes.h>
#include <avr/pgmspace.h>

uint8_t _attribute_ ((progmem)) f3x5[] = {
    0x00, 0xFA, 0x04, 0x05, 0x01, 0x30, 0xB0,
    ...
};
----- Datei f3x5.c -----

Volkmar

Ja, das lässt sich beides machen. Der Fehler ist noch drinnen, habs in
15 Jahren Profi-Programmierung noch nie erlebt das man eine Software
fehlerfrei bekommt, ich beete das ich diesen tag mal erleben darf.

So wie es aussieht entsteht dieses Problem NUR wenn man einen Font
speichert der nur 1 Zeichen enthält.

Das Speichern könnte ich mir so vorstellen das man verschiedene
Templates erzeugt. Wir haben ja jetzt schon "font.template" das als
Vorlage zur Erstellung der Header datei dient. Ich werde es nun so
umbauen das in der Konfiguration Font.ini mehrere solcher Templates
angegeben werden können. Die Endung des Templates gibt dabei die Endung
der zu exportierenden Font Datei an. Der Inhalt des Templates den Inhalt
der exportierten Datei. Somit ist es frei konfigurierbar was du wie wo
abspeichern willst. Ich müsste dann nur nochmal eine kleine Hilfe zu
den Templates und deren Aufbau erzeugen.

Gruß Hagen

Ok, Änderungen sind eingearbeitet und der blöde Editierungsfehler beim
geladenen Font sollte jetzt wirklich raus sein.

In der Datei "Templates.txt" steht drinnen wie die Templates
aufgebaut sind, Diese werden in der "Font.ini" angegeben und diesen
als Vorlage beim Export der Fontdatei. Es können mehrere solche
Vorlagen als Datei in der INI angegeben werden, und der Editor
exportiert dann nacheinander die gleichen Fontdaten in diese Dateien.
Die Extension dieser Template Files werden dann zu den Endungen der
exportierten Dateien.

Gruß Hagen

Hallo Hagen,

vielen Dank für die prompte Bearbeitung. Auf den ersten Test sieht das
alles gut aus.

Volkmar

Hallo, ist es ein größerer Aufwand das Font-Program so abzuändern, das
man damit 256 Farben nutzen kann? Ich möchte ein paar Icons entwerfen
und da komme ich mit 16 Farben nicht so weit. Wie kann ich mir da sonst
weiterhelfen?

Danke

in den Font Dateien steht ausserdem drin, das die nicht komprimiert
sind, wie schalte ich die komprimierung ein, so verbrauchen die
naemlich schon sehr viel speicher...

Hier mal eine 256 FontEditor Version. Einzigstes "Manko" ist die
Auswahl der Farbe in der Farbpalette. Man muß halt umständlich
scrollen.

Du musst dann aber testen ob die GLCD Fontroutinen mit 256 Farben noch
sauber arbeiten, eventuell sind Änderungen an den Font Routinen nötig.

Der FontEditor selber versucht immer den Font zu komprimieren. Im Memo
des FE's kannst du nachschauen wieviele Bytes ein komprimierter Font
und ein un-komprimierter Font benutzt. Sollte der Font unkomprimiert
weniger Speicher verbrauchen so wird der Font immer unkomprimiert
gespeichert, logisch.

Die verwendete Komprimierung (ähnlich wie RLE) kann natürlich nur
komprimieren wenn viele Pixel mit gleicher Farbe hintereinander im
Zeichsatz vorhanden sind. Dies ist bei Fonts auch die wahrscheinlichste
Grafik. Bei Bitmaps/Icons aber sind die Bildinhalte wenig Monochrom und
deshalb sinkt das Komprimierungsverhältnis drastisch. Aber, einen Trost
gibt es, bis auf das komplizierte JPEG Format (verlustbehaftet) gibt es
im Grunde keine wirklich gute Komprimierungsart die kribbelbunte Bilder
komprimieren kann (auf'm AVR :)


Gruß Hagen

vielen dank, das ist echt genial das du immer so schnell reagierst!
eine andere Frage habe ich allerdings noch,
meine momentanen 16 Farben Icons werden wenn ich sie auf den AVR lade
anders angezeigt, als sie im fonteditor waren, also z.B. rot ist nicht
rot sondern blau. die Farben wirken alle sehr blau/gruen stichig. Muss
ich irgendwas speziell konfigurieren oder vorher setzen um die Farben
so zu sehen wie im Editor? Habe schon versucht fuer die 16 Farben den
glcdSetColor Befehl auszufuehren, aber das bringt nichts, bzw. beim
setzen von allen ist der AVR abgestuerzt.

Die Fonts speicher nur indirekt die Farbe. In der GLCD Library gibt es
ja das glcd_Colors[] Array. Dieses speichert die realen Farben. Du
musst also 2 Dinge machen:
1.) glcd_Colors[] muß die korrekte Größe besitzen, dazu
glcd_ColorTableBits in deinem Falle auf 4 setzen, da 2^4 = 16 ist.
2.) nun musst du natürlich vor dem Zeichnen einen Fontzeichens dieses
glcd_Colors[] Array mit den richtigen Farben füttern.

Diese Vorgehensweise der GLCD hat im Grunde nur Vorteile. Man kann
x'beliebige Fonts erzeugen, unabhängig von der realen Farbe, und dann
zur Laufzeit kann man die gleichen Zeichen in unterschiedlichen Farben
zeichnen lassen. Oder im Falle einer Portierung der GLCD Library kann
das bedeuten das die Art und Weise wie die Farbapixel gesetzt werden
müssen unabhängig von der Fontroutine ist.

Und ja, das Display ist Blaustichig. Das musst du vorher
berücksichtigen und in glcd_Colors[] eben Farben benutzen die deinem
Gechmack entsprechen. Ich habe die Erfahrung gemacht das man zwar mit
den maxiaml 4096 Farben arbeiten kann, aber effektiv nur 256, oder
sogar 16 Farben sich real sauber unterscheiden. D.h. die meisten Farben
der 4096 möglichen sind enorm Balustichig. Besonders die dunklen Farben
bis hin zu schwarz sind immer bläulich.

Woran das liegt weis ich nicht, entweder an den bläulichen
Hintergrund-LEDs, oder am Typ des Displays.

Gruß Hagen

Denoch, für den Preis bekommt man momentan kein besseres und einfachers
und kompakteres Display als das Nokia. Schau dir mal die Grafikdisplays
bei den einschlägigen Händlern an, vergleichbare Typen kosten das 5 bis
6 fache, und sind in der Bauform viel globiger.

Gruß Hagen

Wo bekommt man das Display

lG chris