Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien:minor changes: - Atmega128 support hinzugefügt - Test-DEMO geändert Gruß Hagen PS: danke für die viele Verbesserungsvorschläge eurerseits :)
Datum:
Kannst du mal ein paar neue Bilder posten ? Ich meine von irgendwelchen Displayspielereien :-D in Farbe ?
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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.
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien: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
Datum:
... 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
Datum:
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
Datum:
Ja sind es... aber ungeschlagen günstig im vergleich zu Handy Displays. http://www.lcd-module.de/giff/grafik/p128-6n7.jpg (30) Damit es bei den Handydisplays Sinn macht müsste schon das Display eines P800 / P900 herhalten ... (dann gleich mit Touchpanel-Auswerrtung g) http://homepage.hispeed.ch/p800_info/p800/pics/Angepasst.JPG Gruß Kofi
Datum:
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
Datum:
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
Datum:
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
Datum:
> 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
Datum:
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
Datum:
Hallo, hat schon jemand versucht, den C Code umzuschreiben für das 3510i? Wäre sehr von Interesse. mfG Matthias
Datum:
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
Datum:
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
Datum:
Hallo hat jemand Datenblätter für Nokia 6600 oder P800 Display? Gruß, oleg
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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)
Datum:
@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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien: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
Datum:
@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
Datum:
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
Datum:
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
Datum:
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
Datum:
Volkmar, lass dir Zeit es eilt nicht, bin eh nächste Woche in London. Gruß Hagen
Datum:
Kurze Rückmeldung: Mit den Änderungen in pm_lo8() etc. funktioniert es an dieser Stelle. Der Rest kommt dann wie besprochen später. Volkmar
Datum:
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...
Datum:
Angehängte Dateien:Da gabs noch einen Fehler, probier mal den aus dem Anhang aus. Gruß Hagen
Datum:
Angehängte Dateien:Stimmt, jetzt müsste es aber definitiv funktionieren. Leider kann ich nicht mit deinen Daten austesten ;) Gruß hagen
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
Hallo Hagen, vielen Dank für die prompte Bearbeitung. Auf den ersten Test sieht das alles gut aus. Volkmar
Datum:
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
Datum:
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...
Datum:
Angehängte Dateien: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
Datum:
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.
Datum:
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
Datum:
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
Datum:
@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.
Datum:
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?
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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!
Datum:
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?
Datum:
@smartie Da mußt Du wohl alle Sourcen an CodeVision anpassen, dann kannst Du die Lib auch unter CodeVision verwenden. Volkmar
Datum:
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.
Datum:
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
Datum:
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.
Datum:
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?
Datum:
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
Datum:
"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?
Datum:
das kannst du dir doch selber kompilieren, so schwer ist das nun echt nicht.
Datum:
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
Datum:
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.
Datum:
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
Datum:
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);
}
Datum:
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
Datum:
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.
Datum:
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
Datum:
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
Datum:
@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
Datum:
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
Datum:
Alles klar. Vielen Dank für die schnelle Hilfe. Echt ne super LIB von dir. Nur weiter so....
Datum:
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?
Datum:
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.
Datum:
> 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
Datum:
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
Datum:
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
Datum:
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
Datum:
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.
Datum:
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
Datum:
@volkmar wo gibt es den test-code für den ATMEGA-128 ? sind dort die Anschlüsse noch gleich, oder ist Reset anders verdrahtet? gruss christian
Datum:
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
Datum:
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
Datum:
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
Datum:
@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é
Datum:
Hallo Andre das Display verträgt laut Datenblatt maximal 3,6 V. Das gilt auch für die digitalen Eingänge. MartinK
Datum:
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é
Datum:
Hi zusammen! Kann ich die Library auch mit nem Atmel 89C52 betreiben? Was müsste ich da denn alles anpassen? Danke MfG Kev
Datum:
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
Datum:
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
Datum:
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
Datum:
Hallo, die Stecker kaufe ich immer hier: http://www.shop.display3000.com/pd-1033582389.htm?... 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
Datum:
lol, geile Werbung :) Früher wurden da auf Anfrage nur Set´s mit Krempel den man nicht braucht angeboten, hat sich das geändert?
Datum:
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
Datum:
Hallo, ist das Display von Display 3000 ein Nokia6100? Gruß Michael
Datum:
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
Datum:
au welcher Schmiede stammt das S1D17G10 ? Sharp ? vielen Dank für die Antwort
Datum:
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.
Datum:
@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
Datum:
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
Datum:
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
Datum:
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
Datum:
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 ?
Datum:
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.... ;-)
Datum:
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.
Datum:
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
Datum:
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!
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
>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
Datum:
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.
Datum:
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
Datum:
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
Datum:
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! :)
Datum:
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
Datum:
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
Autor:
Andreas Schwarz
(andreas)
(Admin)
Datum:
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.
Datum:
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
Datum:
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.
Datum:
Angehängte Dateien: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
Datum:
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...
Datum:
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...
Datum:
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?
Datum:
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).
Datum:
Angehängte Dateien: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. :) :) :)
Datum:
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
Datum:
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
Datum:
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
Datum:
Hey ! Vielen Dank Hagen. Das mit der Farbpalette bekomme ich hin. Wünsche Dir viel Spaß in Jamaika ! Gruß, Thomas
Datum:
Wollte nur Fragen ob die Hompage mit der glcd lib irgendwann wieder online geht???
Datum:
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
Datum:
@ Hagen
> Verbaue wenn überhaupt erstmal meine S65 Displays.
Wie viele hast du denn noch übrig? Kannst ja welche verkaufen.
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
>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
Datum:
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
Datum:
Nach all den Spambeiträgen, mal wieder was anderes: Auf meiner kleinen Blogseite Zipfelmaus (Link: http://www.zipfelmaus.com/blog/how-to-nokia-6100-display/) habe ich ein Programm zum Konvertieren von BMPs in das RGB8-Format veröffentlicht. Das Programm erzeugt ein fertiges h.-file, das man ganz einfach in das eigene Projekt einbauen kann. Downloaden kann man es hier: http://www.zipfelmaus.com/wp-content/uploads/2008/...
Datum:
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/
Datum:
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
Autor:
Martin J.
(bluematrix)
Datum:
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
Datum:
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.
Autor:
Martin J.
(bluematrix)
Datum:
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. ...
Autor:
Martin J.
(bluematrix)
Datum:
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.
Datum:
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.
Datum:
Angehängte Dateien: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.
Datum:
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.
Datum:
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.
// ldi D0, lo8(SCREEN_COLOR)
lds D0, glcd_Colors
#ifdef USE_HIGHCOLOR
// ldi D1, hi8(SCREEN_COLOR)
lds D1, glcd_Colors+1
#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.
Datum:
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. >
// ldi D0, lo8(SCREEN_COLOR) > lds D0, glcd_Colors > #ifdef USE_HIGHCOLOR > // ldi D1, hi8(SCREEN_COLOR) > lds D1, glcd_Colors+1 > #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.
Datum:
Hallo Volkmar, noch eine Frage. Nutzt Du das Display mit oder ohne USE_HIGHCOLOR?
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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:
.macro in_ value port .if (_SFR_IO_ADDR(\port) > 63) lds \value, \port .else in \value, \port .endif .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):
ldi T1, COLOR_INTERFACE // initialize color format and color mapping
rcall glcdDispSend |
Hier muß doch
ldi T1, COLOR_INTERFACE // initialize color format and color mapping
rcall glcdDispCommand |
stehen. Den Block mit den Farben habe ich noch ins Flash verlegt:
.section .progmem #ifndef USE_HIGHCOLOR #ifdef USE_ORGINALCOLORS COLOR_RED: // original color table .byte 0x00, 0x02, 0x04, 0x06, 0x09, 0x0B, 0x0D, 0x0F COLOR_BLUE: .byte 0x00, 0x04, 0x0B, 0x0F #else COLOR_RED: // modified color table .byte 0x00, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F COLOR_BLUE: .byte 0x00, 0x08, 0x0B, 0x0F #endif #endif .section .text |
Dazu muß dies aber auch noch beim Setzen der Farben angegeben werden:
ldi P3L, 1 // Read from flash ldi P3H, 0 rcall glcdDisplaySetColors |
Für die ISR habe ich nur das was im Listing steht (da ich ja die Makros verwende):
00013966 <__vector_20>: 13966: a4 9a sbi 0x14, 4 ; 20 13968: 0f 93 push r16 1396a: 0c b5 in r16, 0x2c ; 44 1396c: 0f 7b andi r16, 0xBF ; 191 1396e: 0c bd out 0x2c, r16 ; 44 13970: 0f 91 pop r16 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
Datum:
>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
Datum:
Hallo zusammen, apropos S65...... Hat irgendjemand noch welche davon ? Ich find nirgends ne Bezugsquelle und brauch etwa 5 Stück, Sven
Datum:
> 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
Datum:
@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
Datum:
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
Datum:
@Ralph: tut mir leid aber ich arbeite an diesem Projekt, wie gesagt, seit Jahren nicht mehr. Gruß Hagen
Datum:
@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
Datum:
>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
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
@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
Datum:
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
Datum:
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
Datum:
@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
Datum:
Angehängte Dateien: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
Datum:
Angehängte Dateien: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?
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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__... > > 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
Datum:
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
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten
