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
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
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 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
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
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...
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, 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
@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?
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?
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
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.
> 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
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,
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é
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
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
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
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.
@Hans Peter:
Ich schlage mich mit dem gleichen Problem UND Modul herum.
Mit einer (angepassten Variante) der GLCD1.1 von Hagen (DANKE AN HAGEN
!!!) läufts super, nach meiner Ansicht ein wenig zu langsam ...
SPI habe ich allerdings noch nicht hinbekommen.
Kannst du mir mal den Teil posten, den du anpassen musstest (für das
D062) ??
Wäre super
Frank
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
Ich danke zurück und freue mich das es einen Nutzen für euch hat.
Demnächst gibts eine ähnliche Library für das S65 -> LPH88xxx -> Philips
HD66773R Controller. Neu sind dann Abgerundete Rechtecke (die Kreis,
Ellipsen Funktion in der Nokia GLCD kann nämlich so umgebaut werden das
man abgerundete Rechtecke zeichnen kann ;) und komprimierte Bitmaps.
Selbstverständlich gibts zum Konvertieren der Bitmaps eine Software für
den PC, wie bei den Fonts.
Gruß Hagen
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
Hallo Klaus,
die Quellen kannst Du bekommen. Vielleicht sind noch ein paar Bugs drin,
oder vielleicht alles noch ein wenig überarbeitungswürdig, aber bei mir
auf dem Schreibtisch läuft das 3510i ganz gut.
Ich brauche nur eine Emailadresse.
Meines Wissens können die Zeichensätze nicht scaliert werden, es stehen
aber einige zur Auswahl. Auch kann man mit einem Programm, was mit
dabeiliegt, selber einen Zeichensatz bauen oder erweitern.
Matthias
Ich stimme Matthias zu.
Die Font Routinen benutzen Bitmap-Fonts und keine
True-Type-Vektor-Fonts. Mann kann zwar auch Bitmap Fonts skalieren,
meistens habe ich Skalierungen um x2,x3,x4 im Netz gesehen. Ehrlich
gesagt: sehen scheiße aus. Dann ist es effizienter die Bitmap-Fonts nach
Möglichekit per Komperssion kompakt zu machen und dann eben 2 bis 3
solcher Fonts zu unterstützen. Und gerade dahin zielte auch die
Entwicklung meiner Fontroutinen. Man kann also sehr schnell und recht
fexibel eine kleine Datenbank von Fonts in der MCU verwenden.
Ein weiteres nötiges Tool war der FontEditor. Mit ihm kann man quasi in
Sekunden einen beliebigen Windows-True-Type-Font in einen Bitmap Font
umwandeln, ihne nachbearbeiten und als komprimierte Daten exportieren.
Man muß auch immer die Relationen betrachten. Normalerweise kann man in
guten grafisch orientierten Systemen 3-4 verschiedene Fonts
unterscheiden, das reicht auch. Ein TTF ist zwar beliebig scalierbar,
aber die Frage stellt sich ob das mit dem herheblichen Aufwand der
Programmierung einer solchen Vektorengine einhergeht mit einem realen
Nutzen später im GUI.
Auch der Speicherverbrauch solcher TTFs ist größer. Verglichen zu den
vielen Schriftgrößen usw. die sich damit anzeigen lassen ist diese
Datengröße super, aber für eine kleine MCU sind durchschnittlich 200Kb
für einen TTFont doch schon wieder enorm. Da bekome ich mit meinen
FontEditor lässig 10 verschiedene Bitmap Fonts unter.
Ich habe sogar TTFs auf meinen Rechner die brauchen 22Mb, wohlgemerkt
für einen TTF !!
Gruß Hagen
Achso, eventuell wäre es sogar cleverer meine S65 GLCD Library zu
benutzen. Ich habe bei dieser "Neu-Portierung" der Nokia-GLCD aufs S65
auf einige Punkte stärker geachtet, zb. Portierbarkeit. So ist fast der
komplette Source in C und die wenige ASM Stellen lassen sich
auskomentieren. Der HW Zugriff ist als Makro-Schnittstelle sehr flexibel
anpassbar. Die grafikfunktionen sind dadurch weitaus portabler. Und
Bitmaps/Icons mit Kompression werden unterstützt -> auf Monochrome mit
besonderst guter RLE Komprimierung.
Ansonsten kann man sagen das beide Bibliotheken in ihren Font-Routinen
absolut kompatibel sind, besonders im benutzten Datenformat.
Schick mir per PN ne Nachricht falls du Interesse am Source hast.
Gruß Hagen
>320x240 monochrom display von
das könnte das eigentliche Problem werden. 240 passt ja noch in 1 Byte,
320 aber nicht mehr. Alle Grafikfunktionen, besonderst Linien, Kreise,
Ellipsen, abgerundete Rechtecken, ja sogar das Clipping arbeiten mit
Koordinaten bis maximal 255x255. Ich habe zwar in beien Libraries darauf
geachtet das für Koordinaten ein eigener Datentyp benutzt wird, ist also
schnel geändert auf 16Bit, aber denoch müssen einige Korrekturen in oben
genannten Funktionen gemacht werden. Meistens dürfte die Vergrößerung
der lokalen Variablen von x Bits auf 2x Bits ausreichend sein, aber
überprüfen muß man das denoch.
Gruß Hagen
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
Hm, du musst wohl schon mehr ändern. Ich benutze zb. in den Font
Routinen die speziellen Addressierungsmöglichkeiten des LCD Controllers
auf seinen Grafik RAM. Dazu gehört als erstes das man über das GRAM ein
Window legen kann. Dieses Window stellt sicher das wenn man zb. 100
Pixcel setzt und ein Window mit 10x10 Pixel Ausdehnung definiert hat das
dieses Rechteck komplett gefüllt wird. Nun kann man innerhalb dieses
Window dem LCD Controller mitteilen in welche Richtung dieses Window
gefüllt werden soll. Also mit welcher Ecke begonnen wird (RAM Address)
und in welche Richtung die Piexel nacheinander gesetzt werden.
Meine Font Routinen definieren ein Window das so hoch ist wie der Font
selber. Dann beginnt man von Links Oben Spaltenweise nach Unten den Font
zu zeichnen.
Du musst also auch die Window Funktionen, RAM Address Funktion und RAM
Direction Register anderst setzten.
Dann noch das problem der Initialisierung. Die glcdDisplayInit(),
glcdDisplayOn()/Off() Funktionen müssen komplett geändert werden.
Das betrifft dann auch die Initialisierung der Farbtabelle falls
vorhanden.
Anderst ausgedrückt: falls das display die gleiche Pixelauflösung hat
dann sind im Grunde nur die High-Level Grafikfunktionen Hardware
unabhängig, leider.
Gruß Hagen
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
Richtig. Der Controller im Nokia wird wohl erstmal das Philips Teil
versuchen zu detektieren, da das auch ausgelesen werden kann. Gibts
keine Antwort wird davon ausgegeangen das es der andere Displaytyp sein
muß.
Gruß Hagen
Vorsicht bei Nokia-LCDs mit angeblichem Epson-Controller: es gibt einige
(z.B. GE8 von Olimex) die nur einen Teil des Epson-Funktionsumfangs
implementieren und z.B. keinen 8-Bit-Modus beherrschen.
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.
Der "neue" Font Editor hat eine Checkbox mit der man explizit angeben
kann das der Font komprimiert werden soll, Standardmäßig also
"unkomprimiert".
Im ZIP enthalten auch der Bitmap Converter für das S65 Display, hier im
Forum kann man im S65 Thread nachlesen wie das Datenformat aussieht.
@pay.c: falsch ist es nicht aber bei meckert er auch nicht rum.
Gruß 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
Der Font Editor "exportiert" den Font beim Speichern gleich in mehrere
Format. *.font Dateien sind binär und stellen das interne Format des
Editors dar. Dann kannst du noch über die INI die Template-Dateien
angeben von denen ausgehend die Font Dateien erzegt werden. Dabei kann
über diese Templates eingestelt werden ob man zb. ein *.h und *.c Datei
haben möchte mit getrenntem Header und Datenbereich. Oder gleich alles
in ein h oder .c Datei exportiert, also Header und Daten in einer
Datei. Unterstützt werden auch Dateiformate für BASIC und ASM. Einfach
mal die INI Datei anschauen und die dort eingeplegten Templates.
Eventuell im S65 Thread hier die neuste Version des FontEditors laden.
Für Bitmaps/JPEGs/GIFs/PNGs/WMFs/ICOs/ANIs/PCXs usw. habe ich einen
eigenen Converter geschrieben, allerdings für das S65 Display. Im S65
Thread findet sich auch dazu einiges an Erklärungen. Für das Nokia ließe
sich dieser Converter umschreiben, allerdings fehlt mir dazu die Zeit
(ab morgen in Jamaika, juchuh :)
Du kannst auch "Bitmaps", eher frabige Symbole mit den Fonts machen. Die
Farbanzahl ist auf 256 Farben begrenzt. Schau dir mal meine
mitgelieferten Farbenfonts an, zb. die Clock oder Weltkarte.
Eine Bitmap kannst du folgendermaßen importieren:
Öffne die Bitmap mit MSPaint oder jedem anderen kompatiblen Bitmapeditor
der über die Zwischenablage arbeiten kann, zb. Corel Photopaint, WinWord
usw. Markiere den Bereich oder die ganze Bitmap den du haben möchtest,
achte dabei darauf das die Farbanzahl <= 256 ist. Kopiere diesen in die
Zwischenablage. Gehen in den FontEditor und drücke den Paste-Button. Der
Font wird dann autom. auf die Größe der Bitmap erweitert und die Bitmap
aus der Zwischenablage eingefügt. Nun ist es dann aber so das die Farben
nicht mehr stimmen. Das liegt daran das der FontEditor defakto ohne
Farbe arbeitet sondern mit Farb-Indexen. Dh. die Farbpalette im
FontEditor muß angepasst werden. Doppelklicke dazu auf die Farbe in der
Farbpallete und stell dort die richtige Farbe ein. Oder exportiere die
Farbpallette der Bitmap selber und speichere sie dann in deinem AVR
projekt in glcd_Colors[]. Beachte das dieses Array[] über das #define
GLCD_COLOR_COUNT korrekt eingestellt sein muß.
Man kann also sehr einfach Bitmaps in den FontEditor importieren, per
Copy&Paste aus anderen Anwendungen. Bis dahin sehr einfach und schnell.
Aber die Farben sind das eigentliche Problem. Ich hatte mir damals ein
Tools geschrieben das die Farbpalette der Bitmap in der Zwischenablage
abspeichern kann.
Das problem ist halt das die GLCD nur eine, zwar ladbare, globale
Farbtabelle kennt die nicht durch das Laden eines Fonts aktualisert
wird. Das muß der Programmierer selber machen, auch das
Verwalten/Speichern dieser Farbtabelle.
Gruß Hagen
Ach übrigens, dieses Kopieren geht auch in umgekehrter Richtung. Du
kannst ein Symbol/Fontzeichen aus dem FontEditor kopieren und in jedes
bessere Malprogram einfügen ;)
Und beim Einfügen solcher Bitmaps kannst du vorher im Editor noch einen
grafischen Bereich auswählen und dann wird diese Bitmap nur dort hinein
kopiert und beschnitten.
Gruß Hagen
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
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
Für's Nokia ? nein. Alles ist hier in den Threads zu finden.
Den FontEditor habe ich weiterentwickelt, also par kleinere Änderungen
und denn kann ich dir mailen. Melde dich einfach heir als registrierter
Benutzer an und sende mir eine PN indem du auf meinen blauen Namen
klickst.
Von den S65 Displays habe ich nur noch 2 wobei eines schon in meinem
elektronischen Drum Projekt verbaut ist. Ergo habe ich nur noch 1 als
Reserve das bei mir rumliegt. Eventuell könnten wir uns einigen da ich
bis jetzt noch nicht die Zeit oder ein Projekt habe um es zu verbauen.
Ist ungenutzt und neuwertig und ein LPHxxxx Teil das durch meine S65
Library angesteuert werden kann. Die S65 Lib kannst du bei mir per
PN/Email bekommen, haben schon viele User hier gemacht. Am liebsten
tausche ich unter Bastlern ;)
Gruß Hagen
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
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,
momentan bin ich dabei eine kleine Karte mit einem Atmega88 und dem
Nokia 6100 zu bauen - basierend auf dem Elektorprojekt ATM 18 (Stecker,
etc).
Smartie hat geschrieben, dass er den Code umgeschrieben hat für den
Codevision AVR.
Gibt es einen Link, wo man den Code bekommen kann ?
Gruss
- bin übrigens neu hier
ich hoffe mal es meldet sich noch jemand....
Hallo euch allen, das ist ja ne echt starke leistung, was hier alle
vollbrahct haben.
leider bekomme ich keine der Display version zum laufen.
Ich suche eine Software für die Displays.
Nokia 6100 leider die EPSON version
S65
Nokia 3310
mit ATmega128
Nutzen möchte ich diese mit dem aktuellen WinAVR und einem ATmega128
kann mir jemand einen brauchbaren CODE zusenden?
Vielen DANK
martin
Martin J. (bluematrix)
alter, du nervst langsam. Wie wärs mit selber schreiben oder mindesten
googlen ?
Und nicht alle alte threads hier ausgraben. Das ist schon dein
mindestens 10tes posting.
na irgendwer muss doch mal ncoh was ordentlich es haben ...
ist das nun nen forum wo man sich gegenseitigt hilft oder bekommt man
hier immer nur blöde sprüche von solchen wie dir zu hören.
...
ach und nochwas...
es ist echt toll, dass hilfe immer gerne angenommen wird, aber wenn man
selber mal nach etwas fragt.. kommen nur hirnlose antworten.
aber wenn man selber mal nach etwas fragt ?
lese erst:
[http://www.mikrocontroller.net/articles/Netiquette]
Du hast in einigen threads immer wieder selbe mist geschrieben - obwohl
fett / rot steht "der Originalbeitrag ist mehr als 6 Monate alt".
Öffne einfach neues thread, beschreib dein problem und dann wird jemand
schon helfen können, alte leichen ausgraben ist hier nicht willkommen.
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 zusammen,
ich habe mich in meinem Weihnachtsurlaub daran gemacht, die libglcd
zusammen mit einem Octopus (AT90CAN128) von EmbeddedProjects ans Laufen
zu bekommen. Um den gängigen HW-Problemen aus dem Wege zu gehen, habe
ich mir ein Trägerboard gebastelt, das die HW mit 3,3V versorgt. Das
Display ist über den Display3000-Adapter angeschlossen (der nicht sauber
gelötet war und einige Probleme verursacht hat)
Prinzipiell hat die Inbetriebnahme mit dem guten alten Beispiel von
Thomas Pfeiffer recht schnell funktioniert. Mit der libglcd komme ich
bisher aber nur Schrittweise voran.
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 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....
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.
Das ist natürlich fein, denn jetzt sollte sich der Fehler finden lassen.
Also habe ich den Code zu glcdDisplayRect() angesehen und in glcd04.S
ist mir etwas Merkwürdiges aufgefallen:
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 war jetzt leider bereits ein bisschen länglich, aber ich hänge schon
seit vielen Stunden an der Sache und habe auch schon so einiges
weggekämft, da ist dann Historie einfach etwas länger.
@Hagen: Vielen Dank für die Lib. Das ist wirklich ein umfangreiches
Werk! Gerne steuere ich meine Erfahrungen bei, im Moment ist aber alles
im Hacker-Status. Wenn Du an dem Thema noch dran bist, wäre es super,
wenn Du mir an dem obigen Punkt einen Hinweis geben könntest.
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 Volkmar,
Volkmar schrieb:>> 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.
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. Ein Implementierung über das GPIO1-Register ist da auch nicht
schneller.
Darum habe ich dies wie folgt verändert: Ich habe ganz auf das
Deaktivieren der SPI in der ISR verzichtet. Diese hört nämlich von
alleine auf wenn das Byte draußen. In den Funktionen glcdDispSend() und
glcdDispRead() habe ich die SPI dann aktiviert. Das Warten geht dann
anstelle über
sbic LCD_SPCR, SPE
einfach mit
sbis LCD_PORT, LCD_CS
Achtung: Auch in glcd02.S wird einmal gewartet.
Hinzu kommt dann noch vor dem Ausgeben des D/C-Bits die SPI zu
deaktivieren und ebenso in glcdDispRead(). Um diese Blöcke müsste man
eigentlich noch ein cli/sei nehmen, da man sonst durch einen anderen
Interrupt der ebenfalls am PortB "schraubt" gestört werden könnnte (kein
atomare Operation!) Kostet dann aber auch wieder extra Code.
Ich bin der Meinung, dass die Lib dadurch schneller wurde. Da ich noch
ein paar Debugging-Ports drin habe, die ich in den nächsten tagen noch
brauchen werde, habe ich die Änderungen noch nicht gepostet. Wenn Du
interessiert bist, mache ich das Debugging kurz raus.
>>> 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 ;)>
Das war auch recht unschön gemacht. Zuerst den Reset setzten, im
Hintergrund die SPI aktivieren, dann warten, und dann erst den Reset
wieder wegnehmen finde ich ziemlich unschön beim Lesen des Codes. Hier
ist nun wirklich keine Performance gefragt. Auch hier kannst Du mal
meine Variante ansehen, wenn ich diese gepostet habe.
>> 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.
Wenn ich mir meine Fontausgaben ansehe, habe ich auch nur irgendwelche
komischen Muster. Da ist noch einiges an Arbeit notwendig. Evtl.
könntest Du den obigen Code nochmal genauer ansehen. Ich würde gerne
verstehen, was da läuft.
Hier mein Verständnis:
glcdSetAddr:
// Hier wird in Abhängigkeit von glcd_MemCtrl
// der übergebene X-Bereich dem Display entweder als
// X-Bereich (keine 90°-Drehung) oder als Y-Bereich übergeben.
// glcd_MemCtrl enthält einen Spiegel des Display-Registers
lds T0, glcd_MemCtrl // Display-Ausrichtung nach r26 (T0)
ldi T1, SET_X_ADDR // Kommando SET_X_ADDR nach r27 (T1)
sbrc T0, MEM_90 // Wenn Rotation um 90° gewählt, ...
inc T1 // ... Kommando auf SET_Y_ADDR wechseln
fcall glcdDispCommand // Kommando über SPI ausgeben
mov T1, X1 // 1. X-Koordinate nach r27 ...
fcall glcdDispData // ... und ausgeben. 9. Bit=0
mov T1, X2 // 2. X-Koordinate nach r27 ...
fcall glcdDispSend // ... und ausgeben. 9. Bit bleibt.
// So, und jetzt geht's an die Y-Koordintenübertragung.
// Warum hier jetzt wieder SET_X_ADDR genommen wird, ist mit
// unklar!
ldi T1, SET_X_ADDR // Kommando SET_X_ADDR nach r27
sbrs T0, MEM_90 // Wenn Rotation um 90° gewählt, ...
inc T1 // ... Kommando auf SET_Y_ADDR wechseln
fcall glcdDispCommand // Kommando über SPI ausgeben
mov T1, Y1 // 1. Y-Koordinate hinterher
fcall glcdDispData
mov T1, Y2 // 2. Y-Koordinate hinterher
fcall glcdDispSend
// So, und da ab jetzt viele Pixel kommen, dies dem Display ebenfalls
// mitteilen. Somit werden ab jetzt alle Daten ohne weiteres Kommando
// als Pixel interpretiert.
ldi T1, MEM_WRITE // Kommando MEM_WRITE nach r27...
fjmp glcdDispCommand // ... und ans Display senden.
.end
>> Hoffe das hilft erstmal.
Klar, vielen Dank! Toll, dass trotz den hohen alters des Threads noch
immer Leute an den Themen dran sind.
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 Volkmar,
Volkmar schrieb:> 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.
6 Instruktionen sind wirklich spitze! Ich hatte T0 und T1 auf den Stack
gelegt (2), dann das SREG gerettet (3), dann in+andi+out (6), dann das
SREG wieder hergestellt (7), T1 und T0 zurück vom Stack (9). Das wäre
dann der Ersatz für das "cbi LCD_SPCR, SPE" (1).
Könntest Du Deine Lösung mal posten? Evtl hast Du ja auch eine bessere
Lösung für die Änderungen in glcdDispSend() (2 mal in+andi+out, push T0
und pop T0)
Ansonsten rennt mein Display jetzt. Ich hatte in glcdDispSend() das
Register T0 verwendet und das hat dann so einiges zerstört. Jetzt lege
ich T0 einfach auf dem Stack ab. Kostet zwar 2 Zyklen, ich habe aber
keine andere Möglichkeit dafür gefunden.
Interessanter Weise musste ich noch das RGB-Flag für das
Memctrl-Kommando herausnehmen, sonst sind bei mir Blau und Rot
vertauscht.
Ich habe meine Änderungen angehängt. 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.
Ich denke es macht Sinn, mit den Änderungen ein neues Archiv zu
erstellen (Version 2.3) und die Doku anzupassen. Evtl. möchte das ja
auch Hagen machen, ich habe aber keine Ahnung ob er überhaupt noch aktiv
ist bzw. noch Interesse hat.
Noch offen:
1. Da die in+andi+out-Kommandos nicht mehr atomar sind, müsste man
eigentlich während der Ausführung die Interrupts sperren.
2. Da die SPI jetzt nach dem Interrupt aktiv bleibt, müsste man eine
Funktion hinzufügen, die die SPI stoppt (SPE<-0) und dann ggf. noch
wartet, bis die letzte Übertragung abgeschlossen ist. Irgendetwas wie
void glcdReleaseSpi().
Ralph
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:
Dazu muß dies aber auch noch beim Setzen der Farben angegeben werden:
1
ldi P3L, 1 // Read from flash
2
ldi P3H, 0
3
rcall glcdDisplaySetColors
Für die ISR habe ich nur das was im Listing steht (da ich ja die Makros
verwende):
1
00013966 <__vector_20>:
2
13966: a4 9a sbi 0x14, 4 ; 20
3
13968: 0f 93 push r16
4
1396a: 0c b5 in r16, 0x2c ; 44
5
1396c: 0f 7b andi r16, 0xBF ; 191
6
1396e: 0c bd out 0x2c, r16 ; 44
7
13970: 0f 91 pop r16
8
13972: 18 95 reti
BTW: Ich gehe davon aus, das Hagen hier nichts mehr dran macht (hatte
mal sowas gelesen). Dennoch noch mal Danke an ihn (auch für die Hilfe
damals!).
Volkmar
>BTW: Ich gehe davon aus, das Hagen hier nichts mehr dran macht (hatte>mal sowas gelesen). Dennoch noch mal Danke an ihn (auch für die Hilfe>damals!).
naja ist ja auch schon wieder par Jahre her und zudem gabs danach das
bessere S65 Display.
Gruß Hagen
> naja ist ja auch schon wieder par Jahre her und zudem gabs danach das> bessere S65 Display.
Wie man sieht, gibt es aber dennoch weitere Verwendung für das betagte
6100-Display ;)
> apropos S65......> Hat irgendjemand noch welche davon ?> Ich find nirgends ne Bezugsquelle und brauch etwa 5 Stück,
Das gehört nun wirklich nicht hierher! (Das 6100 gibt es noch...)
Volkmar
@Volkmar
Man möge mir verzeihen hier eine Frage gestellt zu haben die sich auf
etwas ähnliches bezieht.
Wobei ich nicht ganz nachvollziehen kann weshalb der Kommentar, dass das
S65 das bessere Display sei hierher gehlrt, die Frage nach einer
möglichen Bezugsquelle jedoch nicht.
Naja...
Sven
Hallo Volkmar, hallo Hagen,
war ein paar Tage abgetaucht. Hatte eine Menge Zeugs um die Ohren :o.
Jetzt habe ich hoffentlich wieder etwas mehr Zeit.
Ja, das 6100er Display gibt es noch. Z.B. hier für 8€:
http://www.centralshop24.com/nokia-6610-7210-display.html
Die Änderung an der ISR gehen so wie sie Volkmar gemacht hat leider
nicht gut, da man auch noch das SFR retten muss wenn in einem Register
ein "and" ausführt. Hierzu muss ein weiteres Register auf den Stack
gerettet werden um dann das SFR in diesem Register zwischenzuspeichern.
Das macht dann 4 Zyklen mehr für die ISR. Volkmar, du musst eigentlich
ziemliche Schwierigkeiten mit seiner SW haben wenn Du diesen Fehler in
Deinem Code drin hast.
Darum habe ich in meiner ISR ganz auf das Abschalten der SPI in der ISR
verzichtet. Dies hat dann schließlich zu meinen etwas massiveren
Änderungen geführt.
Wenn Hagen den Code übernimmt wie ich ihn gemacht habe, sollte dies auch
in weiten Teilen für die "kleinen" Controller funktionieren. Dazu müsste
man das Deaktivieren der SPI allerdings noch in die Funktion
glcdDispSend() verlegen. (Würde ich machen, nur Hagen müsste dies dann
eben prüfen). Damit sollten dann einige #if-Anweisungen verschwunden
sein.
In glcdDispSend() musste ich noch das Register T0 retten, da ich dies
benötige, um auf die SPI zuzugreifen. Bei Hagen war T0 in dieser
Funktion unverändert und andere Funktionen gehen davon aus, dass dem
auch tatsächlich so ist. Volkmar, dies dürfte Dir ebenfalls auch
Schwierigkeiten bereiten.
Die Sache mit den Farben konnte sehr elegant in der Initialisierung
lösen. Da wird nämlich explizit das Bit MEM_RGB gesetzt. Dieses schaltet
von RGB auf BGR um. Und dieses Bit braucht mein Display einfach nicht.
Ich denke meine Lösungen sind nicht so schlecht. Wäre doch schön, wenn
es nochmal eine neue Version der libglcd geben würde, zumal die Displays
zur Zeit zum Schleuderpreis zu haben sind.
Ralph
@Hagen,
schade. Ist es für Dich i.O. wenn ich mit meinen Änderungen eine Version
2.3 zusammenstelle und hier anbiete?
@Andere
Gibt es sonst jemandem der gerade aktiv an dem Display dran ist und mit
den "kleinen" Atmegas arbeitet?
Ralph
>schade. Ist es für Dich i.O. wenn ich mit meinen Änderungen eine Version>2.3 zusammenstelle und hier anbiete?
Natürlich ist das ok, bitte tue dir keinerlei Zwang an, davon lebt freie
Software.
Gruß Hagen
Hallo,
so, wie versprochen hier meine Version der libglcd. Hat noch ein
bisschen gedauert, da ich meinen Octopus erst man auf 16MHz trimmen
musste und nach wie vor ziemlich unter Last bin.
Ich habe an der Lib folgendes geändert:
- Optimized glcdDisplayInit(). I hope it works for everybody.
- Support for RGB and BGR memory color ordering.
- Changes to support controllers with SPI-Registers outside the lower
I/O
addresses (up to 0x1f).
- Renamed macro XTAL into F_CPU. F_CPU is commonly used inside avr-libc.
- Corrected bugs that cause compile errors with recent avr-gcc. (gcc-
Version 4.3.)
- Corrected reading of display registers !CS was set inactive after
sending
a command. This aborted the read command at display and no data was
sent.
Now the command sequence is done manually without SPI use. In order
to solve this I also had to change the glcdDisplayRead() function.
WARNING: glcdDisplayRead() will now take the real amount of bits sent
from display not the amount + 1.
- Added output of display ID in test program. Perhaps this enables the
library to detect the display type in future.
- Optimized glcdDisplayOn(). A short wait before the request of status
register helps my display to start.
ACHTUNG: Die Funktion glcdDisplayRead() akzeptiert jetzt 2 Parameter und
die Anzahl an zu lesenden Bits wird exakt angegeben (Für 32 Bit
wird jetzt 32 angegeben und NICHT mehr 33)
Ich hoffe diese Version hilft an einigen Stellen die Problemchen zu
beheben. Bitte gebt mir Rückmeldungen zu der neuen Version! Ich konnte
diese leider nicht mit der (neuen) Option SPI_IN_LOWER_IO_REGS prüfen.
Wenn die neue Version bei Euch so tut wie bei mir, dann würde ich diese
Version gerne als 2.3 herausgeben.
Gruß
Ralph
Hallo,
ich kann gerne Deine Version testen, es wird aber noch einige Tage
dauern. Aber ich denke, so eilig ist es mit einer Version 2.3 ja auch
nicht. Desweiteren bin ich gerade dabei die Performance bei den
Schriften zu erhöhen (auf Kosten von Speicher). Ich hatte mir dazu
überlegt einen Compile-Switch einzubauen, mit dem man zwischen beiden
Varianten umschalten kann. Sowas könnte doch auch noch mit rein (ist
aber noch nicht fertig).
Gruß
Volkmar
Hallo Volkmar,
klingt prima. Ich habe mich bisher noch nicht über die Font-Geschichten
gekümmert. Wenn Du hier ein paar gute Ideen hast, kommt die lib
tatsächlich deutlich voran.
Achte aber auf die Register, die Du zusätzlich verwendest. Man muss
immer prüfen, welche Register von aufrufenden Funktionen noch genutzt
sind.
Grüße
Ralph
@Volkmar:
wie gedenkst Du die Performance zu erhöhen ?
Die innerste Schleife sollte in durchschnittlich 16 takten das nächste
Datenbyte an/für das SPI gesendet/berechnet haben. Das SPI benötigt bei
vollem Datendurchsatz exakt 16 MCU Takte zum raussenden. Die SPI Routine
wurde so programmiert das sie sofort zum "Aufrufer" zurückkehrt. Alles
in Allem sollte also jetzt schon die innerste Schleife der
Fontzeichenroutine, die übrigens mit ca. 90% die Hauptarbeit macht,
optimal schnell sein. Eine weitere Beschleunigung dieser Schleife würde
nur bedeuten das diese Schleife Waitstates beim Warten auf das SPI
einlegen würde.
Optimiert man den äußersten Part der Fontroutine, also zb. die
Berechungen zum ASCII->Bitmap wandeln dann beträfe das eben nur die
letzten 10-20%.
Das ist übrigens der Grund warum ein komprimierter Font effizienter
dargestellt werden kann als ein unkomprimierter, obwohl der
Berechnungsaufwand durch die Dekomprimierung eigentlich höher ist.
In der ASM Version der Nokia Lib. sehe ich kein Optimierungspotential
mehr da ich dort schon in meinen Augen das Optimum rausgeholt habe.
Falls du also gedenkst den Font bei der Selektion vom FLASH in den SRAM
zu entpacken dann wird das letzendlich nur Resourcenverschwendung sein
und nichts an der jetzigen Performance verbessern. Deswegen meine Frage
an Dich zum Wie.
Der Flaschenhals ist letzendlich die SPI Hardware. Es gilt immer die
Regel 16 MCU Takte sind Zeit bis ein Byte rausgeschoben wurde. Somit
verbleiben bei clevrer Programmierung, eg. im Hintergrund des SPI
Tranfser läuft die Software weiter, ca. 14 Takte für Berechnungen. Die
jetzige innerste Schleife benötigt nicht mehr als diese 14 Takte. Ergo:
schneller als 8MByte bei 16MHz Takt ist nicht drinnen. Wenn die
Fontroutine mit 8MBytes Pixel setzt ist das Limit erreicht. Und dieses
Limit ist fast erreicht mit der aktuellen Version.
Gruß Hagen
Hallo Hagen,
dem kann ich nur bedingt zustimmen. Tatsächlich werden von den 16 zur
Verfügung stehenden CPU-Zyklen bereits 9 für die Verarbeitung des
Interrupts benötigt. Da bleiben dann nur noch 7. Selbst wenn man einen
Controller hat, auf dem die SPI in den unteren I/O Registern gemappt
ist, benötigt man fast das dreifache (20 Zyklen).
Ich habe darum auch bereits darüber nachgedacht, auf den Interrupt zu
verzichten, da die ISR ohnehin nichts Bedeutendes macht. Auch das
permanente Setzen und wieder Löschen des !CS-Signals könnte man sich
dann sparen, wodurch das ganze nochmals beschleunigt werden würde (und
die Probleme beim Lesen vom Display wären ebenfalls weg). Das spart dann
durchaus 10-Zyklen (ca. 600ns) pro gesendetem Byte. Zur Zeit werden in
glcdDispData() 20 Zyklen pro Byte benötigt. Zusammen mit der ISR 29.
Wenn man 10 spart ist das nicht unerheblich!
Um das zu machen, könnte man einfach das SPIF Flag direkt im SPI
Register abfragen. Dieses wird nach einer Anfrage gelöscht, sobald das
nächste Byte gesendet wird. Sollte also gehen. Man könnte allerdings
einmalig in der Initialisierung ein Dummy-Byte senden, um das Flag
initial gesetzt zu bekommen.
Alternativ könnte man die Zeit auch einfach als vergangen ansehen. 16
Zyklen sind ruck zuck vorbei. Selbst wenn man auf die ISR verzichtet und
das Warten auf die SPI in glcdDispData() herausnimmt, bleiben noch 17
Zyklen übrig. Und das ist immerhin einer mehr als die SPI braucht, um
das Byte zu senden!
Was hältst Du davon?
Grüße
Ralph
Hallo,
dann hätte ich gleich noch einen...
Ich habe mir 10 Nokia-Display auf Vorrat bestellt, beim selben
Hersteller wie meine ersten beiden. Die Displays kamen heute an. 7 waren
Baugleich (braune Folie, gehen), 3 hatten eine grüne Folie und gehen
nicht :(
Ich denke mal da ist jetzt der Epson-Controller drin. Hat noch
irgendeiner einen Testcode (am besten in C, geht schneller) für die
Epson-Controller?
Gruß
Ralph
@Hagen:
Da ich unterwegs bin nur in wenigen Worten. Es gibt einen Teil bei dem
die Position der eigentlichen Font-Daten bestimmt wird. Diese Routine
addiert jedesmal alles vorherigen Zeichenbreiten. Dieser Teil kostet
gerade bei hinteren Zeichen viel Zeit. Das würde ich einmalig beim
Festlegen des Fonts im RAM ablegen, kostet halt 512 Byte. Flash wäre
auch nicht schlecht, aber dafür müsste ich den Font-Editor ändern, was
ich nicht kann.
Gruß Volkmar
Nochmal @Hagen,
Von den 20 Zyklen für glcdDispData() sind 9 zwischen SPI disable und SPI
start. Diese darf man also nicht zählen. Somit geht es ohne Warten auf
die SPI doch nicht. Ich eine Version gemacht, in der ich auf die ISR
verzichte. 6 NOPs in glcdDispSend() genügen, damit die Bibliothek wieder
läuft.
Dabei ist mir aufgefallen, dass ich einen Fehler in der Initialisierung
eingebaut hatte. Das SPI2X Flag wurde nicht korrekt gesetzt. Ich hatte
zunächst 22 NOP benötigt.
Entfallen sind nun die ISR (9 Zyklen) und das Warten auf das löschen des
CS-Signals (mind. 2 Zyklen, wenn Loop aktiv + 3 Zyklen/Loop). Es
entfallen also mindestens 11 Zyklen. Also in diesem schnellen Hack sind
bereits 5 Zyklen gespart.
Gruß
Ralph
Hallo,
jetzt habe ich noch ein bisschen experimentiert und mit dem Testprogramm
Laufzeiten ermittelt:
Laufzeit Test mit ISR: ca. 70 Sekunden
Laufzeit ohne ISR, warten auf SPIF-Bit: 59s
Laufzeit ohne ISR, NOP-Warten: 54s
Jetzt könnte man noch das toggeln des CS-Signals einsparen, dann wäre
man wohl unter 50s. Auf die Schnelle hat dies aber dann doch nicht
funktioniert. Durch das Toggeln des CS-Signals wird eben die Adresslogik
im Display immer wieder in den Ausgangszustand versetzt. Das schein wohl
notwendig zu sein zu sein.
Interessant finde ich, dass die NOP-Lösung die schnellste ist. Ich
erkläre dies damit, dass wenn die Wait-Loop einmal zurückspringt, mehr
als die 4 noch übrigen NOPs benötigt werden. Und dies scheint wohl öfter
der Fall zu sein.
Angehängt die dafür geänderten Dateien, auf Basis meiner Quellen vom
27.01.11. Da ich jetzt ziemlich viele #ifdef Präprozessordirektiven drin
habe, sollte man sich besser ganz für oder ganz gegen die ISRs
entscheiden. Das mit dem NOP-Timing sollte optional bleiben, falls
jemand die SPI mit einem kleineren Takt betreiben möchte.
Bitte gebt zu diesem Thema Eure Meinungen ab!
Gruß
Ralph
P.S.: Hat noch jemand den Code für die Epson-Controller?
Hallo,
das CS-Toggeln habe ich jetzt auch noch herausoptimiert. Ohne das
Toggeln bekommt aber die Adresslogik im Display keine Resets mehr. Wenn
also einmal schief gelaufen ist dürfte diese dann für immer hängen. Nach
einem Lesen muss in jedem Fall das CS getoggelt werden. Das war gestern
noch die Schwiegigkeit.
Beim Benchmark konnten so nochmals 5s geholt werden. Das Testprogram
benötigt für den ersten Durchlauf jetzt nur noch 49s. Pro Instruktion in
glcdDispSend() werden also ca. 3s beim Benchmark eingespart. Bevoe ich
gestartet habe hat das Testprogramm noch 70s benötigt.
Dafür gibt es jetzt ein weiters #define. Die Übersichtlichkeit ist damit
völlig futsch. Da kommt #if nach dem anderen. Wenn man diesen Code in 6
Wochen nochmals ansieht versteht man nichts mehr :o
Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der
neuen Optionen sollten optional bleiben?
Gruß
Ralph
Hallo,
Ralph Scharpf schrieb:> Interessant finde ich, dass die NOP-Lösung die schnellste ist. Ich> erkläre dies damit, dass wenn die Wait-Loop einmal zurückspringt, mehr> als die 4 noch übrigen NOPs benötigt werden. Und dies scheint wohl öfter> der Fall zu sein.
Naja, das läßt sich wie folgt erklären: Abgesehen von Interrupts, die
zwischendurch auftauchen können, gibt es ja immer eine festen Ablauf im
µC. Und dann entsteht immer der gleiche Zeitversatz. Mit den NOPs kannst
Du es Takt-Genau einstellen, mit der Schleife ist das Raster halt größer
als 1.
Ralph Scharpf schrieb:> Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der> neuen Optionen sollten optional bleiben?
Im Moment (ohne in die Sourcen zu schauen) habe ich den Überblick etwas
verloren ;) Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am
SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines
glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders
verwendet werden kann.
Ralph Scharpf schrieb:> Das mit dem NOP-Timing sollte optional bleiben, falls> jemand die SPI mit einem kleineren Takt betreiben möchte.
Hier stimme ich auf jeden Fall zu. Eventuell könnte man überlegen noch
eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option
verwendet werden soll und der SPI-Takt nicht auf das Schnellste
eingestellt ist.
Gruß
Volkmar
Hallo,
Volkmar schrieb:> Ralph Scharpf schrieb:>> Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der>> neuen Optionen sollten optional bleiben?>> Im Moment (ohne in die Sourcen zu schauen) habe ich den Überblick etwas> verloren ;)
Ok, kurze Erklärung: Es gibt zurzeit 3 neue Makros in glcd.inc. Diese
sind:
1. USE_ISR
Wenn das Makro gesetzt ist, wir die SPI-ISR wie ursprünglich von Hagen
umgesetzt verwendet. Wenn diese Makro gesetzt ist, sind die anderen
beiden folgenden ohne Funktion bzw. sollten nicht aktiviert werden.
Laufzeit des Testprogramms mit ISR: 70s, ohne ISR: 59s
2. SPI_NOP_WAIT
Wartet nicht in einer Loop bis die SPI fertig ist, sondern verwendet ein
paar NOPs um die überschüssige Zeit zu verbrauchen. Laufzeit des
Testprogramms mit dieser Einstellung: 54s
3. TOGGLE_CS
Jetzt hat man noch die Möglichkeit, die CS-Leitung nicht nach jeder
Übertragung zu deaktivieren und am Beginn wieder zu aktivieren, sondern
das CS einfach stehen zu lassen. Das Spart dann nochmals 2 Zyklen.
Laufzeit des Testprogramms mit dieser Einstellung: 49s
> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders> verwendet werden kann.
Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein
anderes Device wechseln soll, wird in dieser Funktion einfach das CS
weggenommen. Hinterher kann man dann wieder durch einen weiteren Call
das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte
man dann auch die SPI-Einstellungen wieder herstellen, falls das andere
Device hier z.B. einen kleineren Takt verlangt.
Hast Du irgendwelche sonstigen Abhängigkeiten. Bisher wurde ja eine ISR
verwendet. Hattest diese dann angepasst? Ansonsten sollte es doch ohne
ISR eigentlich einfacher sein, noch ein weiteres Device anzuschließen.
>> Ralph Scharpf schrieb:>> Das mit dem NOP-Timing sollte optional bleiben, falls>> jemand die SPI mit einem kleineren Takt betreiben möchte.>> Hier stimme ich auf jeden Fall zu. Eventuell könnte man überlegen noch> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option> verwendet werden soll und der SPI-Takt nicht auf das Schnellste> eingestellt ist.
So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum
Aktivieren bei Bedarf und per Default die sicheren Einstellungen.
Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu
verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden.
Die anderen Optionen würde ich drin lassen. Wenn man ein zickiges
Display hat ist es gut, wenn CS toggelt und SPI_NOP_WAIT ist während
einer Inbetriebnahme auch nicht das was man haben möchte.
Gruß
Ralph
Hallo,
kurzes Update von mir.
Ralph Scharpf schrieb:>> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am>> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines>> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders>> verwendet werden kann.>> Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein> anderes Device wechseln soll, wird in dieser Funktion einfach das CS> weggenommen. Hinterher kann man dann wieder durch einen weiteren Call> das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte> man dann auch die SPI-Einstellungen wieder herstellen, falls das andere> Device hier z.B. einen kleineren Takt verlangt.
Ja, ich denke mit einem separaten Aufruf wäre das gut zu lösen. In
meinem Projekt mußten die SPI-Einstellungen (z.B. die Taktlage) zwischen
den beiden Devices gewechselt werden.
Ralph Scharpf schrieb:>> Eventuell könnte man überlegen noch>> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option>> verwendet werden soll und der SPI-Takt nicht auf das Schnellste>> eingestellt ist.>> So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum> Aktivieren bei Bedarf und per Default die sicheren Einstellungen.
Man könnte die SPI-Frequenz in ein #define packen und dann anhand der
defines den Compiler-Fehler auswerfen. Sollte nicht aufwändig sein.
Ralph Scharpf schrieb:> Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu> verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden.
Die ISR sehe ich auch nicht als notwendig an. Von mir aus kann sie raus.
Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen
hast Du 'cnt' auf 1 gesetzt, oder? Mit meiner Lib (Deine konnte ich noch
nicht testen, siehe unten) komme ich sonst da überhaupt nicht hin, und
das könnte ich mir nicht anders erklären.
Ich denke, es macht Sinn das Testprogramm etwas zu erweitern und eine
kleine Zeitmessung einzubauen. Ebenso sollte man über die Gewichtung
nachdenken, die Rechtecke haben im Moment einen ziemlich hohen Anteil,
die Linien würde ich höher als jetzt gewichten, Ellipsen sind OK, die
werden bestimmt nur selten benutzt. Texte sind total unterrepräsentiert.
Und nun noch zu dem Punkt, warum Deine Lib bei mir bisher nicht läuft:
Aufgrund vorgegebener HW liegen Reset und CS nicht am selben Port wie
SCL und SDA. D.h. ich muß hier noch die Routinen anpassen, damit diese
Werte auf anderen Ports geschrieben werden können.
Damit leidet die Übersichtlichkeit noch mehr :(
Gruß Volkmar
Hallo Volkmar,
Volkmar schrieb:> Hallo,>> kurzes Update von mir.>> Ralph Scharpf schrieb:>>> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am>>> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines>>> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders>>> verwendet werden kann.>>>> Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein>> anderes Device wechseln soll, wird in dieser Funktion einfach das CS>> weggenommen. Hinterher kann man dann wieder durch einen weiteren Call>> das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte>> man dann auch die SPI-Einstellungen wieder herstellen, falls das andere>> Device hier z.B. einen kleineren Takt verlangt.>> Ja, ich denke mit einem separaten Aufruf wäre das gut zu lösen. In> meinem Projekt mußten die SPI-Einstellungen (z.B. die Taktlage) zwischen> den beiden Devices gewechselt werden.
Ich mache hierzu einen Vorschlag!
>> Ralph Scharpf schrieb:>>> Eventuell könnte man überlegen noch>>> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option>>> verwendet werden soll und der SPI-Takt nicht auf das Schnellste>>> eingestellt ist.>>>> So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum>> Aktivieren bei Bedarf und per Default die sicheren Einstellungen.>> Man könnte die SPI-Frequenz in ein #define packen und dann anhand der> defines den Compiler-Fehler auswerfen. Sollte nicht aufwändig sein.
Man hat eben in der SPI mehrere Register die berücksichtigt werden
müssen. Letztlich muss eben das SI2X gesetzt werden und der Clock auf
Maximum stehen. Aber das sind Register-Werte. Die Frequenz selbst ist
egal. Es kommt nur auf den Teiler an. Wenn hier jemand einfach mal
andere Werte setzt um evtl. Probleme zu beheben geht es eben schief.
Darum würde ich darauf verzichten.
>> Ralph Scharpf schrieb:>> Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu>> verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden.>> Die ISR sehe ich auch nicht als notwendig an. Von mir aus kann sie raus.
Ok, auch das werde ich machen...
>> Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen> hast Du 'cnt' auf 1 gesetzt, oder?
Ich habe im Testprogramm noch eine Ausgabe der Display-ID drin. Danach
geht der Test los. Ich messe ab dem Beginn mit den Rechtecken bis zum
Ende der laufenden Steifen, also bevor das Display in die 4 Teile
geteilt wird. Hinter diesem letzten Test scheint sich ein Delay zu
befinden. Darum habe ich diesen Teil nicht mitgemessen.
>Mit meiner Lib (Deine konnte ich noch> nicht testen, siehe unten) komme ich sonst da überhaupt nicht hin, und> das könnte ich mir nicht anders erklären.> Ich denke, es macht Sinn das Testprogramm etwas zu erweitern und eine> kleine Zeitmessung einzubauen. Ebenso sollte man über die Gewichtung> nachdenken, die Rechtecke haben im Moment einen ziemlich hohen Anteil,> die Linien würde ich höher als jetzt gewichten, Ellipsen sind OK, die> werden bestimmt nur selten benutzt. Texte sind total unterrepräsentiert.
Stimmt! Hinterher wäre eine Zusammenfassung auf dem Display auch spitze.
10s anzeigen, dann weitermachen.
>> Und nun noch zu dem Punkt, warum Deine Lib bei mir bisher nicht läuft:> Aufgrund vorgegebener HW liegen Reset und CS nicht am selben Port wie> SCL und SDA. D.h. ich muß hier noch die Routinen anpassen, damit diese> Werte auf anderen Ports geschrieben werden können.> Damit leidet die Übersichtlichkeit noch mehr :(
Da schlage ich vor, das eine Makro für LCD_PORT durch 3 zu ersetzten.
Die SPI-Pins dürften ja immer am gleichen Port hängen. Wenn Du möchtest,
kann ich dies auch gleich machen. Ich schlage die Makros vor
LCD_SPI_PORT, LCD_CS_PORT und LCD_RES_PORT. Sollte an der
Übersichtlichkeit nicht viel ändern. Kann man durch suchen und ersetzten
machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".
Gruß Ralph
Ralph Scharpf schrieb:>> Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen>> hast Du 'cnt' auf 1 gesetzt, oder?>> Ich habe im Testprogramm noch eine Ausgabe der Display-ID drin. Danach> geht der Test los. Ich messe ab dem Beginn mit den Rechtecken bis zum> Ende der laufenden Steifen, also bevor das Display in die 4 Teile> geteilt wird. Hinter diesem letzten Test scheint sich ein Delay zu> befinden. Darum habe ich diesen Teil nicht mitgemessen.
OK, ich habe zwischenzeitlich einen Fehler bei mir gefunden. Nun stimmen
die Durchläufe.
Ralph Scharpf schrieb:> Stimmt! Hinterher wäre eine Zusammenfassung auf dem Display auch spitze.> 10s anzeigen, dann weitermachen.
Ich habe mal einen Benchmark erstellt (in test.c), die Zahlen am Ende
werden pro Disziplin angezeigt. Es sind die Anzahl der Takte geteilt
durch 64. Die Werte sind reproduzierbar.
Ralph Scharpf schrieb:> kann man durch suchen und ersetzten> machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".
Das Problem hierbei ist, daß die Ports nicht alle direkt
bit-adressierbar sind und somit auch die in/out-Konstruktion benötigt
wird. Habe ich ja soweit für mich schon umgesetzt.
Anbei ein Satz der Änderungen, ich hoffe ich habe alle drin ;) Bei der
Test.c habe ich noch weiter Rücksicht auf die HW nehmen müssen (wie zB.
Hintergrundbeleuchtung einschalten, Ausschalten des Gerätes nach Ablauf
des Benchmarks). Insgesamt ist es sicherlich auch nicht optimal/schön
programmiert (zu wenig Zeit).
Was mir auch dabei noch aufgefallen war, bei mir passte die Funktion für
die Orientierung nicht. Die hatte ich angepaßt, scheinbar gibt es hier
zwei verschiedene Typen (habe ein braunes Display). Habe die Änderungen
in glcd03.S eingetragen.
Gruß
Volkmar
Hallo Volkmar,
ich hatte inzwischen einige Probleme mit meinen Änderungen. Zunächst
hatte ich nur veruscht, die Änderungen an glcdDisplayOff() zu prüfen,
was das ganze Display durcheinandergebracht hat. Dann habe ich weiter
experimentiert und habe alle möglichen Störungen auch in anderen
Routinen entdeckt. Mein Ergebnis: Das Toggeln der CS-Leitung wird
einfach doch benötigt!
Volkmar schrieb:> Ich habe mal einen Benchmark erstellt (in test.c), die Zahlen am Ende> werden pro Disziplin angezeigt. Es sind die Anzahl der Takte geteilt> durch 64. Die Werte sind reproduzierbar.
Ich kam noch nicht dazu, mir die Sache genau anzusehen. Aber die Ausgabe
ist recht umstandlich. Ich hatte dies zuvor auch so gemacht, inzwischen
bin ich aber auf itoa und ltoa gestoßen. Siehe
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html#ga1d4c7b84110553544081a69a0fc49c52>> Ralph Scharpf schrieb:>> kann man durch suchen und ersetzten>> machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".>> Das Problem hierbei ist, daß die Ports nicht alle direkt> bit-adressierbar sind und somit auch die in/out-Konstruktion benötigt> wird. Habe ich ja soweit für mich schon umgesetzt.
Du liegst doch mit den Ports auf PortG. Dieser ist bein meinem
Controller noch in den unteren Adressen (PING@0x12, DDRG@0x13,
PORTG@0x14). Sind die Port-Register nicht immer in die unteren Adressen
gemappt?
>> Anbei ein Satz der Änderungen, ich hoffe ich habe alle drin ;) Bei der> Test.c habe ich noch weiter Rücksicht auf die HW nehmen müssen (wie zB.> Hintergrundbeleuchtung einschalten, Ausschalten des Gerätes nach Ablauf> des Benchmarks). Insgesamt ist es sicherlich auch nicht optimal/schön> programmiert (zu wenig Zeit).
Wie gesagt, bin noch am Zusammenführen mit meinen letzten Änderungen.
Melde mich wenn ich fertig bin. Mache dann auch nochmal ein Archiv.
>> Was mir auch dabei noch aufgefallen war, bei mir passte die Funktion für> die Orientierung nicht. Die hatte ich angepaßt, scheinbar gibt es hier> zwei verschiedene Typen (habe ein braunes Display). Habe die Änderungen> in glcd03.S eingetragen.
Bei mit gingen nur die Orientierungen 90° und 270°. Mit deinen
Eintstellungen in glcd.inc geht das jetzt! glcd03.S muss ich noch
prüfen. Kommt auch morgen dran...
Gruß
Ralph
Ralph Scharpf schrieb:> Ich kam noch nicht dazu, mir die Sache genau anzusehen. Aber die Ausgabe> ist recht umstandlich. Ich hatte dies zuvor auch so gemacht,
Deswegen hatte ich ja vorher geschrieben: "Insgesamt ist es sicherlich
auch nicht optimal/schön programmiert (zu wenig Zeit).". ;)
Hatte halt Deine Zeilen mit Copy/Paste übernommen. Eigentlich nutze ich
dafür gerne dir printf-Varianten ...
Ralph Scharpf schrieb:> Du liegst doch mit den Ports auf PortG. Dieser ist bein meinem> Controller noch in den unteren Adressen (PING@0x12, DDRG@0x13,> PORTG@0x14).
Hmmm, irgendwie hast Du recht. Frag mich nicht, warum ich das so
gemacht/gedacht habe. Scheint doch zu gehen ;)
Da ich leider meinen (eher fliegenden) Aufbau erneuern muß, wird es nun
einige Tage dauern, bis ich daran weitermachen kann.
Gruß
Volkmar