Forum: Projekte & Code Nokia 6100 Grafiklibrary die Zweite

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

@chris: am besten bei ebay, ich habe ca 16Eur gezahlt. Achte aber darauf
das die Platine braun ist!!!, die mit der gruenen Platine haben einen
anderen Controllerchip drauf und lassen sich nicht so gut ansteuern.

ich habe versucht die Farben wie folgt zu setzen, aber die Farbtoene
sind trotzdem alle schwarz  bla  gruen

glcdSetColor(0, RGB(0xff, 0xFF, 0xff));
usw.
was mache ich falsch?

1.) du hast in GLCD.inc auf den 256 Farben Modus eingestellt

#define USE_CLIPPING                                        // support
clipping
// #define USE_HIGHCOLOR                                       // 65536
color mode
// #define USE_ORGINALCOLORS                                   // in
256 color mode use original color table
// #define USE_AUTOINIT                                        // call
glcdDisplayInit() automaticaly on startup

2.) in GLCD.inc hast du

#ifndef COLOR_TABLE_BITS
#define COLOR_TABLE_BITS            4                 // 2^4 = 16
colors in color table (minimum)
#endif


stehen. Falls Punkt 1.) oder 2.) nicht zutraf so musstdu dies ändern
und die GLCD Library erneut vollständig compilieren.

3.) glcdSetColor() ist nur ein Makro und benutzt glcd_Colors[Index] =
Farbe; Du hast im Fonteditor in der Farbpalette zb. folgende Farben
eingestellt: Schwarz, Weiß, Rot, Grün, Blau usw. Einstellen kannst du
dies per Doppelklick auf die Farbe. Wichtig ist nur eines, der Index
dieser Farbe entspricht dem Index in glcd_Colors[]. Also Schwarz = 0,
Weiß = 1, usw.
Demzufolge setzt du nun glcdSetColor(0, BALCK); glcdSetColor(1, WHITE);
glcdSetColor(2, RED); usw. usw.

Gruß Hagen

hm, merkwuerdig, das habe ich eigentlich gemacht gehabt, aber es geht
irgendwie trotzdem nciht, habe bis jetzt nur 16 Farben Fonts, aber die
werden alle immer in Blau/Gruen/Schwarz angezeigt, auch wenn die
sonstige Schrift andersfarben ist (glcdSetColor fuer 0 und 1)

gibt es sonst noch irgendeine Option die ich vergessen haben koennte?
kompiliert wird eigentlich auch immer alles. Die glcd.inc liegen in den
avr-gcc Verzeichnissen, das ist ja eigentlich auch korrekt... hmm...
muss ich noch weitersuchen

Ohne deine Sourcen und Fonts zu kennen kann ich dir da auch nicht
weiterhelfen, irgendwo must du einen kleinen Fehler gemacht haben. Die
GLCD selber läuft garantiert. Im Source solltest du meine EMail
Addresse finden, kannst mir ja mal deine Fonts und Sourcen mailen.

Hast du denn mehr als ein Display ? Eventuell man das LCD austauschen
und schauen ob das zweite genauso reagiert. Vielleicht haste ja dein
LCD durch Überspannung beschädigt ?

Gruß Hagen

Benutzt du eigentlich die Backlight LEDs ?
Wenn du das LCD ohne Hintergrundbeleuchtung ansteuerst musst du schon
sehr genau hinschauen (mit entsprechender Beleuchtung) um die
Farbunterschiede zu erkennen.

Gruß Hagen

ich habe zwei Displays, aber ich denke nicht, das es beschaedigt ist,
bei der Schrift zeigt es ja die verschiedensten Farben an.
Ich betreibe das Display mit 6,5V Hintergrundbeleuchtung.
Ich werde nochmal selbst schauen wodran es liegt, ansonsten mail ich
dir mal die Source.
Danke fuer deine Hilfe!

Ich benutze CodeVision und einen ATMEGA162 mit 8MHz.
Habe mir die Library runtergeladen und das Makefile angepaßt (CPU und
Quarz).
Nur wie kann ich nun das Make ausführen ohne mir vorher nen anderen
Compiler zu installieren?
Kann ich das irgendwie in mein Projekt mit einbinden?

@smartie

Da mußt Du wohl alle Sourcen an CodeVision anpassen, dann kannst Du die
Lib auch unter CodeVision verwenden.

Volkmar

habs mittlerweile hinbekommen, hab das winavr installiert, war ganz
easy. Testprogramm aufgespielt. Aber Display bleibt außer der
Beleuchtung dunkel.
Habe an
Port B4 Chip Select Pulse mit 3 µs breiten High Pulsen, Pulsabstand
50µs
Port B5 Data Pakete im 50 µs Abstand
Port B6 Reset High Pulse von 3 µs im 50µs Abstand
Port B7 Clock 1 breiter Puls und 8 schmale Pulse, Pakete auch im 50µs
Abstand

Sieht also soweit schonmal ganz gut aus. Nur die Datenpakete scheinen
konstant zu sein, da ändert sich nicht viel.
Ist das mit den ständigen reset Pulsen auch korrekt?
Ist das Chip Select denn so korrekt oder muß es invertiert werden?

Zur Anpassung der 5V auf 3,3 Pegel habe ich je nen Widerstand drin,ne
Z-Diode nach Masse und nen Pull down nach Masse. 3,3V hab ich auch so
erzeugt, mit nem Elko dran.

Nein, die Reset-Leitung müßte nach dem Anfangsimpuls (habe es nicht mehr
im Kopf ob High- oder Low-Pegel) konstant bleiben. Da bei Dir alles
scheinbar nach 50µs wieder von vorne anfängt, stimmt da was wohl
nicht.

Invertieren ist nicht notwendig. Ich habe die Leitungen direkt über
einen Widerstands-Spannungsteiler direkt mit dem Display verbunden. Ich
mußte nur bei meinem ATmega128 die Reset-Leitung vom MISO-Pin weglegen.
Aber den von Dir beschriebenen Effekt hatte ich nicht.

Volkmar

Das heißt also der Controller resettet sich aus irgendeinem Grund.
Das erklärt auch warum die Daten so konstant aussehen.
50 µs sind auch so eine typische Watchdog-Zeit.
Gerde nochmal geschaut, die Fuses sind alle 1 also unprogrammiert.
Hatte den ATMEGA162 als ATMEGA16 compiliert.

Jetzt hab ich die glcd.inc erweitert um

#elif defined (_AVR_ATmega162_)
  #define   LCD_PORT                _SFR_IO_ADDR(PORTB)
  #define   LCD_PIN                 _SFR_IO_ADDR(PINB)
  #define   LCD_DDR                 _SFR_IO_ADDR(DDRB)
  #define   LCD_CS                  PB4   // SS
  #define   LCD_SDA                 PB5   // MOSI
  #define   LCD_RESET               PB6   // MISO
  #define   LCD_SCL                 PB7   // SCK

und den ATMEGA162 in die makefiles geschrieben.
Außerdem Clock 8000000 in makefile und glcd.inc geändert (hatte ich
schon vorher)
Ergebnis:

Der Resetpuls kommt nun nach 60ms. Das Chip Select Signal besteht nun
aus 2 High Pulsen.
Irgendwie seltsam das ganze.

Wirklich keiner ne Idee, wie man die Library mit nem ATMEGA162 ans
laufen bekommt?

oder wohl wieder mal was für die Kiste mit angefangen Projekten...

Umschreiben für Codevision ist fast unmöglich, da die Variablen immer
erst bei Bedarf deklariert werden, das mag Codevision nicht.

Oder gibts irgendwo ein einfaches C-Code Beispiel nur zum Testen für
das Display?

Ich will mal erhlich sein: das von dir beschriebene Verhalten deutet mit
hoher wahrscheinlichkeit auf einen Fehler deinerseits hin. Die GLCD
wurde schon mehrfach erfolgreich verwendet ohne das es zu Problemen
führte. Wie sollen wir aber nun eine Bewertung und Hilfe anbieten wenn
wir nicht wiessen:
- wie deine Hardware aussieht
- wie deine Software aussieht
- wie groß dein Wissenstand ist

Sorry, falls ich mit diesen Aussagen ein bischen zu erhlich und direkt
bin, aber nur so kommen wir weiter.

So wie ich die Sache einschätze Reset sich der AVR selber. Dafür könnte
es viele Ursachen geben, zB. Kurzschlüsse an einem Pin oder Stackfehler
in Software ect. pp.

In der GLCD ist ein Testprojekt enthalten. Du konfigurierst erstmal die
GLCD Library, compilierst sie neu, kopierst die Lib Dateien in den
richtigen Pfad. Dann konfigurierst du das Testprojekt, compilierst es
und installierst das HEX auf'm AVR. Alle Schritte sind in der GLCD
beschrieben.

Gruß Hagen

"wie deine Hardware aussieht"
wie schon beschrieben: ATMEGA162, Hardware ist geprüft und
funktioniert. Port B hatte ich vorher ein VFD-Display dran, daher war
der komplett frei.

"wie deine Software aussieht"
Testprogramm aus der ZIP-Datei GLCD V22
geändert:
- ATMEGA162 in die beiden Makefiles
- 8 MHz in das Makefile der Library
- Eintrag in die GLCD.H:
#elif defined (_AVR_ATmega162_)
  #define   LCD_PORT                _SFR_IO_ADDR(PORTB)
  #define   LCD_PIN                 _SFR_IO_ADDR(PINB)
  #define   LCD_DDR                 _SFR_IO_ADDR(DDRB)
  #define   LCD_CS                  PB4   // SS
  #define   LCD_SDA                 PB5   // MOSI
  #define   LCD_RESET               PB6   // MISO
  #define   LCD_SCL                 PB7   // SCK

- Library compiliert und in das entsprechende Verzeichnis kopiert
- Testprgramm compiliert und auf den Prozessor programmiert

"wie groß dein Wissenstand ist"
groß bezüglich Microcontroller, klein bezüglich WINAVR


Da die Definition des MEGA162 gefehlt hat, wurde wohl die Library auch
noch nie auf diesem Prozessor ausprobiert.

Wäre es vielleicht möglich, das Demo als ATMEGA162 mit 8MHz zu
compilieren und mir zuzuschicken?

das kannst du dir doch selber kompilieren, so schwer ist das nun echt
nicht.

kann schon, aber dann funzt es ja nicht.
s.o.

Hardware:

- mit welcher Spannung ?
- haste Spannungsteiler am LCD ?
- wie lang ist das Kabel zum LCD ?
- was ist noch am AVR angeschlossen ? und wie ?
- wieviel Ampere liefert die Stromversorgung ?

Es sind also noch einige Punkte offen.

Gruß Hagen

5V DC/DC Wandler 1A
noch gar kein LCD angeschlossen solange der Microcontroller nicht
läuft.

Habs heute mal selbst probiert, wenn ich die SPI-Schnittstelle von Hand
programmiere, funktioniert sie einwandfrei, hab dann mal angefangen die
glcd.h für codevision umzuschreiben. Die glcd_Send Routine funktioniert
schonmal.
Bei der glcd_init bin ich dann schon fast verzweifelt, hab nirgendwo
die set_color routine gefunden. Werde morgen weiter suchen.

Also 5V sind für das LCD zu viel, aber das dürftest du ja hier im Forum
nachgelesen haben. Desweiteren MUSS das LCD angeschlossen sein damit
die GLCD funktioniert. Die GLCD fragt bei der Initialisierung das LCD
ab. Ist es nicht vorhanden kann die GCLD auch kein LCD abfragen.

Gruß Hagen

ohne Display sollte das Programm sich hier aufhängen, aber nicht ständig
resetten:
// wait for booster
    d = 0;
    while (!(d & 0x80000000)) {
      glcdDisplayCommand(DISPLAY_STATUS);
      d = glcdDisplayRead(33);
    }
    glcdDisplayCommand(DISPLAY_ON);
 // wait for display
    while (!(d & 0x00000400)) {
      glcdDisplayCommand(DISPLAY_STATUS);
      d = glcdDisplayRead(33);
    }

und ? haste den Watchdog aktiviert ? Du hast schon recht das in obiger
Loop ohne Display eine Endlosschleife auftritt. Somit wäre nur noch der
Watchdog meiner Meinung nach für den Reset verantwortlich.

Ich habe jetzt mal angefangen die GLCD für mein ATmega162 Board
anzupassen. Übers Wochenende werde ich mal sehen das ichs real testen
kann. Vielleicht sogar im Zusammenspiel mit meiner MMC-SPI Library.

Gruß Hagen

funktioniert jetzt, die Reset Pulse kommen von der SPI, MISO nicht als
Reset verwendbar.
Selbst wenn ich den PIN nach dem Reset Puls als Input schalte, habe ich
dort die MOSI Daten drauf, schon irgendwie seltsam.

Du hast auf der MISO Leitung die Signale der MOSI drauf ?
Dann ziehe mal den ISP Stecker vom Board,und mach dann einen Reset des
Boards. Scheint wohl so zu sein das dein ISP Programmer da nicht ganz
mitspielt. Was nutzt du ?

Gruß Hagen

Das Problem mit dem MISO Pin und Reset hatte ich bei meinem Mega128 aber
auch. Der AVR machte zwar keinen Reset, aber das Display bekam kein
ordentliches Reset-Signal. Ist schon eine Weile her, daher kann ich
mich nicht erinnern, ob das abhängig vom ISP Programmer ist.

Volkmar

@Hagen:
Wie veränderst du denn die gelbe Hintergrundfarbe, die bei init
automatisch genommen wird?
Mit setColor(s) kann ich nur die Farben in und um einen Font bzw.
Rechteck oder Kreis ändern.
Vielen Dank

Der Hintergrund beim Init des Display, sprich der Display RAM des
Controllers ist mit zufälligen Daten = Muster gefüllt. Das Init muß
also auch immer mit glcdFillRect(), eg. glcdClearScreen() initialisiert
werden. Dazu wird der Bildschrim in der Hintergrundfarbe gefüllt. In
glcdClearScreen() wird intern glcdFillRect(0, 0,132,
132,SCREEN_COLOR);aufgerufen. SCREEN_COLOR == SCREEN_COLOR0 == YELLOW
ist in der Datei glcd.inc gefiniert, also hardcoded, das spart ein par
bytes. Du kannst also entweder SCREEN_COLOR0 auf eine andere Farbe
ändern und dann die GLCD neu compilieren, diese Änderung ist dann
dauerhaft. Oder aber nach dem Aufruf von glcdDisplayInit() eben
glcdFillRect(...) statt glcdClearScreen() aufrufen. Schau mal in die
Datei Test.c des Demo Projektes rein.

Gruß Hagen

Alles klar.
Vielen Dank für die schnelle Hilfe.
Echt ne super LIB von dir.
Nur weiter so....

Bei mir funktioniert der glcd_wait nicht, da hängt sich der Prozessor
bei auf.
Kann ja eigentlich nur mit dem 8 MHz Quarz zusammenhängen.

glcdMoveTo mit anschließendem glcdDrawChar funktioniert nur nach einem
glcdclearscreen

Hallo,

ich würde mir gerne ein entsprechendes Display bei ebay besorgen. Da
gibt es aber, so weit ich das gesehen habe, 3 Typen:
1. komplett braune flexible Leiterplatte (sehr, sehr selten!)
2. flexible Leiterplatte bei der Windung von der Vorder- zur Rückseite
braun, am Stecker aber grün (siehe Anlage)
3. komplett grüne flexible Leiterplatte

Muss ich unbedingt Typ 1 kaufen oder funktioniert Typ 2 genauso?

So, hab diese blöde WINAVR in die Tonne getreten und alles nach
Codevision portiert. War ein paar Tage Arbeit aber nun funktionierts
super. Die Library war leider nicht zu gebrauchen, deswegen hab ich die
1.1 Version genommen.

Hat denn schonmal jemand weitere Routinen geschrieben?
Hex, Dezimal und Balkenausgabe waren schnell programmiert, aber möchte
nun ein Zeigerinstrument realisieren, bin aber noch am überlegen wie.

Möglichkeit 1 wäre 90 Zeiger (0-90 Grad) als Font abzulegen, alles
andere bekommt man mit der Orientierung. Vielleicht die eleganteste
Lösung, da man auch schöne Grafikzeiger basteln kann. Problem sehe ich
dabei, daß jedesmal auch die Skala neu geschrieben werden muß, da der
Zeiger als Font ja eckig ist.

Möglichkeit 2 wäre, den Zeiger aus drei Linien immer zusammenzubauen
und neuzuschreiben, ist sicher die schnellst Variante, und braucht
wenig Speicher.

Möglichkeit 3 wäre, den Zeiger in ein RAM-Feld zu schreiben und das
dann immer komplett auszugeben.


@Martin Steghoefer: das 1. kenn ich nicht, das 3. hat nen Epson
Cntroller und funktioniert nicht mit der Library, also die Version 2.
kaufen.

Schönen Dank!

> Die Library war leider nicht zu gebrauchen, deswegen hab ich die
> 1.1 Version genommen.

Tja, auf meinem ATmega162 Board mit 16Mhz hat sie auf Anhieb
funktioniert, sogar zusätzlich mit SD/MMC Karte am SPI.
Umkonfiguiert musste nur XTAL werden, das wars. Mir ist es im Grunde
egal was du für eine Meinung über die GCLD hast, denn nicht bei mir
läuft sie nicht sondern bei dir.

Möglichkeit 1:
das ist grafisch die schönste Methode und es gibt auch keinen
Widerspruch oder Probleme mit dem Neuzeichnen der Scala. Besonders bei
der neuen GLCD Version 2.2 unterstützen die Font Routinen ein Clipping.
Es ist also sehr effizient möglich nur den Teil der Scala unter dem
neuzuzeichnenden Part des Zeigers darzustellen. Das dürfte flickerfree
gehen. Tja, aber das dürfte eben nur mit der Version 2 der GLCD so
gehen.

Möglichkeit 2:
geht auch, du bindest nur die mathermatischen Libs ein und kannst das
durch einfachste Geometische Winkelberechnungen die Koordinaten der
Linien berechnen.

Möglichkeit 3:
Ist nichts anders als ein Double-Buffering und wohl die langsammste
Alternative. Macht eigentlich nur Sinn wenn wie in einem Game mehrer
Layer wie sich bewegende Backgrounds und Sprites benötigt werden. Da
die GLCD alle Grafikfunktionen immer direkt auf das LCD anwendet müsste
man alle nötigen Funktonen umschreiben damit sie im Doublebuffer
arbeiten. Also einiges an Umschreiberei und ein erhöhter
Speicherbedarf. Immerhn 128x128 = 16KByte SRAM maximal.
Nun in der Version 2 der GLCD gibt es sogar schon eine einfache
Funktion, glcdDisplayBuffer(), die effizient einen rechteckigen
Speicherbereich als Bitmap an das LCD sendet. Tja, aber eben nur in
Version 2.

Gruß Hagen

Achso, bei der Möglichkeit 1, bzw. bei der Verwendung des FontEditors in
der Version 1.1der GLCD solltest du aufpassen. Denn erst ab Version 2
der GLCD werden die komprimierten Fonts des FontEditors unterstützt. Da
aber der FontEditor ohne Benutzereingriff autom. entscheidet ob ein Font
komprimiert oder nicht komprimiert wird,kann es sein das die erzeugten
Fonts nicht mit der Version 1.1 angezeigt werden können.

Übrigens: die Version 2 zeichnet Linien, Rechtecke und Ellipsen ca. 15
mal schneller als die reine C Version 1.1. Das liegt eben auch an den
Assemblerroutinen.

Gruß Hagen

funktioniert hatte es bei mir ja auch mit der 2er version, nur hab ich
keine Lust, mich mit dem WINAVR rumzuärgern, wenn ich doch was
gescheites hab.
Außerdem hatte ich meine bestehenden Projekte alle schon in
Codevision.
Das mit dem komprimierten Fonts funktioniert bei mir auch.
Der Font-Editor ist einfach genial. Hat man ganz schnell einen Windows
Font mit konvertiert.
Hatte versucht, die Library einzubinden, funktioniert aber nicht, da
sie zu spezifisch für das WINAVR programmiert ist, werde aber
vielleicht den einen oder anderen Teil daraus noch portieren.
Aber erstmal mach ich mich an mein Zeigerinstrument.
Werde wohl auch die Möglichkeit 1 nehmen. Braucht halt ziemlich viel
Speicher. Zum Testen lass ich aber erstmal ne Linie rotierne nach
Möglichkeit 2

Bei der "Vektor"-linie benötigst du ja keine Skalierung, d.h. die
komplette Anzeige bleibt ja immer gleich groß. Falls du nun auf die
aufwändigen Math Routinen verzichten willst, dann kannst du ja die
Pixelkoordinaten vorrausberechnen und in einer Lookuptable speichern.
Dafür reicht im Grunde ein 1/8'tel Kreissegment, sprich 45 Grad.

Nur der Aufwand um die Linie zu bewegen, sprich Linie zeichnen, Linie
löschen und Linie an neuer Position zeichnen, ist genausgroß wie bei
den Fonts. Denn die Linie kannst du nur löschen indem du sie nochmal in
der Hintergrundfarbe zeichnest. Wenn nun die Linie ein Teil der Grafik
der Skale überzeichnet zu muß dieser Teil ebenfalls neu gezeichnet
werden.

Mit den Fonts verhält es sich genauso. Das Zeichen des Zeigers wird ja
mit transparenter Hintergrundfarbe gezeichnet. Somit werden nur die
Pixel überzeichnet die auch zum Zeiger gehören. Beim Löschen dieses
Zeigers wird das selbe Zeichen wiederum mit Transparentem Hintergrund
gezeichnet, diesmal ist aber die Zeigerfarbe die Farbe des
Hintergrundes der Skala.

Wenn du die Komprimierung drinnen hast dann solltest du mal abtesten
wie viel Speicher eine komplette Skala für 90 Grad benötigt. Falls nur
2 Farben benutzt werden und schlanke Zeiger so dürfte die Komprimierung
relativ hoch sein.

Generell würde ich aber auf eine Bufferung der Bilddaten im SRAM
verzichten, da das viel zu viel Speicher benötigt.

Wenn du es wirklich einfach und informativ haben willst dann stell doch
alles digital dar, einfach eine Zahl zwischen 0-100% statt einer Skala
;)

Das besondere an den Font Routinen ist es ja das die Farbe
"Transparent" ein "nicht-setzen" eines Pixels zur Folge hat. D.h.
die Zeichenroutine überspringt diesen Pixel und somit wird der
vorhandene Pixel im DisplayRAM des Controllers nicht geändert.
Man könnte nun die Font Routine so abändern das zusätzlich zum Zeichen
selber eine Maske mit übergeben werden kann. Ob nun der aktuelle Pixel
des Fontzeichens gesetzt wird oder nicht hängt dann von der Farbe und
eben auch der Maske ab. Die Maske könnte nun ein Zeichen sein das
sozusagen über den Pixeln der Skale liegt und diese vor überschreiben
schützt. Im Grunde würde man das Recheckige Clipping erweitern mit
einem beliebigem Maskenbasiertem Clipping. Das ist die einzigste
Methode die ich kenne die kein zusätzliches RAM benötigt und auch ohne
Lesezugriffe auf das DisplayRAM auskommt.

Ich persönlich würde aber den Zeiger per Fontroutinen in den 90 Grad
Segmenten einzeichnen und dann sofort das 90 Grad Segment der Skale
darüber zeichnen. Das ist zwar nicht elegant sollte aber mit
entsprechendem Takt ziemlich schnell und flickerfree gehen.

Der Vorteil mit den Fonts liegt bei deren Mehrfarbfähigkeiten. Du
benutzt zb. 4 Farben Fonts. 1 Farbe ist transparenter Hintergrund, 1
Farbe ist Vordergrund des Zeigers zB. Schwarz und 2 Farben sind
Anti-Alias, sprich Hell- Dunkelgrau. Nun kannst du die Zeiger so sauber
zeichnen das sie auf dem Display in jeder Position nicht Pixelig
aussehen. Bei einer Linie ist dies nicht so sauber hinzubekommen. Ich
vermute mal das du die Skale ja nur benutzt damit am Schluß grafisch
auch ein tolles Aussehen entsteht,das kostet eben Resourcen ;)

Gruß Hagen

Hallo,

hat schon jemand versucht die Temperatur des Displays auszulesen?
Ich lese immer 0xFF aus dem TD Register was also einer Temperatur von
199°C entspräche. Gibt es bei der Sache einen Haken?

Gruß,
Markus

PS: Ich habe die Philips Variante, am Lesen an sich scheitert es also
nicht.

Geht bei mir auch nicht. Im Datenblatt steht das man im OTP ROM die
technischen Betriebsdaten des Displays festlegen kann. Das macht
normalerweise der Hersteller des Displays. Dort kann man auch festlegen
welche Features der Controller unterstützen soll. So wie es aussieht
kann man die Temparatur nicht korrekt auslesen. Ich habe das aber nicht
weiter verfolgt.

Gruß Hagen

@volkmar

wo gibt es den test-code für den ATMEGA-128 ? sind dort die Anschlüsse
noch gleich, oder ist Reset anders verdrahtet?

gruss
christian

Hallo Christian,

der Mega128 ist doch schon in den Original-Sourcen von Hagen enthalten.
Ich hatte nur das Reset-Signal für das LCD umgelegt, weil es bei mir mit
der Verwendung des MISO nicht klappte. Alle weiteren Änderungen betraf
die Verwendung des Nokia 3510i anstelle des 6100.

Volkmar

vielen dank volkmar,

ich habe die sourcen vom April 2004 version 2.1, gab es da nicht
inzwischen was neueres. das file test ist für den mega-32.
mein AVR-Studio gab beim übersetzen einige Fehler aus und das Display
blieb dunkel. ich wollte nur ein hex-file zum testen der displays  für
den Anschluß an einem STK-501 haben. Beim letzten Mal waren die
Portdefinitionen für den 128L nicht dabei und so habe ich dann wohl
Feher beim verändern gemacht. Falls es was neures gibt, dann hätte ich
gern den link. vielen dank

christian

Hallo Christian,

schau mal hier im Thread das Posting von Hagen datiert 16.09.2004
13:10. Dort ist der Mega128 enthalten. Mit der Übersetzung des
Beispielprogrammes hatte ich keine Probleme. Nur stellte ich halt fest,
daß das Reset-Signal nicht ordnungsgemäß generiert wurde. Daher hatte
ich diese Pin-Zuweisung verändert. Das kann aber auch an meinem Aufbau
gelegen haben.

Volkmar

@Hagen:

Hallo,

eine kleine Frage hab ich noch. Das Display arbeitet ja mit VCC=2,7V -
3,3V. Sind die SPI-Pins 5V-kompatibel, oder sollte man besser die 'L'
Version des Mega 128 nehmen (3,3V)?

Grüße,
André

Hallo Andre
das Display verträgt laut Datenblatt maximal 3,6 V.
Das gilt auch für die digitalen Eingänge.

MartinK

Hallo,

okay. Dann wohl ein ATmega8 in der 3,3V Version. komisch nur, weil das
nirgends erwähnt wird (weder hier im Thread, noch in der Readme). Kann
aber auch sein, daß ich es übersehen habe.

Danke & Grüße,
André

Hi zusammen!

Kann ich die Library auch mit nem Atmel 89C52 betreiben?
Was müsste ich da denn alles anpassen?

Danke

MfG Kev

Hallo,

Ich habe den ganzen Text noch nicht gelesen, werde das aber bald
nachholen. Aufgrund des Datums einiger Post's schreibe ich lieber
jetzt schonmal, und hoffe auf eine Reaktion.

Ich bin auf der Suche nach einem günstigen, kleinen Display, und die
Handydisplays sind ja mit 15€ doch schon recht billig :)
Ich wüsste gerne welche Displays diese Bibliothek unterstützt, und auf
was ich bei einem kauf achten muss.

Danke
Tobias

Hallo Zusammen,

ich weiß es wird in Euren Kommentaren immer darauf hingewiesen das man
möglichst ein Display mit dem braunen Platinenmaterial nehmen soll.
Aber ich habe diese nicht bekommen. Jetzt ist auf der Leiterplatte so
ein schöner SMD- Stecker aufgelötet.... Kennt vielleicht rein zufällig
jemand den Hersteller, oder einen Distributor??? Dann würde ich mir
meine Platine, die ich sowieso inmoment noch erstelle gleich mit
Stecker versehen!

Ich hoffe einer von Euch kann mir zu der Problematik helfen!!

Danke schon mal vorab!!

Gruß
Benjamin

ich habe noch etwas vergessen....

wenn schon jemnad von euch den Stecker verwendet hat, dann werdet Ihr
doch bestimmt auch die Pinbelegung haben!? Oder?

Gruß
Benjamin

Hallo,
die Stecker kaufe ich immer hier:
http://www.shop.display3000.com/pd-1033582389.htm?categoryId=3
10 Stück für 19,95 sind ein guter Deal (gibt dort auch kleinere
Stückzahlen). Distributoren kannst du vergessen, die verkaufen die nur
als 2000er Rolle und da die nirgends auf Lager sind, haben die 8 Wochen
Lieferzeit.
Dort gibt es übrigens auch das Display mit der besten Bildqualität -
ich weiß nicht was daran anders ist, aber das Bild ist um Längen besser
als die der anderen Displays die ich ausprobiert habe.

Übrigens: es gibt 6 oder 7 verschiedene Displays auf dem Markt, viele
mit unterschiedlicher Ansteuerung - einfach nur ein beliebiges Display
kaufen wird schnell zur Enttäuschung führen - die Ebay-Anbieter
verkloppen auch immer gerade das, was momentan am billigsten eingekauft
wird (dem Telefon ist das egal, das erkennt den Typ und passt sich an;
der Mikrocontroller aber eben nicht). Das Thema mit grün und braun
stimmt schon seit 1,5 Jahren nicht mehr, wird aber immer noch gerne
erzählt. Das ist Bullshit und sollte schnellstens vergessen werden!
John

lol, geile Werbung :)
Früher wurden da auf Anfrage nur Set´s mit Krempel den man nicht
braucht angeboten, hat sich das geändert?

Habe die Grafik LCD Libary mal ausporbiert (Besitze ein D62 Board von
Display 3000 mit GLCD Display und Mega128).


Leider wird das Display nicht initalisiert.

Wenn ich es mit Soft SPI mache geht es.

Benötige aber Hardware SPI weil ich noch eine SDCARD ansteuern will
über SPI.

Die SDCARD funktioniert im augenblick nur wenn ich das Display vom
Controller entferne(Abstecke).

Das Display ist orginal von Display 3000.

Die schreiben in den Datenblätten das die Ansteuerung im Beispiel
Software SPI ist aber Hardware SPI kein Problem wäre weil das Display
an den Hardware SPI Pins liegt das stimmt auch aber die Libary von
APATECH funzt nicht.

Ports richtig eingetsellt nur SS ist nicht belegt und CS ist auf der
B5.


Vieleicht hat einer einen TIP

Hallo,

ist das Display von Display 3000 ein Nokia6100?

Gruß Michael

Nein, ist es meiner Meinung nach nicht. Es ist wohl ein S1D17G10 - steht
zumindest so in den Bascom Sourcen dafür. Datenblatt hatte ich keines
gefunden, also habe ich für meine Bedürftnisse fremden Code angepasst
und ein wenig ergänzt.
Wie hast du denn vor die MMC mit dem Display gleichzeitig zu benutzen?
Das Hardware SPI CS ist doch, wie ich das in erinnerung habe fest mit
dem Display verbunden?!?
Gruß,
Jörg

au welcher Schmiede stammt das S1D17G10 ? Sharp ?

vielen Dank für die Antwort

Also es scheint tatsächlich ein Epson Dipslaycontroller zu sein und kein
Phillips.

Aber laut Anleitung von Display 3000 ist es möglich das Display mit
Hardware SPI anzusteuern.

Habe es unsauber gelöst indem ich wenn ich das Display anspreche einen
Flag setzte sodas dei MMC nicht aktiv wird.

Und nach den Display Commands den SPI deaktiviere und bei benutzung der
MMC den SPI nach der MMC Vorgabe aktiviere.

Gefällt mir absolut nicht weil es vorkommt das das Display nur Müll
anzeigt.

Eine Saubere Variante wäre nur den Slave auswählen mit CS low und
fertig.

Soll aber mit dem Phillips Display Controller gehen der aber nicht mehr
hergestellt wird.

Was machen wir denn dann????

Ich denke ich werde mal ein anderes Display ausprobieren von Siemens
S65 oder Nokia 7250.

Hay @all

Danke an Hagen für seine Mühe.

Ich habe das ganze in Codevision geschrieben.
War ein Haufen Arbeit den Code von Hagen zu Zerlegen und
an Codevision Anzupassen deshalb schrieb ich eigene Routinen
aber mit hilfe von Hagen´s Code.

Also in diesem Sinne ein riessen Dank an Hagen.


MFG: Fichte

Hay Leute



Ich habe mir ein Nokia 6610 Display gekauft nun habe ich das Problem es 
sind nur 9 Lötfahnen dran.

Bei meinen Orginal Display sind es 11.

Kennt den jemand die Belegung der 9 Lötfahnen.?


MFG: Fichte

Hab es heraus gefunden wie die Belegung ist.

Hier für alle


1  3,3V
2  GND
3  LED-
4  LED+
5  3,3V
6  RESET
7  SDATA
8  SCLK
9  CS

Das ist das LCD mit der Grünen Leiterplatte.



MFG: fichte

Hallo,
das Display von Display 3000 scheint ja recht nett zu sein, aber die 
machen ein Geheimnis aus der Ansteuerung. Die Pinbelegung ist vermutlich 
gleich, aber läuft das Display mit dem Nokia kompatiblen Code oder muß 
man sich das Display mit Doku kaufen damit man es anpasst ?

Hallo an Frank Nobody und alle anderen, die auch ein Display mit Epson 
Controller S1D15G10 haben.

Ich habe mir ebenfalls die GLCD1.1 von Hagen angepasst. Läuft soweit. 
Auch über die SPI. Was noch nicht funktioniert ist die Darstellung von 
Schrift. Da funktioniert die Darstellung mit dem Philps-Controller doch 
wohl anders. Da mir jetzt die Zeit wegrennt wollte ich mal fragen, ob 
jemand sich eine funktionierende  GLCD für den Epson-Controller 
zusammengestellt hat. Vielleicht kann mir derjenige die Lib auch 
überlassen. Mein Dank würde ihm/ihr auf Ewig hinterherschleichen.... ;-)

Ich habe mal die ursprüngliche GLCD genommen und für den Wickenhäuser 
C-Compiler angepaßt fürs 3510i. Läuft noch nicht über SPI, aber über 
Standard Ausgänge. Mit Bildern scheint es nicht zu gehen, aber Texte 
gehen. Wer Interesse hat, bitte melden. Ich habe einige Änderungen 
vorgenommen, damit es bei mir lief. Läuft bei mir auf einem AT89C51CC03.

Hi

Irgendwie soll man ein Oszilloskop auuf dem Display anzeigen lassen 
können.
Kann mir jemand schreiben wie man das macht.
Oszilloskop am besten über Mikro eingang.

Grüße, Micro=>DIsP_chix

Du machst ein Bild von einem Oszilloskop und einem Mikro Eingang , 
wandelst das alles in ein großes C Array und schon hast du ein Bild von 
einem Oszi mit Mikro Eingang auf dem Display! Super Statisch und mit 
allen Knöpfen und Reglern eines 10k€ Oszis mit Mikro Eingang!! Analog 
kann man das natürlich auch auf das S65 Display anwenden. Um das SNR in 
den Threads etwas zu erhöhen
könntest du dir mal die AVR Tutorials zu Gemüte führen. Nix für ungut!

Hallo  Matthias und Hagen,

beschäftige mich mit einen 320x240 monochrom display von 
crystalfontz.com cfag320240cx (gute Erfahrungen bei Direktbestellung in 
USA) monochrom transflectif mit s1d13700 epson controller. Zur 
Ansteuerung benutze ich einen FlexGateIII von Wickenhäuser (51ED2) 
einschließlich Wickenhäuser-C. Kurven, (Texte mit eingebautem 
Zeichensatz) gehen. Da der eingebaute Zeichensatz einfach nur billig 
aussieht, suche ich nach einer Möglichkeit, mit scalierbaren 
Zeichensätzen zu arbeiten, sodaß auch verschiedengroße Buchstaben aus 
einem Zeichsatz heraus dargestellt werden können.
2 Fragen:

1.:Ist die Portierung nach Wickenhäuser C '51 von GLCD zu bekommen, die 
Anpassung an den s1d13700 via parallel-Ansteuerung bekomme ich hin.

2.Gibt GLCD diese Scalierung her?

Grüße Klaus

Die Antworten waren sehr interessant. Die Möglichkeit der 
FontKompression wird wahrscheinlich eine praktikable Variante sein, da 
sich der notwendige FlashSpeicher in der erwarteten Größe integrieren 
läßt. Einen Spline bzw. Bezier-basierten Fontgenerator für scalierbare 
Zeichensätze in einer auf Speicherplatz und Taktrate beschränkten 
Hardwareumgebung aufzubauen, ist sicher schwierig und vor Allem 
zeitaufwendig. Stellt sich noch die Frage, ob sich die z.B. 4 
Zeichensätze nach kursiv zur Laufzeit manipulieren lassen, oder ob  sie 
explizit ebenfalls hinterlegt werden müssen.

Ich würde gerne die Portation nach 51er C nutzen. Dafür fehlen mir aber 
noch Informationen, die z.Z. auf anderem Wege erfragt werden. Ich melde 
mich diebezüglich dann wieder.

Hi Hagen,

erstmal vielen Dank für diese Lib, war wirklich ein Haufen Arbeit! Gut 
kommentiert an jeder Stelle, sehr schön nachvollziehbar. Bekomme 
demnächst ein paar Displays und zwar aller Wahrscheinlichkeit nach Epson 
S1D... Controller. Frage: Reicht es aus, wenn ich in glcd.inc die 
Hexwerte der Befehlstabelle anpasse oder muss ich mehr ändern? Sollte 
eigentlich reichen, oder? Klar, eventuell ändern sich Werte wie Kontrast 
oder LCD Spannung usw, aber nix weltbewegendes (hoffe ich).

Danke & Grüße

Alles klar, Danke. Werde es auf jeden Fall mal angehen und versuchen, 
daß Ganze hin zu biegen. Der Init ist sicher anders, stimmt, ist mir 
vorhin entfallen. Die Window Funktion gibts im S1D... Controller genau 
so, ich muss nur mal vergleichen, ob die zugehörigen Parameterwerte die 
selben sind, gute Frage. Die Farbtabellen sollten ebenfalls kein Problem 
darstellen.

Na, ich seh schon, wird nix Einfaches, aber dann haben wir´s wenigstens 
mal. ;)

Danke & Grüße! :)

PS: Ich versteh noch nicht so ganz, wie Nokia das gelöst hat. Ich meine, 
es kann doch nicht sein, daß da ein Nokia-Techniker vorm kaputten LC 
Display hockt und erst das Eine, dann das Andere ausprobiert, jenes, das 
funktioniert, bleibt drin. Irgendwie müssen die Handies doch beide 
Displays vertragen können, oder nicht? blödguck

Hallo Hagen

Gibt es eine Möglichkeit die Kompression in Deinem Fonteditor zu 
deaktivieren ?
Falls nicht,könntest Du eine Version ohne Kompression zur verfügung 
stellen ?

Danke

mfg Sylvio

Evtl. habe ich einen kleinen Bug gefunden: Mein Winavr hat rumgemotzt, 
es fehle in glcd.h eine Kleinigkeit (hat nix compiliert): (Zeile 49)

Original:

            Clipping:1;              // activate clipping
    }
} glcdFlags_t;

Korrektur: (Strichpunkt nach "}" )

            Clipping:1;              // activate clipping
    };
} glcdFlags_t;

Ist das korrekt?

Grüße! :)

PS: Display läuft bisher noch ned, brauch (noch immer) Teile.

Danke Hagen

SO! FUUUNZT! :) :) :)

Einziges Prob noch: Die Füllfarben schauen bei mir noch wie sonst was 
aus. Ich habe momentan test.c am Laufen. Linien und Ähnliches werden 
anscheinend in korrekten Farben dargestellt, aber sobald etwas gefüllt 
wird (Rechtecke oder auch die diagonal durchlaufenden Schattierungen) 
wird das Ganze wild: Verschiedenste Farbcodes (schaut ähnlich zu 
Graustufen aus) werden dargestellt.

Hab schon nach sonst was geschaut, aber bisher nix gefunden...

Sorry, kleines PS: Habe anscheinend ein Japaner Display, da der 256 
Farbenmode nicht funktioniert (sogar die Bildschirmweite wird falsch 
initialisiert). Mit 65k Farben funzts soweit einwandfrei. Evtl hats auch 
damit was zu tun, kann gut sein...

Hmmmm, dritte Anmerkung (SORRY!!!): Ich verwende einen ATMEGA32, der 
Code hat 23 kByte und bei ClearScreen(1) schauts fast so aus, als würde 
irgendein Codeschnipsel nochmal geschrieben werden (nach einem Reset 
gibts beispielsweise ein Teilbild von vor dem Reset bei ClearScreen - 
Reste im Display RAM?). Hilft evtl. weiter.

Also, irgendwie komme ich noch so überhaupt nicht mit dem Display klar. 
Ich bin mir wirklich nicht sicher, ob die Schaltung so in Ordnung ist. 
Ich habe jetzt einen 74HC4050 als Pegelwandler drin (ziemlich exakt 3,3V 
und 3,0V ausprobiert). Beides funktioniert nur mit deutlichen 
Kondensatoren an der DATA Line und ich kriege immer noch völlig wirre 
Graphiken (siehe Bild im Anhang). Also grundsätzlich funzt alles, aber 
irgendwie fehlt mir der letzte Schliff...

Öhmmmm, Hilfe?

Hände über den Kopf zusammenschlag

Ach Gott, nööö. Update: Habe eben herausgefunden, warum die ganze 
Geschichte nicht bei mir läuft: Habe Displays mit dem S1D15G17 
Controller (Achtung! NICHT S1D15G10 wie sonst). Das ist anscheinend ein 
weiterer Controllertyp, der noch nirgends wirklich dokumentiert ist, 
aber anscheinend recht gerne verwendet wird.

Toll, gaaanz toll... ich update eben mal den LCD-Artikel in die Richtung 
um andere vom gleichen Fehler abzuhalten und mache mich dann an die 
Programmierung in die Richtung (stöhn).

Puh! Cool, war doch nicht so viel, wie ich dachte.

Also bei mir läufts jetzt. @Hagen: Anbei die in erster Linie angepasste 
Datei. Ich musste ein wenig was im Init ändern (mehr Pausen, Sleep Out 
und Display On auch gleich mit rein, statt erst später aufzurufen). Der 
G17 Controller braucht da anscheinend etwas mehr Zeit, um 
"hochzufahren", aber mehr ist es nicht. Sollte so auch zum 
Nachfolgermodell dem "S1D15G27" kompatibel sein und bleiben.

Ein einziges Problem gibts noch: Bei den 0° und 180° Orientation gibts 
im Testproggi noch Probleme beim String schreiben (Linien usw. funzen 
einwandfrei). Habe versucht mich reinzudenken, aber da hast Du ja ganz 
schön "elegant" programmiert. ;) Nebenbei: Spitzen Programmierstil, da 
kann man sich was abkupfern!

Wenn Du lustig bist, geb ich Dir mal die entsprechende Seite aus dem 
Datenblatt für die Orientation Geschichte, es gibt leichte 
Unterschiede zwischen PCF und G17. Ansonsten versuche ich mich bei 
Gelegenheit wieder reinzudenken und eine für beide Controller kompatible 
Lösung zu finden... vorerst reicht mir der bisherige Funktionsumfang 
nämlich voooohoooollkommen aus. :) :) :)

Hat jemand ne Idee, wie man ein Bitmap zu einem font konvertiert (in 
Farbe)? Und wie mache ich aus den Font-Dateien von Hagens Editor 
eigentlich Datazeilen ?

Gruß,
Thomas

Hey ! Vielen Dank Hagen.

Das mit der Farbpalette bekomme ich hin. Wünsche Dir viel Spaß in 
Jamaika !

Gruß,
Thomas

Wollte nur Fragen ob die Hompage mit der glcd lib irgendwann wieder 
online geht???

Mit ApeTech's Homepage habe ich nichts zu tun, da musst du Ape fragen. 
Er war so freundlich meine Lib zu hosten.

Ich selber habe mit dem Nokia schon seit jahren nichts mehr gemacht. 
Verbaue wenn überhaupt erstmal meine S65 Displays.

Gruß Hagen

@ Hagen
> Verbaue wenn überhaupt erstmal meine S65 Displays.

Wie viele hast du denn noch übrig? Kannst ja welche verkaufen.

hi,

ich kann den code von hagen mit dem neuen winavr nich comilieren und den 
alten gibts nirgens gibts.

gibt es evtl einen neueren code von Dir ?

mfg sven

Guten tag Schweden calling

Tried to write to you in in German but i'm not that good:-(

Anyhow found this site during my websearching and downloaded the 
GLCD.zip file from 040414. I have the same problem, can't compile it 
with Winavr 20071221, i get the following during the compile steps:

C:\make clean
-------- begin --------
Cleaning project:
..
..
Errors: none
-------- end --------
C:\make all
set -e; avr-gcc -MM -mmcu=atmega32 -I. -Os -mcall-prologues 
-funsigned-char -fun
signed-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wa,-adhl
ns=test.lst  -std=gnu99 test.c \
        | sed 's,\(.*\)\.o[ :]*,\1.o \1.d : ,g' > test.d; \
        [ -s test.d ] || rm -f test.d
-------- begin --------
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

Compiling: test.c
avr-gcc -c -mmcu=atmega32 -I. -Os -mcall-prologues -funsigned-char 
-funsigned-bi
tfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wa,-adhlns=test.l
st  -std=gnu99 test.c -o test.o
In file included from test.c:2:
c:/avr/include/glcd.h:49: error: expected identifier or '(' before '}' 
token
c:/avr/include/glcd.h:49: error: expected ';' before 'glcdFlags_t'
make: *** [test.o] Error 1
Press any key to continue . . .

----
Error as shown below:
    }
} glcdFlags_t;    <<<<<<----------

removed one "} " by using //
Then i got the :
In file included from test.c:2:
c:/avr/include/glcd.h:52: error: expected specifier-qualifier-list 
before 'extern'
Which is the line below:

extern uint8_t         glcd_MemCtrl;  // display RAM access and degree 
of rotation

I've done the installation steps by editing and copy the requested 
files... i assume....

All hints are welcome..

Best regards,
Hans

Ich habe genau das gleiche Problem wie Hans aus dem vorigen post.

<<<Mein Display läuft in allen Tests super>>>

Aber beim Copilieren des test.c Codes von Hagen
(-bei dieser Gelegenheit: Vielen Dank für die Bereitstellung des 
Codes:-)

kommt auch der folgende Compilierungsfehler:
In file included from test.c:2:
./glcd.h:49: error: expected identifier or ‘(’ before ‘}’ token
./glcd.h:49: error: expected ‘;’ before ‘glcdFlags_t’
make: *** [test.o] Fehler 1


Für eine Hilfe bei Lösen des Problems wäre ich sehr dankbar.

Gruß min

>error: expected ‘;’ before ‘glcdFlags_t’

The answer is this thread at this post:
Schaut mal in diesem Thread in diesen Post:

Autor: pay.c (Gast)
Datum: 02.09.2007 18:37

Hallo,

ich versuche gerade meinem ATmega16L das schreiben auf das Nokia6100
(Epson Controller Variante) beizubringen.

Mit dem Code von
http://www.e-dsp.com/controlling-a-color-graphic-l...
klappt das schon ganz gut. Es fehlt mir aber noch die Unterstützung von
Schriftzeichen und Bildern.
Mit dem Code von Hagen klappt es jedoch nicht :-(
Da bleibt das Display stumm.

Die Anpassungen laut install.txt hab ich brav gemacht, jedoch glaube
ich, das sich noch irgendwo ein böses define versteckt, was meiner
Schaltung nicht schmeckt. Ich verwende 4 statt 16MHz und habe die
Steckerbelegung von der http://www.e-dsp.com -Seite (die Anpassung im
glcd.inc habe ich doch gemacht).


Gruß Sebastian

Nach all den Spambeiträgen, mal wieder was anderes:

Auf meiner kleinen Blogseite Zipfelmaus (Link: 
http://www.zipfelmaus.com/blog/how-to-nokia-6100-display/) habe ich ein 
Programm zum Konvertieren von BMPs in das RGB8-Format veröffentlicht. 
Das Programm erzeugt ein fertiges h.-file, das man ganz einfach in das 
eigene Projekt einbauen kann.

Downloaden kann man es hier:
http://www.zipfelmaus.com/wp-content/uploads/2008/04/rgb2bmp.exe

ohje wieder Spam

mal eine Frage, hat jemand mein BMP-Konvertierungstool (von 
zipfelmaus.com) ausprobiert und mag über seine Erfahrungen damit 
berichten?

die Seite habe ich nun auch ein wenig angepasst:
http://www.zipfelmaus.com/nokia6100lcd_en/

Hallo Zusammen,

erstmal Danke für die Infos von denen, die sich sachdienlich beteiligen.
Und vor allem grosses THX to Hagen, für das Bereitstellen dieser 
ausgereiften Bibliothek.
Ausserdem möchte ich mich pay.c anschliessen der den Programmierstil 
lobt.

Trotzdem bin ich fast am Ende einer zweitägigen Leidensgeschichte mit 
der Lib.
Daher hab ich im Folgenden ma die Punkte zusammengefasst die ich ändern 
musste damit die Geschichte bei mir läuft.

Meine Hardware:
  ATMEGA8 @5V und @8Mhz, keinen Hacken bei Watchdog
  Spannungsteiler fürs Display: 1,8k/3,3k (suboptimal, ich weiss)
  DisplayController PCF8833: (glaube ich, da ja die DispCommands sonst 
andere wären) auf jeden Fall braune Platine
  Programmer (Hardware): 0815 selbstbau, seriell, (der mit den 2x 4,7k 
und 2x 10k, etc.), Schaltplan bekommt man im Internet überall 
hinterhergeschmissen
  Programmer (Software): PonyProg2000

PinConfig:
  #define   LCD_CS    PB2   // ICP1
  #define   LCD_SDA    PB3   // MOSI
  #define   LCD_RESET  PB1   // MISO
  #define   LCD_SCL    PB5   // SCK

Änderungen an 'glcd00.S':
- SOFT_RESET entfernt (Zeile 207 + 208),
- ganz wichtig für alle die mit Füllfarben Probleme haben, und bei denen 
es so aussieht wie bei 'pay.c' am 'Datum: 19.09.2007 23:05':
  'glcdDispCommand' statt 'glcdDispSend' bei COLOR_INTERFACE (Zeile 211)

Änderungen an 'glcd01.S':
- nicht vom Display lesen: d.h. 'glcdDisplayOn1' und 'glcdDisplayOn2' 
ersatzlos entfernt,
 'glcdDisplayOn' besteht nur aus SLEEP_OUT, INVERSION_OFF, DISPLAY_ON, 
über BOOSTER_ON kann man sich streiten
 ohne diese Änderung bekam ich nur einen schwarzen Bildschirm, an 
LCD_SDA lag dann permanent nur eine Dreiecksspannung an.

Änderungen an 'glcd.h': (neben dem, was in der install.txt beschrieben 
ist)
- das semikolon hinter dem 'struct' in 'union' vor 'glcdFlags_t'

Habe die geänderten Versionen ma angehangen. Hoffe ich konnte damit wem 
helfen.

Offene Probleme:
- die testBitmaps() sieht seltsam aus, hab mir aber noch nicht 
angeschaut, wie man die bedient.
- die testSymbols() ist bei genauem hinsehen nicht ganz sauber
- die testOrientation() erzeugt nicht sauber die strings f. 0,180,270 
Grad, lediglich 90 ist lesbar

Lösungen für die offenen Probleme sind selbstverständlich willkommen.

Hallo,

auch ich habe die Lib mit dem CAN128 am Laufen. Daher versuche ich mal 
einige Kommentare abzugeben ;)

> Das erste Problem war, dass die SPI-Register in dem Controller außerhalb
> des I/O-Adressbereichs bis 0x1f liegen. Da musste dann einiges am
> Assembler angepasst werden, was aber in der ISR nicht sehr effektiv war.
> Inzwischen habe ich ein recht gute Lösung. Ich werde diese in den
> nächsten Tagen hier posten.

Das ist korrekt, ich habe alle cbi und sbi durch ein Makro ersetzt, 
welches abhängig von den Vorgaben die richtigen Kommandos auswählt. 
Desweiteren habe ich die Warteschleifen ähnlich behandelt.

> Das zweite Problem war das Display selbst. Die HW-Variante benötigt
> neben RESET Low auch noch SDA Low und Clock High, und dies stabli
> während der Reset-Phase. Außerdem muss der Reset-Pegel einige Zeit im
> Low-Zustand verbleiben. Muss man erst mal drauf kommen....

Mit dem Reset habe ich auch so meine Probleme, das muß ich mir in Ruhe 
noch mal anschauen. Zur Zeit initialisiere ich 2 Mal ;)

> Danach hat das Demo endlich etwas ausgegeben, allerdings waren die
> Farben falsch und sind es noch bis heute. Rot wird zu Magenta, Grün zu
> Türkis und Blau bleibt Blau. Hat aber nichts mit dem Inverter zu tun,
> das habe ich bereits probiert. Darauf hin habe ich ein einfaches
> Beispiel mit Quadraten in den Farben Rot, Grün Blau und Weiß
> geschrieben, wobei diese einmal über die lib und einmal direkt über das
> Testprogramm generiert werden. Das Display wird hierbei aber nur einmal
> über die Lib initialisiert. Interessanter Weise sind die Farben über die
> Lib falsch und im Testcode korrekt.

Ich hatte ähnliche Probleme mit den Farben, und habe dann eine Änderung 
an gemacht, die hauptsächlich bei Rechtecken zu tragen kommt. Ich glaube 
in der Demo wird immer glcdClearScreen verwendet (vorher das Clipping 
entsprechend gesetzt). Hier habe ich die folgenden ldi-Befehle ersetzt. 
Bin mir aber nicht 100%ig sicher, ob es das war.

1

//        ldi     D0, lo8(SCREEN_COLOR)

2

        lds     D0, glcd_Colors

3

#ifdef USE_HIGHCOLOR

4

//        ldi     D1, hi8(SCREEN_COLOR)

5

        lds     D1, glcd_Colors+1

6

#endif

Falls es das nicht ist, müsstest Du mal posten wie die Quadrate mit der 
Lib aufgerufen werden und wie es mit dem Testprogram erfolgt.

> In der Funktion glcdSetAddr werden die 2 x- und die 2 y-Adressen für die
> folgende Pixel-Ausgabe gesetzt. Es wird aber 2 Mal das Kommando
> SET_X_ADDR an das Display gesendet (Zeilen 19 und 27). Wenn MEM_90 nicht
> gesetzt ist, wird dies so beibehalten, ansonsten wird auf das Kommando
> SET_X_ADDR+1 (SET_Y_ADDR) gewechselt. Sollte es hier nicht so sein, dass
> einmal das X- und einmal das Y-Kommando ausgegeben wird?

Das ist schon richtig so, was da abläuft, ist ziemlich tricky.

Hoffe das hilft erstmal.

Hallo,

> So habe ich das auch zuerst gemacht. Vor allem in der ISR wird dann aber
> massiv zus. Code notwendig, da über die in und out-Befehle zusammen mit
> dem andi insgesamt 2 Register auf den Stack müssen. Alles in allem
> kommen 10 Instruktionen hinzu, und das bei jedem Byte das übertragen
> wird.

Bei mir sind es 6 Instruktionen plus RETI, aber wenn man ein paar Takte 
sparen kann.

> Wenn Du interessiert bist, mache ich das Debugging kurz raus.

Ne, keine Eile. Bei mir läuft es ja soweit ;) Ähnlich auch mit dem 
Reset, hat keine Eile, das Projekt ist noch nicht abgeschlossen und wird 
noch 'ne Weile aktiv sein.

> // So, und jetzt geht's an die Y-Koordintenübertragung.
> // Warum hier jetzt wieder SET_X_ADDR genommen wird, ist mit
> // unklar!

Ganz genau habe ich das auch nicht mehr im Kopf. Es werden aber die 
verschiedenen Möglichkeiten des Chips genutzt um in die verschiedenen 
Richtungen schreiben zu können. Es kann gespiegelt werden, um 90° 
gedreht etc. Durch diese tricky-Programmierung wird das passend gemacht. 
Die Frage ist, ob Du den richtigen Chip im 6100 hast, da gibt es ja 
verschiedene Varianten.

> noch eine Frage. Nutzt Du das Display mit oder ohne USE_HIGHCOLOR?
Derzeit ohne USE_HIGHCOLOR. Habe eben einfach mal den Wert geändert und 
kann optisch keinen Unterschied sehen (nur das Programm wächst in der 
Größe)

Volkmar

Hallo Ralph,

> In glcd.inc kann man jetzt über das Makro SPI_IN_LOWER_IO_REGS steuern, ob
> die SPI im unteren I/O-Bereich liegt oder nicht.

Das habe ich über ein Makro gelöst (Anregung von Hagen). Zum Beispiel 
für das in-Kommando. Statt "in" verwende ich "in_". Dazu gibt es noch 
ein Makro "in_" wie folgt:

1

.macro in_ value port

2

  .if (_SFR_IO_ADDR(\port) > 63)

3

            lds     \value, \port

4

  .else

5

            in      \value, \port

6

  .endif

7

.endm

Damit geht das dann automatisch.

Ich habe an einigen Stellen gesehen, daß Du kein #else beim #if defined 
hast, ist das so korrekt?

Für das Vertauschen von Blau und Rot könnten die nachfolgenden 
Änderungen helfen (ich meine das hatte ich auch):

1

        ldi     T1, COLOR_INTERFACE     // initialize color format and color mapping

2

        rcall   glcdDispSend

Hier muß doch

1

        ldi     T1, COLOR_INTERFACE     // initialize color format and color mapping

2

        rcall   glcdDispCommand

stehen.

Den Block mit den Farben habe ich noch ins Flash verlegt:

1

    .section .progmem

2

#ifndef USE_HIGHCOLOR

3

  #ifdef USE_ORGINALCOLORS

4

COLOR_RED:                                              // original color table

5

        .byte   0x00, 0x02, 0x04, 0x06, 0x09, 0x0B, 0x0D, 0x0F

6

COLOR_BLUE:

7

        .byte   0x00, 0x04, 0x0B, 0x0F

8

  #else

9

COLOR_RED:                                              // modified color table

10

        .byte   0x00, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F

11

COLOR_BLUE:

12

        .byte   0x00, 0x08, 0x0B, 0x0F

13

  #endif