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.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten
