Announcement: there is an English version of this forum on Hallo, hier ein einfaches Demo Program für Atmel AVR zur BitMap Ausgabe auf das Display des Siemens S65/M65/CX65/SK65 Mobiltelefon. Dieses Display gibt es bei diversen Quellen recht günstig als Ersatzteil zu kaufen. Preis derzeit z.B. 10EUR beim Internet Versteigerer zum sofort kaufen. Die weitergehende der Software und Hardware findet sich hier: http://www.superkranz.de/christian/S65_Display/DisplayIndex.html Dort gibt es auch die Quelltexte für die angepasste glcd die ursprünglich für das Nokia 6100 Display entwickelt wurde. http://www.mikrocontroller.net/forum/read-4-74872.html#new Have Fun Christian
Ich hab mir auch mal eins bei ebay für 10EUR geordert, hab leider zu spät gemerkt das bei diesen Displays der Artikelzustand als gebraucht beschrieben ist... Naja ich bin gespannt für den Preis kann man ja nicht sehr viel falsch machen :)
Hallo Christian, Du hast in Deiner Webseite http://www.superkranz.de/christian/S65_Display/DisplayIndex.html die Tag-Klammern zu den verlinkten Seiten etwas unglücklich gesetzt. Der IE6 verweigert deshalb die Links. Ansonsten sehr gute Arbeit! Gruß Joachim
oh ja, habe die schliessende Klammer(n) vergessen... Ich hab's repariert. Leider habe ich zuhause keinen IE und kann das nicht testen... Mozilla hat das nicht gestört. Grüße Christian
Und ich dachte die ganze Zeit, dass die Seite noch nicht fertig ist. Der hier gepostete Source-Code ist für mich nur schwer zu verstehen (C mit ASM kann ich noch nicht so gut) Durch deine Homepage ist mir der Ablauf der Display-Ansteuerung endlich klar geworden. Andy
Hallo Christian, in den Startsequenzen Init1 und Init2 sind pro Reihe eine unterschiedliche Anzahl Kommandos enthalten. Hat dies etwas zu bedeuten, muss ich außer den 7 ms zwischen Init1 und Init2 noch andere Zeitintervalle einhalten? Wie hoch kann die minimale bzw. maximale Taktfrequenz der seriellen Ansteuerung sein? MartinK
Hallo, die Aufteilung in verschiedene Reihen habe ich gemacht, weil ich vermute dass jede Zeile ein Command ist. Die Software (lcd.asm) schickt die Sequenzen einfach byte für byte als grosses Packet. Ich benutze 8MHz SPI clock, dürfte kein Problem sein, da das Display im Original mit 13MHz benutzt wird. Es funktioniert aber auch ohne double clock bit und mit 1/16 Teiler. Grüße Christian
Hi, ist es auch möglich mit bascom dieses LCD anzusteuern ? Besser gefragt, hat dies schon jemand gemacht ? ( Wird schon gehen, nur wie ? ) mfg Kay
Naja, die Ansteuerung hat im wesentlichen ja nichts mit der Ansteuerung zu tun. Bascom wird nur um einiges mehr Code produzieren, sollte aber trotzdem funktionieren.
So, ehe unser Oberguru Jens Dinspel wieder aus der Bahn geworfen wird*, hier eine korrigierte Fassung meines obigen Postings: Naja, die Ansteuerung hat im wesentlichen ja nichts mit der Programmiersprache zu tun. Bascom wird nur um einiges mehr Code produzieren, sollte aber trotzdem funktionieren. *) http://www.mikrocontroller.net/forum/read-5-244046.html#244746
Hy Leute, Hab mir vorhin mal die zeit genommen und das Zeug was auf der HP von Christian Kranz (ChristianK) war in ein PDF gepackt. Sollten irgendwelche Fehler oder Sonstiges sein, bitte sofort mir sagen. Gruß Lightning
Hat jezt nix mitm Disp zu tun, aber ich wllte euch nur mal drauf hinweisen, dass "actually" im Englischen icht aktuell sondern tasachlich bedeutet. Ihr wollt in dem Satz "Actually there are known three different types of the display." wohl eher "Currently" nehmen :) Gruss Tobias
@Christian: bei der Addressierung des DisplayRAMs gibt es wirklich nur diese 2 Modis ? Das bedeutet das dieses LCD mit meinen Font Routinen der GLCD nur Sinn macht wenn es senkrecht benutzt wird, mit Koordinate (0,0) Links Oben. Das ist Schade da es gerade waagerecht eingebaut interessant wäre. Hast du bei den Commandbytes mal alle Bits durchgetestet ? Ich könnte mir vorstellen das es ein Bit gibt das die Ansteuerung der Koordinaten spiegelt. In diesem Moment wären alle 4 Richtungen wieder möglich. Das Problem mit meinen Font Routinen ist, das sie durch die Komprimierung und dementsprechende Live-Dekomprimierung während der Anzeige eines Zeichens, nur in Richtung der Y Koordinate bottomup und der X Koordinate bottomup gezeichnet werden können. Eine einfache Art&Weise dieses Verhalten umzuprogrammiern wird es leider nicht möglich sein. Die Fonts müssten in ihrer Pixelreihenfolge schon während der Komprimierung umprogrammiert werden. Was natürlich zu einer Inkompatibilität der verschiedenen Fonts untereinander führt. Funktionieren denn meine Linien Routinen ? Ich erinnere mich dunkel daran das auch die Linienfunktionen von der spez. Memory Addressierungen Gebrauch machen. Kann man den DisplayRAM des LCDs auch wieder auslesen ? Ansonsten super Arbeit. Gruß Hagen
@ Tobias Schneider Hallo, Gut das du das mit demActually bemerkt hast. Ih habe bereits ein neues PDF gemacht wo der Fehler korrigiert ist. Ich warte aber noch mit dem Upload, vieleicht tauchen noch mehr solche Fehler auf. Gruß Lightning
@Hagen, ich habe einige (allerdings wohl nicht alle) Bit-Kombinationen nach dem 0x05xx Command getestet. Zumindest alle Einzelbits und FF. Ausser bei der 04 hat sich nichts getan... (habe natürlich auch 0x04xx und 0x03xx getestet ohne Wirkung) Ich habe mir da aber nicht sehr viel Zeit genommen, vielleicht ist noch was versteckt.... Die Linien habe ich in alle 4-Richtungen diagonal getestet, waren o.k. Leider kann man das Display Memory nicht zurücklesen. Macht im Mobile Phone Betrieb auch keinen Sinn, da der RAM-Inhalt regelmässig (etwa jede Sekunde) vom µC aufgefrischt wird um Pixelfehler zu vermeiden. Wie man mit der GLCD weitermacht weiss ich auch noch nicht. Mir reicht im Moment erst mal der 90-Grad Betrieb. Vermutlich könnte man sie schon einfach anpassen, wenn man etwas Performance und RAM opfert.... Grüße Christian
Im Notfall könnte man die zu zeichnenden Zeichen ins RAM des uC dekomprimieren und von dort aus entsprechend gedreht ans Display senden. Bei einer 2 Farb Font bräuchte man für ein 32x32 Pixel großes Zeichen gerade einmal 128 Byte.
@Hubertus du bist sowas von armsehlig... schade, dass solche, wie du meinen sie muessen leuter persoehnlich angreifen und somit solche foren, wie hier in den dreck ziehen nunja du bist der beste mach weiter so..
hi, nochmal zu bascom ... hat jemand vor, das ganze auch auf bascom zu portieren, oder bleibt ihr lieber bei C ? mfg Kay
In Bascom nicht aber in Assembler. Gruß Lightning
@Christian: >> Die Linien habe ich in alle 4-Richtungen diagonal getestet, >> waren o.k. Schlechter Test ;) versuche mal 4 Linien mit den Koordinaten 40,0 -> 60,176 60,0 -> 40,176 60,176 -> 40,0 40,176 -> 60,0 Deren Steigung ist < 1 in Y Richtung Dann noch 0,78->128,98 0,98->128,78 128,98->0,78 128,78->0,98 Deren Steigung ist ebenfalls < 1 in X Richtung Bei den Fonts gäbe es noch die Möglichkeit ohne Komprimierung zu arbeiten. Man kann dann die Speicherzugruiffe auf die Fontdaten entsprechend umbauen. Allerdigs hats eben mehrere Nachteile 1.) monochrome große Fonts werden normalerweise auf 1/4'tel oder sogar 1/8'tel der Größe komprimiert. Bei 16Kb also nur 2-4Kb an real benötigtem Speicher, das ist ne Menge Holz. 2.) Der Code muß 4 Orientierungen separat umsetzen, für jede Orientierung eine eigene Schleife, ergo mehr Programcode 3.) Man kann nun nicht mehr linear sequientiell die Fontdaten aus dem Speicher laden. Das ist im ersten Moment für einen Laien kein größeres Problem. Aber ich habe exakt auf dieses spezielle Feature Acht gegeben damit man nämlich die Fontdaten in externen seriellen Speicherbausteinen, oder SD/MMC Karten ablegen kann. Bisher gibt man den Startadresse an dem ein Font beginnt vor. Beim zeichnen eines Zeichens wird immer linear sequientiell ab dieser Addresse die Daten aus dem Speicher gelesen. Darauf müsste man dann verzichten. 4.) die bisherige innerste Loop der Fontroutinen ist so ausgelegt das sie während 1 Byte übers HW-SPI im Hintergrund gesendet werden mit maximal 16 Takten die nächsten Koordinaten berechnet und die Daten dekomprimieren kann. Es entsteht also eine enorm hohe Performance der Font-Routinen im Vergleich zum Datendurchsatz. Wie Ape schon oben vorgerechnet hat: ein String mit 32 zeichen a 16x16 Pixeln und 16Bit Farben muß an das Display 16Kb übertragen. Nur 32 Zeichen !! Bei komprimierten Fonts ist aber die innerste Schleife samt Clipping meistens schneller fertig mit den neuen Daten als das das HW-SPI seine 8 Bits rausschicken kann. Man erreicht also theoretisch Clock/2 MBit Durchsatz. Gruß Hagen
wäre es denn möglich, einen avr zu nehmen, der in Assembler oder C das display ansteuert und die "daten" über die serielle bekommt ? mein problem ist, das ich kein C und kein assembler kann. würde halt gern mit bascom programmieren.
Hallo Kay, ich werde mich nicht mit BASCOM beschäftigen. Allerdings dürfte - wenn du dich ein wenig mit BASCOM auskennst - die Display Ansteuerung nicht so schwer sein. nach der Homepage kann Bascom: a) SPI Interface ansprechen b) externe C/Assembler Routinen aufrufen D.h. für eigene Grafik-Routinen reicht a), wenn du die glcd benutzen willst musst du dich mit b) beschäftigen... Grüße Christian
hab im oberen post den halben text vergessen. ich habe mir jetzt so ein display bestellt. ich warte bis das display hier ist und werde dann mal schauen wie weit ich komme. Will einfache Texte an einer bestimmten position platzieren. und grafiken anzeigen lassen. vielleicht bekomme ich das mit bascom ja hin. wenn nicht, dann halt nicht. probieren kann man es ja mal. mfg Kay
Ich habe Vorgestern mein Display (blaue Platine) erhalten. Doch leider gelingt mir die Ansteuerung nicht. Zuerst habe ich es mit Bascom versucht, da ich mit Basic schon die Ansteuerungsroutinen für die Nokia-Displays 3510i und 6100 geschrieben habe. Prinzipieller Ablauf (verkürzt wiedergegeben): Mega128, 2.8 Volt, 4 MHz-Resonator, Port C Reset (low), dann Pegel auf high CS auf low, RS high (Commands) Datenpin high/low setzen, mit CLK auf high wird Zustand eingelesen die Wartezeiten zwischen Init1 und Init2 habe ich variiert (0-40 ms) RS low für Daten Leider tat sich nichts Dann habe ich das Beispielprogramm simple_display3 genommen, das Display an Port B angeschlossen, und im ASM-File Xtal auf 4 MHz gesetzt, und make all vom AVR-GCC gestartet. Dann das Gleiche nochmal mit dem internen kallibrierten 1 MHz Oszillator ausprobiert. Leider zeigte das Display keine Reaktion. Jetzt bleiben noch 3 Möglichkeiten übrig: Display ist defekt Display is inkompatibel ich habe irgendwas falsch gemacht (nur was?) Vielleicht weiss einer Rat. MartinK
Hallo Martin, grundsätzlich hört sich das o.k. an. Läuft der atmega mit 2.8V zuverlässig? Drei Dinge: a) mit so langsamen Takt habe ich das noch nicht probiert, der langsamste waren 8MHz mit einem ATmega32 b) Für dein BASCOM: Ich glaube, das zwischen den Commands das CS toggeln muss. c) Blaue Platine? Bisher kenne ich nur die grüne und zwei verschiedene braune.... Vorschläge: -> Überprüfe die Verdrahtung mit den #defines in simple_display3 -> kannst du dir die Port Signale anschauen und überprüfen? Wenn ja check die Verzögerung zwischen INIT1 und INIT2 mit dem Osci. sowie die Daten -> Überprüfe deinen Display Anschluss. Ich kann ESD Schutzdioden zwischen den Steuersignalen und Supply/GND messen (ca. 1V mit meinem Diodentester). Damit kannst du testen ob der Kontakt da ist. -> Nehme Spannungsteiler, 5V und 16MHz
@MartinK Kannst du bitte mal n Foto von dem Display mit der blauen Platine Posten ?? (Vorder + Rückseite) Mfg. Lightning
@Lightning Tut mir Leid, aber momentan habe ich keine Digitalkamera. Das Display habe ich bei Ebay ersteigert (Cellow), sieht fast genauso aus wie das linke Display auf Christians Homepage. @Christian Ich habe den Mega128L, kann max 8 MHz, läuft aber bei 2.8 Volt zuverlässig. Die Schutzdioden habe ich auch messen können mit Ausnahme von Pin 1 (RS), bei dem ich absolut nichts messen kann, vielleicht liegt hier der Fehler. MartinK
Das ist zumindest ein Fehler. Ich kann auch bei RS die Dioden messen.
@Christian Die Signalleitung von Pin 1 (RS) ist definitiv irgendwo unterbrochen. Im Übrigen gleicht mein Display deinem Grünen fast 100%ig, nur der Lötstopplack meiner Platine ist blau. Sogar die Platinenaufdrucke sind gleich. Ich habe bei meinem Display den weissen unteren Platikrahmen abmontiert. Dann habe ich kurz vor der Bending-Area, also dort, wo die Leiterfolie auf die Platine geklebt ist, mit einem scharfen Cutter den Lötstopplack von der Platine gekratzt. Da die Leiterbahnen an dieser Stelle sehr klein und eng beianander liegen (etwa 60 auf 2,2 cm), habe ich mit einem akustischen Durchgangsprüfer die Signale zwischen Leiterbahnen und Anschlusspins geprüft. Alle Pins mit Ausnahme von RS gaben einen Signalton. Der einzige Punkt, an dem ich noch ein Signal erhalte, ist der rechte Lötpunkt von R4 (oder A4). Von da an verliere ich das Signal. Und bei einer 4-Layer (oder noch mehr) Platine kann ich nichts mehr machen. Vielleicht könntest du mir helfen. Von Reset und CS weiss ich, dass das Signal bei einem Kondensator oder Widerstand wieder auftaucht. (CLK taucht erst an der Bending-Area wieder auf). Vielleicht gibt es eine direkte Verbindung zwischen RS und irgendeinem Baustein oder Lötpunkt. Dann könnte ich einfach ein Kabel daran löten. Unter dem weissen Abdeckrahmen sind keine Bausteine. MartinK
Martin, habe gerade mein grünes Display untersucht: a) ich kann RS nirgends, ausser an R4 finden b) ich messe bei RS auch keine Schutzdiode!!!! Das ist ein Unterschied zwischen den grünen/blauen Display und den braunen... Grüße Christian
@ChristianK: > Das ist ein Unterschied > zwischen den grünen/blauen Display und den braunen... Das heißt jetzt was genau? Ich werde wohl morgen auch ein blaues erhalten (Cellow, ebay). Laut dem PDF sollte es 3 Versionen geben (wohl blau, braun und grün). Sind jetzt alle gleich oder nicht? @MartinK: Wenn meins morgen ankommt werde ich mich mal am WE dran begeben. Ich meld mich dann mit den Ergebnissen. Grüße, André
Ach noch was. In der Artikelbeschreibung von Cellow ist aber ein ROTES mit brauner(?) Folie abgebildet. Laut PDF: Grün=Braun Laut ChristianK: Grün=Blau!=Braun Hilfe! Farbenwahn! Grüße, André
@Christian Hast du das grüne Display mal ausprobiert? @André Ja, ich habe bei meiner Bestellung bei Cellow auch ein Display mit einer rötlichen Platine gesehen. Streng genommen ist meine Platine nicht rein blau, sondern hat einen kleinen Grünstich, also dunkel-Türkis MartinK
Hm. Wenn meins morgen da ist, up ich mal 'nen Scan. Vielleicht sollte das PDF dann um Eigenarten der verschiedenen Displaytypen ergänzt werden. AK
Zum Aufklären des Farbwirrwars: Also ich besitze: a) ein braunes wie auf Web-Page abgebildet b) ein braunes mit anderer Platine (kein Foto, da eingebaut ) c) ein grünes wie auf Web-Page abgebildet Diese drei verhalten sich gleich. Martin hat jetzt noch ein türkis-farbenes das aber wie mein grünes aussieht... und offensichtlich die gleiche Eigenschaft hat dass keine Schutzstruktur am RS pin zu messen ist.
Hallo, ich habe die Software (WEB und hier) nocheinmal upgedated. Grund ist, dass das Display nicht immer zuverlässig gestartet ist. Es konnte passieren, dass mehere Reset's nötig waren um das Display zu starten. Wenn es dann einmal lief, lief es ohne Probleme. Zuerst habe ich das auf meine unvollkommene Reset-Beschaltung geschoben, konnte heute aber nachweisen, dass es nicht der µC ist der die Probleme macht. Also habe ich die init1 sequence in zwei Sequenzen aufgeteilt (wie beim S65 gemessen) und eine Wartezeit von 68ms dazwischen eingebaut. Bisher hat damit das Display problemlos funktioniert. Grüße Christian P.S: Diesmal habe ich die HEX-Files im Zip gelassen. Diese HEX Files habe ich bei mir getestet und sie funktionieren.
Hy Leute, Wenn ihr alle Arten von Displays untersucht habt, schickt mir bitte Infos zu (oder hier Posten). Dann werd ich in mein PDF da noch ne extra Rubrik für die verschiedenen Displays und deren Tücken, Farben,... etc. reinbasteln. Gruß Lightning
Da stehen doch auch Typbezeichnungen auf der Rückseite drauf, z.B. LPH8836 oder LS020... Gibt es denn innerhalb eines Typs verschiedene Leiterplattenfarben? Gruß Roland
hi, das display braucht ja eine Versorgungsspannung von 2,9V. macht es dem display was aus, wenn es 3,3 V sind ? habe nämlich noch einen LM3574 den ich gerne benutzen würde. nur will ich auch nicht mein Display schrotten. mfg Kay
Ob 3.3V funktionieren weiss ich nicht, ich würde da aber erstmal keine Experimente eingehen. Letztendlich hängt die ganze Spannungserzeugung für das Glas daran.
dann muss ich wohl das ganze von 3,3 auf 2,9 V bringen. müsste doch mit nem widerstand machbar sein oder ?
@Christian, auf den Fotos auf Deiner Homepage ist ja auch ein LPH8836 zu erkennen. Hast Du Deine Software auch mit dem LPH8836 getestet oder nur mit dem anderen LS020-Typ? Bei meinem LPH8836-3 funktioniert außer der LED-Beleuchtung leider noch nichts. Verdrahtung habe ich schon mehrfach kontrolliert, am Power-Up-Timing habe ich auch schon herumprobiert, leider ohne Erfolg. Was mich etwas wundert: weshalb geht bei Dir das Power-Up-Timing schief, wenn die Wartezeit zu groß ist? Eine Mindestzeit hätte ich erwartet, aber eine Maximalzeit...? Michael
Angehängte Dateien:
-
LCD_Back.jpg
44 KB
Hi, mein Cellow-LCD ist da. Grün (also kein Türkis wie bei MartinK). Allerdings auch keine Typenbezeichnung drauf ;-( Hoffe es ist ein LPH8836 (DAS sollte ja gehen). Layout paßt schonmal. Grüße, AK
Meins ist auch da, ein braunes mit LS020..... über eb** müsste auch passen
@André Cellow scheint verschiedene Chargen zu verkaufen. Meins sieht zwar genauso aus (außer der Farbe) Als Herstelldatum auf dem weißen Kunststoff steht bei mir 4 04, also 3 Monate jünger als deines. Die Nummer auf dem weißem Aufklebr ist: 3738.1 Nummer auf der Platine (neben den Anschlüssen): 3320 010 2051.2 Mein Display läuft leider immer noch nicht. Es wäre schön, wenn du bei erfolgreicher Ansteuerung dein Ergebnis mal posten würdest. MartinK
@MartinK Ergebnisse kommen (wohl frühestens am WE). Wenn Deins jünger ist, geh ich mal davon aus daß nur der Lack-Hersteller gewechselt wurde. Deine Chancen (und meine) stehen wohl gut ;-) Grüße, AK
Kann mir jemand die exakten Einbau-Masse des Displays nennen ? Danke im Voraus an alle Hilfsbereiten. Daz
Hallo, ich benutze derzeit ausschliesslich das Display, das auf der Web-Seite rechts neben dem grünen zu sehen ist. (braun LSxxx) Das grüne hatte ich nur einmal ganz kurz vor einiger Zeit im Betrieb. Nur um zu testen ob es funktioniert. (damals hatte ich die Displays übrigens parallel geschaltet, - beide zeigen dann das gleiche Bild...) Die Ansteuersoftware hat sich danach noch geändert. Im wesentlichen "Weg-Optimierungen" von "überflüssigen" CS toggeln, Änderungen im Timing etc. Es besteht daher eine gewisse Wahrscheinlichkeit, dass das grüne Display mit der derzeitigen Ansteuerung nicht (mehr) funktioniert. Nach dem Motto was nicht getestet ist funktioniert meist auch nicht. Ich werde - frühestens am Wochenende - das grüne mal wieder anschliessen. Dann kann ich näheres sagen. Zu den Kodes: LSxxxxxx Hersteller vmtl. Epson? L2F50126 Hersteller vmtl. Epson LPHxxxxx Hersteller vmtl. Philips? Ihr könnt aber auch selber experimentieren. Die Timing's der Original-Ansteuerung sind ja verfügbar. Im worst case muss man die einfach exakt nachbauen...
ich habe jetzt über einen Spannungsteiler mit 2 Widerständen eine Spannung von 3,034 V. Das müsste doch gehen für die Spannungsversorgung vom Display oder ? Noch ne Frage: Wieviel mA zieht das Display denn ? mfg Kay
So hab jetzt mein Display auch endlich mal bekommen, braune Leiterplatte LSxxx. 2,9V Versorgung über Spannungsregler, Level-Shifting über Widerstände. Die Lib hat auf Anhieb funktioniert. Vielen Dank nochma :) Kleine Frage am Rande: Warum ist der zweite Versorgungspin des Display 1V8 benannt, obwohl er auch an den 2,9V hängt? @Kay: Mit Spannungsteiler-Konstruktionen für die Versorgungsspannung wär ich vorsichtig, da eine solche Versorgung per Definition einen sehr hohen Innenwiderstand hat und daher die Spannung bei Lastwechseln stark schwankt (Es sei denn du willst mit dem Spannungsteiler auch gleich heizen). Hab noch nich gemessen wieviel das Display so aufnimmt und ob sich die Stromaufnahme stark ändert, aber ein Spannungsregler ist doch die bessere Wahl.
hi ape, welchen Spannungsteiler benutzt du denn für das display ? hast du das display schon ans laufen gebracht ? mfg Kay
mhh ich meine natürlich Spannungsregler ...
@ape Woher hast du das Display? Hast du 16 MHz, oder funktioniert die Ansteuerung auch bei niedrigeren Taktfrequenzen? MartinK
Ich hab das ganze im Moment auf dem Steckbrett laufen und benutze einen LM314 (einstellbarer Spg.regler), der is zwar etwas überdimensioniert, aber das macht ja nichts :) Ich hatte zunächst die Lib für 8MHz übersetzt und den Mega128 mit internen 8MHz laufen, das hat wunderbar funktioniert. Als nächstes habe ich die Lib für 16MHz kompiliert und einen 16MHz Quarz verwendet, damit geht das Display aber nicht an. Wenn ich aber erstmal mit einem langsamen Takt starte und dann auf 16MHz umstelle (Jumper auf dem STk500 von Board-Takt auf Quarz-Takt umstecke) läuft das Display auch problemlos. Erscheint mir merkwürdig, ich muss das nochmal genauer untersuchen.
@ape Mit Lib meinst du simple_display3 ? Gut, dass das bei dir läuft. Mit meinem 8 MHz Atmega128L hat das nicht funktioniert. Vielleicht habe ich beim Compilieren etwas falsch gemacht. Kannst du mir das fertige Hex-File für 8 MHz an meine E-Mail-Adresse martin-k@x-mail.net schicken oder hier posten? Wenn mein Display dann immer noch nicht funktioniert, dann ist es entweder kaputt oder inkompatibel. Mein Mega128L funktioniert einwandfrei, das habe ich überprüft. MartinK
@Fabian Super, endlich mal ein Erfolg :-) Die 1V8 Spannung heisst so, weil im Original hier 1.8V anliegen. Das ist die von Siemens benutzte Interface-Spannung. Bei allen mir bekannten Display Controllern ist diese allerdings sehr weit spezifiziert üblicherweise immer bis hin zur Display-Spannung. Darum habe ich sie auch an die 2.8V gehangen. 16MHz Problem: Hast du die neue Version mit den 3-Init Sequenzen benutzt? (die die aktuell unter download steht) Die läuft bei mir mit 16-MHz wirklich völlig problemlos. Allerdings ist das Timing am SPI-Bus mit den passiven Level-Shiftern bei 8MHz SPI-Clock schon nicht mehr optimal. Ich überlege schon, ob ich für das spätere Gerät nicht aktive Level-Shifter verwenden soll. Grüße Christian
Angehängte Dateien:
-
s65lcd.jpg
84 KB
Hallo ich hab jetzt nochmal die neueste Lib von deienr Seite runtergeladen aber das hat keine Änderung gebracht. Vielleicht kannst du in einer nächsten Version den SPI Clock fürs Init etwas runtersetzen und erst danach voll aufdrehen. Ich denke spätestens wenn ich ein Gerät mit dem Display baue, werde ich aktive Level-Shifter einsetzen, aber so fürs steckbrett wars erstmal die einfachste und schnellste Lösung :) Im Anhang mal nochn Bild, kommt auf dem Foto nicht gut rüber, aber ich bin positiv überrascht von der Bildqualität des LCDs, ist wirklich um Längen besser als das Nokia 6100... @Martin: Nein das simple_display hab ich nicht ausprobiert sondern gleich die portierte glcd Library verwendet. Ich hab dir mal das Hex File per Mail geschickt.
@ape Danke für das File. Leider funktioniert das Display immer noch nicht. Ich habe extra noch mal alle Kabel neu angelötet. Ich schätze, ich werde mir ein braunes Display bestellen. MartinK
Schaut euch mal dieses Angebot bei Ebay an: http://cgi.ebay.de/Original-Siemens-M65-M-65-Farb-LCD-DISPLAY-NEU_W0QQitemZ6444305427QQcategoryZ40578QQcmdZViewItem Laut Anbieter ist ein M65-Display nicht mit S65 kompatibel, während andere Händler keinen Unterschied machen. Vielleicht ist mein Display nur M65 kompatibel. MartinK
Für was genötigt man diese Levelshifter ? ich dachte, es reicht, eine 2,9V Spannung und die 10,4 V für die Hintergrundbeleuchtung ? mfg Kay
@Kay: Nix für ungut, aber du weißt schon was du tust? Die Level-Shifter brauch man um die Pegel auf der Schnittstelle zwischen Controller und Display anzupassen. Schließlich läuft der AVR bei 2,9V nicht mehr mit voller Taktrate (wenn man Glück hat schon, aber man ist dann schon sher weit außerhlab der Specs...). Die einfach-Lösung besteht darin mit Spannungsteilern die Signal-pegel runterzuteilen. Steht glaub ich auch irgendwo weiter oben im Thread. Jedenfalls sind aber durch die relativ hohen Widerstände die Signale bei hohen Frequenzen nicht mehr sehr schön. Ein aktiver Level-Shifter schafft da Abhilfe. @all: Für einen Einsatz im Querformat ist das Display übrigens nicht sehr gut geeignet, da der Blickwinkel für den Einsatz im Handy optimiert zu sein scheint. Der beste Kontrast ergibt sich, wenn man von unten leicht schräg auf das Display schaut. Bei senkrechtem Blickwinkel oder gar von der Seite leidet der Kontrast doch recht massiv.
So hab nun auch das Init Problem bei 16MHz behoben. Und zwar hab ich die init Routine so geändert das das Double Speed Bit erst nach der eigentlichen Initialisierung gesetzt wird. Also hier (glcd_init.asm):
1 | ; write initial screen command (i think not necessary...) |
2 | cbi LCD_PORT,LCD_CS ;select Display |
3 | |
4 | ldi T1,0xEF |
5 | rcall glcdDispCommand |
6 | ldi T1,0x90 |
7 | rcall glcdDispCommand |
8 | ldi T1,0x00 |
9 | rcall glcdDispCommand |
10 | ldi T1,0x00 |
11 | rcall glcdDispCommand |
12 | |
13 | ldi r24,1 ; double speed bit |
14 | out LCD_SPSR,r24 |
15 | |
16 | rcall lcd_clrscr |
17 | |
18 | pop r31 |
19 | pop r30 |
20 | ret
|
Hatten wir das gleiche Problem nicht auch schon beim Nokia Display ? Gruß Hagen
Naja zumindest ist der Blickwinkel beim Nokia auch nicht sehr groß. Das Problem beim Siemens Display lag aber zum Teil auch an mir :) Der Spannunsgregler war nich ganz richtig beschaltet das Display hatte nur 2V Versorgungsspannung... Jetzt kann man auch senkrecht aufs Display gucken, aber sonderlich groß is der Sichtbereich trotzdem nich. Ich denke mal mein Problem mit den 16MHz lag auch dadran, aber ein etwas langsameres Init kann denk ich trotzdem nich schaden :)
Hallo, schlechte Nachrichten für alle grünen und blauen... Ich habe gerade das grüne Display LPHxxx angeschlossen. Mit der aktuellen Software läuft es nicht! Ich habe auch bereits ein wenig am Timing gespielt, es aber nicht zum laufen gebracht. Vorher hatte ich es zum Test in das S65 eingesetzt und dort hat es funktioniert. (Daher glaube ich die Theorie mit dem M65 nicht) -> Vorerst als nur das LSxxx Display kaufen! (braun, rechts auf dem Bild)
@Christian: Wenn es im S65 funktioniert hat, aber mit Deiner eigenen Ansteuerung nicht, dann wird beim LPHxx vermutlich doch ein anderes Protokoll gefahren als beim LSxxx, d.h. in der Handysoftware wird erkannt, um welches Display es sich handelt, ähnlich wie beim Nokia 6100 Philips / Epson, z.B. durch Abfrage eines Identifikationsregisters. Wenn Du das Protokoll des Handys mit eingesetztem LPHxx nochmal aufzeichnen könntest, wäre das natürlich super. Ich weiss, ist viel Arbeit. Ich würde es auch selber machen, habe aber leider kein S65 und nur dafür eines kaufen ist mir dann dann doch etwws zu teuer... ;-) Gruß Michael
Von weiter oben: "Das grüne hatte ich nur einmal ganz kurz vor einiger Zeit im Betrieb. Nur um zu testen ob es funktioniert. (damals hatte ich die Displays übrigens parallel geschaltet, - beide zeigen dann das gleiche Bild...)" Die Ansteuersoftware hat sich danach noch geändert. Im wesentlichen "Weg-Optimierungen" von "überflüssigen" CS toggeln, Änderungen im Timing etc. Es besteht daher eine gewisse Wahrscheinlichkeit, dass das grüne Display mit der derzeitigen Ansteuerung nicht (mehr) funktioniert. Nach dem Motto was nicht getestet ist funktioniert meist auch nicht." Wenn ich das richtig verstehe hat es ja schonmal funktioniert :)
Ja, ich bin mir ziemlich sicher (ich werde schon vorsichtiger...), dass ich das grüne und das braune parallel in Betrieb hatte. Ich wollte ja wissen ob sie kompatibel sind... Darum sollten sie - wenigstens für init - einen ähnlichen Befehlssatz haben. Ich vermute, dass es eine blöde Kleinigkeit ist, die hier das grüne Display blockiert. Z.B. falsche Pegel auf RS/CS/CLK/DAT lines wärend der RESET Flanke... Ich habe jetzt schon einiges probiert, leider immer noch ohne Erfolg...
@ChristianK: auf Deiner Homepage steht 10,4V/20mA für die HB. Müßte die Gesamtspannung in "Schematic" dann nicht 14V sein (steht 15V drin)? 10,4+180Ohm*20mA = 14V. Wie ist das denn bei der HB, wenn die 5mA mehr Strom (immerhin 25%) bekommt? Grüße, AK
@Andre, ich kenne die Spezifikation der LED's nicht und habe mir den Aufbau der Hintergrundbeleuchtung auch noch nicht genau angeschaut. Im Moment gehe ich von drei in Reihe geschalteten LED's aus. D.h. bis zu max. 30mA Dauerstrom (je nach gewünschter Helligkeit/Batterie-Lebensdauer) sollte erlaubt sein. (sollten es 2x3 in Reihe geschaltete LED's sein müsste der Strom höher eingestellt werden...) Deine Rechnung stimmt. Aber der Messwert 10.4V@20mA gilt natürlich nur für dieses eine Display bei der damaligen Temperatur.
Hi, danke. Dann mach ich mich mal dran. Hab Deinen Code für einen ATmega8515 kompiliert (wegen DIP-Gehäuse und ein anderer war gerade nicht da). Werde einen 74HC573 als LevelShifter nötigen. Mal sehen ob mein LCD damit funzt ...
@Fabian Thiele könntest du eventuell mal deinen Code posten mit dem du die Bitmap ausgibst? Wo hast du die gespeichert ? Wenn ich richtig rechne hat das Display eine Auflösung von 132x176 Pixel also 23232 Bildpunkte bei 16 bit Farbtiefe sind das etwa 45kb?
Ich sende die Bilder über die serielle Schnittstelle vom PC. War nur nen einfaches Test-Programm ohne jegliches Protokoll oder so. Das ganze "Programm" sieht so aus:
1 | void recvPicture(void) { |
2 | uint8_t x=0, y=175; |
3 | glcdColor_t pix; |
4 | |
5 | for(uint16_t i=0; i<23232; i++) { |
6 | pix = get()<<8; |
7 | pix |= get(); |
8 | glcdSetPixel(x, y--, pix); |
9 | if(y == 255) { |
10 | y=175; |
11 | x++; |
12 | }
|
13 | }
|
14 | }
|
get() empfängt ein Byte übers UART, die Üebrtragung erfolgt mit 460kBaud, das Bild zu übertragen dauert ca. 1 Sekunde. Ich weiß auch das die Funktion glcdSetPixel() für diesen Zweck nicht optimal ist, da ja jedes Mal auch wieder die Position auf dem Display neu egsetzt wird, was jede Menge Overhead bedeutet, aber zum Testen reichts :)
Danke für die schnelle Antwort. Hast du ein speiziellen Programm mit dem du die Daten an den UART schickst oder verwedest du einfach das Hyperterminal und benutzt du die Funktion Datei schicken?
Ich hab mir ein kleines Java-Programm geschrieben, was die Bilder öffnet in die richtige Größe konvertiert, nach 16-Bit umrechnet und dann einfach die nackten Pixeldaten an den AVR sendet. Hyper-Terminal oder sowas funktioniert nicht, da das ja ein Protokoll zur Dateiübertragung verwenden würde, außerdem haben ja auch Bitmaps nen Header und auch nicht die passende Farbtiefe. Hab mein Programm mal angehangen, vielleicht kannst du ja was mit anfangen. Mit run.bat starten, Bild öffnen (gif, jpg oder png) Com-Port auswählen und senden. Baudrate ist fest auf 460kBaud, wenn das zu Viel ist musst dus im Quelltext anpassen udn neu kompilieren :). Wenn man ein Verzeichnis öffnet, werden alle enthaltenen Bilder im 15 Sekunden Takt als Slideshow angezeigt. Achja und du brauchst natürlich eine aktuelle Java Runtime Environment.
Das Programm scheint schon mal super zu sein. Leider hackt es auf dem Atmel noch etwas. Die Zeile "pix = get()<<8;" erzeugt beim Kompilieren den Fehler: undefined reference to `get'.
Ja klar, das is ja keine Library Funktion. Die Funktion empfängt einfach ein Byte übers UART. Hatte sie jetzt oben nicht mit gepostet weil ich das eigentlich für Trivial gehalten habe :) Im Anhang mal der Komplette Code für den AVR (mega128). Takt ist 18,432MHz. Wenn du einen anderen Takt verwendest, musst du den Wert für UBRR0L anpassen um die passende Baudrate zu behalten.
Schlechte Nachrichten für alle Besitzer von grünen Displays (LPH) und Epson (L2F) Displays. Ich habe - nachdem ich alle Variationen der Ansteuerung mit dem grünen Display erfolglos durchgefahren habe - den Parallel-Test wiederholt. D.h. ich habe ein Epson Display (L2F) (eingebaut) jeweils mit einem grünen (LPH) und dem braunen (LS0) ausserhalb und parallel am S65 betrieben. Leider ohne Erfolg. Es hat immer das externe Display gewonnen und den Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes hat das interne funktioniert. -> Das S65 hat wohl eine Funktion um das Display zu erkennen -> Beim letzten mal muss ich wohl doch zwei gleiche Displays parallel geschaltet haben -> jedes Display wird seinen eigenen Befehlssatz haben Immerhin lässt das hoffen, dass das Epson kompatibel zu einem Epson Befehlssatz ist (d.h. mehr Addressierungsmodies, 0-Grad Betrieb mit glcd...)
Es gibt definitiv 2 verschiedene Controller: www.siediyer.com/Doc/x65SRD.pdf Seite 30
Hallo MarinK, toller Link - danke. Ich habe lange versucht das S65 repair manual zu finden, aber keiner der Links und Quellen hat funktioniert... Jetzt kennen wir zumindest schon die LED-Spec (15mA). Ich denke aber es gibt drei Hersteller (ich habe die drei Bilder auf meiner Web-Page). Eins kommt definitiv von EPSON (steht drauf). Wenn sie über die Widerstandswerte identifiziert werden kann man ja mal nachmessen...
Hi, > For the display two different sources are used, which > will be distinguished by the software via different > code resistor values. Bin ich noch zu müde? Hat jemand gefunden WIE man die LCDs erkennt? 'Resistor' scheint klar, aber welcher?
@ChristianK: > ich habe ein Epson Display (L2F) (eingebaut) jeweils mit einem grünen > (LPH) und dem braunen (LS0) ausserhalb und parallel am S65 betrieben. > Leider ohne Erfolg. Es hat immer das externe Display gewonnen und den > Inhalt angezeigt, wobei das interne L2F leer blieb. Ohne externes hat > das interne funktioniert. Ok. Heißt also L2F!=LPH und L2F!=LS0. Laut Datenblatt gibt es 2(!) verschiedene Typen. Wenn L2F!=LPH ist und L2F!=LS0, MUß LS0=LPH sein => Deine Routinen sollten auch mit dem LPH funktionieren. Allerdings befürchte ich noch eine andere Fehlerquelle: Die Widerstandskodierung dürfte nicht funktionieren bei 2 parallelen LCDs.
Hallo, Christian, du hast ja alle drei sorten displays, kannst du mal nachmessen: Widerstand zwischen masse und RESET: - L2F50xxx -> 52,46Kohm - LPH88xxx -> 20,1Mohm - LS020xxx -> ?? Widerstand zwischen masse und CS: - L2F50xxx -> 27,6Mohm - LPH88xxx -> 25,2Mohm - LS020xxx -> ?? Ich habe mit eine philips PM2525 (multimeter) gemessen und die com vom messgerät auch an die masse vom display gehalten. Nur der RESET und CS gehen zum ARM9 (SGold-Lite PM8875) controller, also können das meiner meinung nach die einzige pin zur display erkennung sein. Die andere pins (CLK, DAT, RS) gehen zum S1D13732, also keine möglichkeit zur erkennung. Grüße Mark,
Hi, das deckt sich ja mit meiner Theorie. Wenn das LS 20,1MOhm hat zwischen GND und RESET besauf ich mich heute abend ;-) Ich denke nicht, daß die 2MOhm Unterschied am CS relevant sind. Ich meß mal mein Display gleich nach.
@Christian: Hättest Du denn Zeit und Lust, das Protokoll des ans S65 angeschlossenen LPHxx nochmal mitzuloggen? Hab leider kein S65, sonst würde ich es selbst versuchen, aber falls mich jemand mit einem S65 sponsern möchte, jederzeit gerne... ;-) Gruß Michael
Hallo Alle, Kennt jemand das Siemens CXT65 ? Grüße Mark,
Hat sich erledigd, das CXT65 hat das gleiche display. Grüße Mark,
Hallo Freunde der grünen und blauen Display's, jetzt wartet Arbeit auf euch.... Hier ein C-Programm zur Ansteuerung des Displays. FillScreen() funktioniert tadellos aber ihr werdet sehen, dass die Textausgabe noch nicht ganz korrekt ist. Die Position und die Breite stimmt schon - aber die Höhe noch nicht... Die Zeichen sind ein wenig verschoben und nur halb ausgegeben. Also macht euch an die Arbeit und unterstützt beim Suchen der richtigen Ansteuerung.... Grüße Christian
Hallo Christian, Das sieht danach aus das der HD66766 Controller drauf ist. Grüße Mark,
Angehängte Dateien:
-
LPH_V01.jpg
120 KB
Das wäre natürlich super wenn es der HD66766 oder ein kompatibler wäre... Hier noch ein Bild zum obigen Program. Ich werde die nächsten Tage nicht unterstützen können also viel Erfolg. Grüße Christian
Hi, ich weiß nicht ob das mitten in diesen Thread gehört, aber: !!! EIN FETTES DANKE UND MERCI AN CHRISTIAN KRANZ FÜR SEINE MÜHEN UND UNTERSTÜTZUNG !!!
Angehängte Dateien:
-
IMG_0730.JPG
240 KB
@André Dem kann ich nur zustimmen! @Christian Die Ansteuerung hat geklappt, bis auf die Textausgabe. Zur Weiterentwicklung der Ansteuerung bin ich noch nicht gekommen, weil ich heute ein LS020-Display bekommen habe (Ebay, PID-Handy), das ich auf Anhieb auch zum Laufen bekommen habe. Mir ist aber aufgefallen, dass das LS020-Display wesentlich heller ist. Im Dateianhang ist ein Bild von beiden Displays, deren Hintergrundbeleuchtung mit je 12 mA betrieben wird (links LS020, rechts LPH88) Außerdem scheint das LS020-Display gleichmäßiger beleuchtet zu sein. MartinK
Hallo Alle, Ich arbeite gerade an eine platine für das Display. Ich will ein Platine machen mit: - +3.3volt oder +5 volt eingang. - Spannungs regler für 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - Level wandler für signale. - 10 polige stifleiste mit 2,54mm abstand. - etwas größer als das display. - größe 38.8mm x 60mm Soll noch etwas mit drauf? Grüße Mark,
O.k. nachdem das Datenblatt verfügbar ist (es handelt sich tatsächlich um einen HD66766 kompatiblen Controller :-) war es ja nur noch eine Sache von Minuten... Das LPH hat auch seine Vorteile: a) einfacher zu löten, da keine Folie b) Datenblatt verfügbar! D.h. mehr Möglichkeiten Jetzt muss ich mich aber um etwas anderes kümmern.
@Christian Hat das L2F50xxx-Display vielleicht auch einen HD66766? Wie hell ist dieses Display im Vergleich zu den anderen? MartinK
Hallo, mir ist kein gravierender Unterschied zwischen den Displays aufgefallen. Beim LPH ändern sich die Farben etwas, wenn man schräg draufschaut, dafür finde ich die Farben etwas satter. Ich habe auch keinen grossen Helligkeitsunterschied festgestellt. Die LPH LED forward-voltage ist ca. 0.5V höher (bei mir) als beim LS020. Ich betreibe die Displays aber auch mit etwas mehr als 20mA. @André: Danke, mache ich auch nur weil ich am Anfang irrtümlich versprochen habe die Displays sind kompatibel :-) @MartinK: Das L2F50 hat einen EPSON Controller. Die Ansteuerung liegt hier schon, brauche nur noch einmal 1-2h Zeit...
@Christian: Weisst Du welche EPSON controller drauf ist? Ich glaube es nicht der HD66766 sondern der HD66773, ich habe die register nochmal gecheckt. Grüße Mark,
Hallo, hab gerade eben diesen Thread entdeckt. Super sache! Ich hab mit die Seite von Christian angesehen, dabei ist mir folgende Frage eingefallen: Kann ich die 10,4V für die Hintergrundbeleuchtung aus dem Power-Booster des LCD-Controllers abziehen? Meint, hat der Booster reseven, sodaß er auch diesen Strom noch abzapfen läßt? Würd die Ansteuerplatine erheblich vereinfachen. abo Mario
@Mario Die Spannung vom Booster beträgt etwa 12,5 Volt (LPH Display). Wenn ich die LEDs daran anschließe, liefert dieser nur einen sehr geringen Strom von etwa 0.4 mA, also viel zu wenig. MartinK
@Mark Ich bin an einer solchen Platine interessiert und bitte um Info, sobald es Neuigkeiten in Bezug auf Preis und Lieferzeit gibt. Vielen Dank. Gruss, Ralf
Ist es nur die Platine oder mit Display? Ja und der Preis wäre gut.
Hallo Mark, --> Soll noch etwas mit drauf? - Joystick, siehe Butterfly Board - PS2-Tastatur Eingang - SD-Card Steckplatz
Vielleicht 7 Tasten zur Steuerung, es soll ja bezahlbar bleiben, verschiede Versionen mit Joystick und SD-Slot, gibts den auch als Bausatz? Vielleicht noch Version mit einen ATMEGA µC und SD-KArte.
@Mark, ich glaube an so einer Platine gibt's viele interessierte. Mit einer SD-Karte und der Java nanoVM hätte man dann ein richtig tolles und günstiges Kleincomputersystem, vorallem mit Farb-Display :)) Zudem gibt's dann sicher genügend freiwillige die fleißig daran herumbasteln. Ich habe mir jedenfalls soeben von Cellow ein so ein Display geordert. Mal sehen wann es da ist. Gruß Mario
Ich will ne Kaffeemaschine mit drauf haben!
@Mark ich wäre schon ganz zufrieden damit, wenn auf der Platine die Levelshifter und der Spannungsconverter für die 2,9V drauf wären. kannst dann mal bescheid sagen, was die platine kosten würde. mfg Kay
@Mark Denke auch, daß die nötigsten Komponenten reichen (2,9V-Regler, Levelshifter) vielleicht noch der Konverter für die HB. @ChristianK Mein LCD leuchtet zwar grün, aber kein Text ist zu sehen. Nur bunte Balken in der ersten Pixelreihe. Wird wohl noch ein Timing-Problem bei mir sein. Dein Quellcode definert kein F_CPU (wird für delay_ms() benötigt). Der Compiler setzt zwar als default 1000000UL, aber das klappt nicht immer. Wenn ich die Optimierung ausschalte (OPT=0), funktioniert das LCD nicht (kein Init). Auch ein wenig seltsam. Aber ich arbeite dran. Grüße, AK
@André Bei mir läuft die Ansteuerung (grünes Display) einwandfrei sowohl bei 1 Mhz als auch 8 MHz, obwohl ich Christians originale Hex-Datei (16 MHz) zum flashen genommen habe, ohne sie neu zu compilieren. MartinK
Hallo, Hat jemand schon das EPSON (L2F50126) display getestet? Das LS020B8UD06 hat glaube ich denn LR38826 controller drauf. Wenn mann sich seite 14 vom Datenblatt vom LQ022B8UD04 display ansieht, erkennt mann die kommandos wieder. Ich habe das Datenblatt vom LR38826 noch nicht gefunde, nur einen übersicht. Grüße Mark,
kurze frage: wo finde ich bei reichelt einen 2,9V regulator ? mfg Kay
Hallo Mark, einige Kommandos scheinen gleich zu sein -> Also ist Sharp der Hersteller :-) Nur die wichtigen Kommandos wie wie VRAM writing stimmen nicht. Aber: Du bist nahe dran, hast du noch mehr von Sharp?
Hallo Christian, Leider (noch) nicht, hast Du denn Epson schon getestet? Anfrage bei sharp hat noch nichts gebracht, anfrage bei epson lauft. Grüße Mark,
@Kay: versuchst mal mit LM317 kann man die Spannung mit 2 Widerständen einstellen. Datenblatt gibt bei reichlet
Hi, so. Mein LCD geht mit dem Code jetzt auch. Der Fehler war nicht in der Ansteuerung selbst, sondern mir scheint der AVR-GCC noch nicht ausgereift genug zu sein. Erklärung: - Sobald der Code mit 'OPT=0' kompiliert wird läuft er bei mir nicht. - Bei 'OPT=3' werden Warteschleifen wegoptimiert. Sind zwar simple for-schleifen ohne Inhalt, aber kein Grund es zu übertreiben. - Nur einige Zeichen gehen (wohl Zugriffsprobleme bei großen Arrays) Ich habe für die Änderung an den ATmega8515 nur die Portpins (funktioniert, da Ansteuerung geht) und das Compiler-Ziel (MCU) angepaßt. Zusätzlich hab ich noch ein F_CPU gesetzt, was aber wohl nicht unbedingt nötig ist (Wartezeiten sind da wohl nicht so kritisch). Entweder mach ich was falsch, oder das Teil ist für den ATmega8515 nicht zu gebrauchen. Grüße, André
Hallo Andre, der Code war nur als einfaches, sofort zu verstehendes Beispiel gedacht, daher liegen alle Daten (ASCII sowie Display) im RAM! (Denn dar AVR braucht spezifische (non ANSI) Befehle für den Zugriff auf den Program-Speicher. Ich kenne den ATmega8515 nicht, aber ich vermute, du hast zu wenig RAM. Daher solltest du die ganzen Arrays in den Program-Space verschieben. Wie das geht steht sehr gut hier im AVR-GCC Tutorial beschrieben. Vielleicht sollte ich den Beispielcode dementsprechend ändern....
Hi, danke aber nicht nötig. Denke Du hast Recht mit dem Problem. Das sollte aber vom AVR-GCC erkannt werden und - entweder Abbruch mit Fehler - oder die Daten ins .cseg und mit LPM zugreifen. Naja. Vielleicht lese ich erstmal ein wenig und übe, bevor ich den Thread mit Sachen zumülle die nichts mit der LCD-Ansteuerung zu tun haben ;-) Grüße, André
@Christian Betrifft LS020-Display Ich habe eine einfache Ansteuerung in Bascom geschrieben. Dabei habe ich festgestellt, dass ohne die beiden Befehle EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm nichts erscheint. (in deinem Asm-File steht dazu: I think not necessary...) MartinK
@Christian Außerdem habe ich festgestellt, dass die Zeit zwischen Init2 und Init3 zwar eine Mindestzeit von etwa 7 ms haben muss, doch die Maximalzeit ist unbegrenzt (1 Sekunde funktioniert bei mir noch) MartinK
Hallo MartinK, zur Mindestzeit: ich könnte mir vorstellen, dass es daran liegt, das es jetzt 3-Init Sequenzen gibt (am Anfang hatte ich nur 2). Der Display reset 0xFDFD war vorher wohl noch nicht sauber gelaufen. Jetzt kannst du das ja mal ausprobieren :-)
Hallo Leute, hab das PDF ein bisschen erweitert. Falls irgendwo Fehler drinn sind bitte mir sagen. Gruss Lightning
Hallo Lightning, Der Controller ist der HD66773 und nicht der HD66766. Kannst du nocht die init für das LPH88 display hinzufügen? Grüße Mark,
Kann das sein das das LS020 am meisten bei Ebay verkauft wird ( gelbliche Platine ) und der LPH88 ein auslauf Modell ist das L2S50 sieht man auch ab und zu. Frage: Aber ich es jetzt richtig verstanden das , nur der LPH88 im Moment läuft? Wie weit seit Ihr mit den anderen? Ich ohne bedenken LS020 kaufen oder erstmal abwarten? Für welche Displays kann man verwenden. Bitte - gebt bei den Posts an welches Display ihr meint , sonst kommt man ja durcheinander. Gute Arbeits Jungs!!!!
@Mark de Jong Ist die INIT für das LPH88 Display die mit den 3 einzelnen Inits ?? ~ Lightning
@ Dirk: Den mehr oder weniger aktuellen Stand findest du hier: http://www.superkranz.de/christian/S65_Display/DisplayIndex.html Grüße Christian Im Moment ist das LPH88 und LS020 supported. Das L2F50 hoffentlich bald. Die GLCD gibt es derzeit nur für das LS020, ein gleichwertiger Port für das LPH88 ist einfach möglich. Für das L2F50 könnte es schwieriger werden, da es anscheinend keine Addressierungs-Modi unterstützt.
@Mark de Jong:
>HD66773 und nicht der HD66766
Wieso denkst du es ist das HD66773? Hast du die Specification davon?
Wenn ja würden mich die Grafik-Befehle interessieren bzw. ob sie sich
vom HD66766 unterscheiden.
Die Grafik-Befehle die ich benutze sind zum HD66766 kompatibel.
Grüße
Christian
Hallo Christian, Wenn mann die init anschaut schreib er auch zu register 0x0D und 0x0E beim init. Die gibt beim HD66766 nicht, aber beim HD66773 schon. Deshalb glaube ich das es der HD66773 ist. Grüße Mark,
@Mark de Jong Wenn ich die INIT für den LPH88 auch ins PDF reinschreiben soll muss ich wissen welche Init das ist. Jetzt sind auf der Homepage vom Christian Kranz da auf einmal 3 einzelne Inits. Warum ?? Hab ich was verpasst ?? Gruß Lightning
@Lightning: Am besten wartest du, bis alles 100% deutlich ist. Grüße Mark,
@Mark de Jong Ja ist wohl das beste. Wenns soweit ist poste ich dann das neue PDF. Gruß Lightning
Hallo, Ich schreibe gerade an meine software library die ich auch frei verfügbar machen werde (pre-beta, längst nicht alles ist drin). Ich schreibe sie für denn MSP430 (IAR Embedded Workbench), er soll aber auch für denn Atmel werden (brauche jemand der dabei hilft). Ich werde das font-tool von Ape benutzen. Der low-level treiber ist für pin toggle und SPI-hardware ausgelegd. Grüße Mark,
Hallo, Ich plane zwei Platinen: 1. Minimal platine (fertig für produktion): - mit oder ohne display lieferbar. - +3.3volt oder +5 volt eingang. - Spannungs regler für 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - Level wandler für signale. - 10 polige stifleiste mit 2,54mm abstand. - etwas größer als das display. - größe 40mm x 60mm 2. MMI platine (in arbeit) - nur mit display lieferbar. - 5 volt eingang. - MSP430F15x/MSP430F16x/MSP430F161x microcontroller. - JTAG anschluss. - I2C anschluss mit pegel anpassung. - RS232 V24 anschluss. - bis zu 64Kbytes EEPROM (smd) - Spannungs regler für 3.3 volt und 2.8 volt. - Spannungs regler für hintergrundbeleuchtung, PWM geregelt. - 2x 4 taster neben display. - 5 tasten unterhalb display (in kreuz). - größe 60mm x 90mm. Sobald ich preise und lieferzeiten weiss melde ich das auch hier, und auf meine homepage (www.mdejong.de) Die software library und alle iinformationen für die displays wird auch auf meine homepage zum download verfügbar sein. Grüße Mark,
Könnt Ihr in eure Programm Dateien auch reinschreiben für welchen Display damit man bescheidweis wenn man mal die Lib tauschen will. Ich bin mal gespannt auf die Preise :-/
Kurze Frage zur Spannungsversorgung: Weiter oben im Thread steht, dass der 1V8 Eingang auch 2V9 verträgt. Im Datenblatt zum HD-Controller hab ich gesehen, dass der alles im Bereich von 2.2 bis 3.3V verträgt. Ich vermute mal dass das für alle Controller die hier im Einsatz sind gilt. Ist der Level-Shifter + Spannungswandler überhaupt nötig, oder spielt da das LCD-Panel auch eine Rolle? Mario
@Mark: "Sobald ich preise und lieferzeiten weiss melde ich das auch hier, und auf meine homepage (www.mdejong.de)" Nicht, daß das so hängenbleibt wie andere unvollendete Projekte von Dir. Auf die LCD-Platine zum 640er warten wir bis heute trotz vollmundiger Ankündigung...
Hallo Andi, Wie du auf meine homepage sehen kannst ist der platine jetzt lieferbar. Ich mache das alles alleine und neben meine eigentliche arbeit deshalb dauert es manchmal länger. Die hardware entwicklung ansich ist nicht das Problem. Die testfase kostest viel zeit (Platinen machen lassen, bauteile besorgen, aufbauen, testen....) , ich biete keine ungetestet hardware an. Auch das schreiben von der doku nimmt viel zeit in anspruch. Ich möchte das meine Produkte für jeder zu benutzten sind, also keine "bastellösungen". Ich bin auch jederzeit bereit fragen zu beantworten (per email oder telefonisch). z.b. Das suchen welche controller auf die displays benutzt werden hat viele stunden gekostet, ich habe viele stunden verbracht im internet zu suchen und datenblätter zu lesen. Dies soll keine entschuldigung sein, sondern nur eine erklärung :-) Ich beschwere mich auch nicht, es ist eine hobby für mich. @Mario, Du hast recht das steht im datenblatt vom controller, aber wir haben kein datenblatt vom LCD-Panel, deshalb gehen wir auf nummer sicher und benutzten nur 2,9 volt. Der level-shifter is "notwendig" um die signale zum controller richtig zu haben (die flankensteilheit, etc.) Grüße Mark,
Hallo André Kronfeldt und den rest der Leser. Ich hab mal eine Frage an gerichtet André, du sagtest oben das du dein Display mit einem Levelshifter 74HC573 ansteuern wills, meine frage dazu hat dies Funktioniert und wie hast du diesen angeschlossen. Vielen Dank Holger
Ist es eigentlich möglich die Lib noch um eine Funktion zu erweitern um Dreiecke zu füllen? Damit könnte man dann beliebige Polygone zeichnen da sich ja jede Form in Dreiecke zerlgen lässt.
@Holger: Ich hab dann doch lieber 10 Widerstände genommen. Der 74HC573 hat entgegen seinem Dateblatt die Ausgänge auf 3,3V gelegt (angeblich maximal VCC+0,5V). Wurde extra mit 2,4V versorgt. Ging aber nicht. Ich hab das bislang aber nicht weiter verfolgt, werde mich aber mal bei Gelegenheit dran machen. Grüße, AK
@Andi, ich muss mich Mark anschließen. Es ist das Forum für Hobbyasten und Bastler, das ist weit weg vom Komerziellen. Da gibts andere Seiten, beipielsweise www.display300.com. Ich denke aber mal, dass Dir das sowieso klar ist und du Mark nur motivieren wolltest damit die hier interessierten daran auch zu der Platine kommen. ICh denke er tut in seinem Rahmen des möglichen das beste ... @Mark: Ich werde mich mal bzgl. LCD-Panels schlau machen. Ich denke die werden sowieso über den internen Booster angesteuert, der wiederum die Spannung über die interne Referenz erzeugt. Aber der "auf Nummer sicher" Ansatz klingt überzeugend :) Mario
@André ein normaler HC573 hat an seinen Eingängen ESD Schutz-Dioden, die dafür Sorgen das Überspannungen an den Eingängen auf die Versorgungsspannung abgeleitet werden. Wenn du nun an den Eingängen höhere Pegel hast als die Versorgungsspannung des ICs, wird die Versorgung über die Eingänge hoch gezogen. Da der AVR recht kräftige IOs hat stellt sich dann eine entsprechend höhere Spannung ein. Deshalb steht ja auch in den Absolute Maximum Ratings als Maximum Input Voltage VCC... Ein Level Shifter wie z.B. ein HC4050 ist dafür ausgelegt an den Eingängen höhere Pegel als die Versorgungsspannung zu haben.
@Fabian Danke. Das kommt davon, wenn man nur die Hälfte liest. Einen HC4050 hab ich wohl noch hier. Ich teste das mal. Grüße, André
@Fabian bei mir im Datenblatt ist für den HC4050 aber auch VI DC Input Voltage -0.5 to VCC + 0.5 V (Maximum) VI Input Voltage 0 to VCC V (RECOMMENDED) angegeben und in der CIRCUIT SCHEMATIC auch zwei Schutzdioden (allerdings gestrichelt).
Also bei TI steht im Datenblatt: "The HC4049 and HC4050 are fabricated with high-speed silicon gate technology. They have a modified input protection structure that enables these parts to be used as logic level translators which convert high-level logic to a lowlevel logic while operating off the low-level logic supply. For example, 15-V input pulse levels can be down-converted to 0-V to 5-V logic levels." Ausprobiert hab ich die aber auhc noch nie.
Hallo, Wegen die pegelwandler hier ist mein schaltplan für die Platine. Ich benutzte denn 74LVC1T45 und 74LVC2T45 von TI. Grüße Mark,
"Dies soll keine entschuldigung sein, sondern nur eine erklärung :-) Ich beschwere mich auch nicht, es ist eine hobby für mich." Wenn das ein Hobby ist, wieso dann eine Umsatzsteueridentnummer? Im Übrigen ist der Bestellvorgang nicht gesetzeskonform. Wenn man nämlich die AGB bei der Bestellung anklickt (Der Link hinter dem Haken), dann führt der ins Leere. Die AGB werden also nicht Bestandteil des Kaufvertrages. Wenn man die AGB links anklickt, so kommen hier nicht gesetzeskonforme AGB zu Tage. Portkosten sind nämlich ab einem Bestellwert von 40 Euro in jedem Fall vom Verkäufer zu erstatten. Auf jeden Fall solltest Du an der Webseite arbeiten, sonst kann das schnell teuer werden.
@Mark: > Wenn mann die init anschaut schreib er auch zu register 0x0D und 0x0E > beim init. Die gibt beim HD66766 nicht, aber beim HD66773 schon. Ich find die beim HD66773 aber auch nicht. R0Bh (Seite 35) ... R0Fh (Seite 37) ...
@Andre, Aber auf seite 27 :-) @Andi, Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby ist. Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht davon lebe (kann). Grüße Mark,
@Mark: Japanische Reihenfolge ist schon seltsam. BTW: Natürlich hab ich nach 'R0Ch' gesucht, ging aber nicht.
@Christian Habe gerade gesehen, dass du die Ansteuerung für das L2F50-Display fertig gestellt hast. Hast du vielleicht ein Datenblatt des Controllers gefunden, weil du so detailiert die Befehle beschrieben hast. Besonders interessant finde ich, dass es eine 18-Bit-Farbdarstellung gibt. Bedeutet das, dass dieses Display das Beste von allen Dreien ist? Oder welches Display würdest du empfehlen? (in Bezug auf Bildqualität, Helligkeit, Ansteuerbarkeit) MartinK
Hallo, Das ist ein Controller von EPSON, wie der S1D15G10 (132x132pixel). Jetzt brauchen wir nur noch das richtige datenblatt. Grüße Mark,
Hi, ich hab mal eine Frage zu der generellen SPI-Kommuniktation. Laut Datenblatt (S55) wird CS* auf low gezogen um das LCD zu selektieren. Dann werden die Daten (Kommando, Parameter) übertragen. Danach CS* wieder auf high. Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur nach der Übertragung kurz auf high gezogen. Woran liegt das? Grüße, AK
"Mann braucht einen Steuernummer zum verkaufen, Auch wenn es ein hobby ist." Das ist falsch. Entscheidend ist die Gewinnerzielungsabsicht. "Auch ein gewerbe kann ein hobby sein, ich meine nur das ich nicht davon lebe (kann)." Das ist etwas anderes, wenn die Umsätze zu gering dafür sind. Entscheidend ist, wie gesagt, daß Du damit Gewinne erzielen möchtest.
@Jochen & Andi abgesehen davon, daß einem in diesem Land bestimmt sofort 'Gewinnerzielungsabsicht' vom Finanzamt unterstellt wird sobald man versucht einen alten Kaugummi loszuwerden, halte ich die Diskussion über den Shop in diesem Thread für unangebracht. Nicht bös sein, aber ich denke es geht hier um das S65-LCD und um die Ansteuerung (von mir aus auch um Bauteilbeschaffung). Grüße, André
@Andre: Da hast Du völlig recht, also ENDE. Grüße Mark,
Hallo Andre, >Laut dem Code von ChristianK ist CS* die ganze Zeit low und wird nur >nach der Übertragung kurz auf high gezogen. Das stimmt so nicht. Schau dir den Code nochmal genau an. Im übrigen unterscheidet sich die CS Steuerung bei jedem Display Typ. Es gibt aber auch bestimmt andere CS Steuerungen die zum Ziel führen, als die aus meinem Code. Allen Display's gemein ist (hoffentlich, noch nicht getestet) dass sie den SPI Bus ignorieren wenn CS=high ist. Grüsse Christian
@Christian, Hast Du das richtige datenblatt vom EPSON controller? Wenn Ja, kannst Du das Posten? Grüße Mark,
@Christian: Es geht hier um das LPH. Nach einem port_init() ist CS* low. Im lcd_init_c() wird erst ein Reset (CS*=1) durchgeführt und dann das LCD selektiert (CS*=0). Soweit okay. Dann kommen die Daten per comtype() oder comdat(). Nach dem Senden wird CS* auf high gezogen. Da komm ich noch mit. Aber warum geht es danach wieder auf low? Vor allem, weil Du es am Ende von lcd_init_c() wieder setzt. Das Setzen ist okay (LCD nicht selektiert), aber der zusätzlich Impuls scheint mir unnötig, oder? Kann aber auch sein, daß Du versuchst das LCD default-mäßig zu selektieren um mehrere Befehle hintereinander zu senden. Dann ist natürlich klar, daß du am Ende von put_char() und lcd_init_c() das LCD wieder abwählen mußt. Trickser ;-) Ich denke aber auch, daß der BUs ignoriert wird, wenn CS*=1 ist. Gruß, AK
@Mark: Nein, ich habe kein passendes Datenblatt zum Epson Controller. Wäre schön wenn du das irgendwie besorgen könntest ;-) Die Commands sind aber ähnlich zu anderen Controllern (z.B. der 132x132) und die die benutzt werden passen auch soweit. Andere, die bei mir noch in der #define Liste stehen, aber nicht benutzt werden, z.B. DISPINV, scheinen nicht zu funktionieren. Ich habe aber noch nicht alles (viel) ausprobiert. Hoffe das die SLEEP Commands funktionieren. Grüße Christian
@Andre, schau mal in das HITACHI Datenblatt. Da steht etwas zu den CS Flanken. Z.B. muss es zu Begin und Abschluss der commands gewisse Flanken geben. Grüße Christian
@Christian Hast die 18-Bit-Farbenzahl beim L2F50-Display schon ausprobiert? (bezieht sich auf deinen Kommentar im C-File) MartinK
Hallo, auch ich hab mal eine Frage in wie fern ist es möglich zwei Displays über einen Mikrocontroller zu steuern, muss man dazu im Code viel verändern? Mfg Thomas
@Thomas Wenn ich mich nicht täusch, sollte es reichen wenn man getrennte CS* Signale auf jedes Display legt. Der Code ist dann fast derselbe (bis auf die Anstuerung des CS*).
@MartinK könntest du mir bitte dein Beispiel in Bascom mal zukommen lassen ? mfg Kay
@MartinK: > Oder welches Display würdest du empfehlen? (in Bezug auf > Bildqualität, Helligkeit, Ansteuerbarkeit) Weiter oben im Thread findet man: >Mir ist aber aufgefallen, dass das LS020-Display wesentlich >heller ist.... Außerdem scheint das LS020-Display gleichmäßiger >beleuchtet zu sein. Aha, aber trotzdem würde ich die LPHxx Display (die grünen/blauen) aufkaufen wenn ihr sie los werden wollt.... Grüße Christian P.S: Die LPH's lassen sich nämlich laut Datenblatt (noch nicht probiert) erheblich flexiber programmieren. Es gibt praktisch alle Addressierungsarten, so dass z.B. ein Port der glcd in allen Rotationen einfach möglich sein wird. D.h. das LPH Display eignet sich dann sehr gut zum Quereinbau (längs). Bei den anderen beiden Displays ist dazu mehr Portierungsaufwand erforderlich. Die Bildqualität ist bei allen recht ähnlich, die Qualität der Beleuchtung wohl beim LPH am schlechtesten, L2FS und LS020 sind ähnlich. Meiner Meinung nach macht das L2FS Bildmässig overall den besten Eindruck, auch was die mechanische Qualität angeht - ist aber derzeit von der Programmierung her am wenigsten flexibel. Beim LPH kann man sich sogar noch ein Interface-Signal (RS) sparen. Also zusammengefasst derzeit meine private Rangliste: a) LPH b) LS020 c) L2FS
Christian, reagiert deine step-up 10V Quelle empfindlich auf die groesse der Induktivitaet ? Ich habe eigentlich KEINE Ahnung von dem analogen Gebimsel und habe hier noch ne 1mH Festinduktivitaet rumliegen und hoffe, man kann das mit einer Anpassung des PWM Signals ausgleichen. Ich gehe mal davon aus, dass der Transistor- und Dioden-Typ eher nebensaechlich sind, oder ? (dachte an BC546 + 1N4148). Daz
@The Daz Ich würde lieber bei einer Schottky-Diode bleiben.
Hallo, ich habe im eBay ein bischen herumgesucht und bin auf das SX1 gestoßen. Ich weiß, dass dass hier nicht so richtig passt. Aber ich vermute, dass dieses Display (ist etwas größer) ähnlich in der Ansteuerung ist wie dieses hier. Hat dazu schon jemand eine Idee. Hier die "Daten" vom Display: Display (genutzte Fläche) 35 x 44 mm (176 x 220 Pixel, 65.536 Farben) Das Teil gibts für ca. 15.- bei eBay. Zu meiner Level-shifter Frage von vorhin. Nachdem ich mich versucht habe so gut wie möglich schlau zu machen, bin ich auf folgende Versuchsanordnung gestoßen: Das Display anhängen und langsam die Spannung schrittweise von 2.9V bis 2.2V verringern. Ändert sich nichts (Kontrast etc.), so sollte dasselbe auch für höhere Spannungen gelten, d.h. das Display kann innerhalb der Controller-Spezifikation betrieben werden. Von der Theorie her (Flüssigkristalle etc.) sollte das auch für das Panel nicht kritisch sein. Desweiteren scheint der Controller seine LCD-Treiberspannungen von der (internen) Referenz zu erzeugen wie es das Blockschaltbild darstellt. Welche internen Spannungen hat das S65? Mario
Hallo Mario, Das SX1-display habe ich ach schon gesehen, aber das hat glaube ich einen 40 polige connector. Grüße Mark,
Soweit ich das auf den eBay Bildern erkennen konnte scheint der Connector 18 Pins zu haben... Das spricht jedenfalls für ne paralelle Schnittstelle. Macht auch Sinn, bei 176*220 Pixeln und 16 Bit ist ein Bild stolze 77440 Byte groß. Bei einer SPI Schnittstelle mit 8MBit würde man für ein Bild im Idealfall 74ms brauchen bzw. 13,5fps schaffen. In der Praxis wäre das ganze noch wesentlich langsamer, da die Daten ja erstmal generiert werden müssen. Überhaupt sind AVRs für diese Auflösungen meiner Meinung nach nicht mehr wirklich geeignet, und die hohe Auflösung ist denke ich auch einfach überflüssig. Zu JPEG- oder Video-Anzeige sind AVRs glaube ich selbst bei noch so effizienter Programmierung nicht mehr in der Lage :) und sonst wüsste ich nich wofür man die vielen Pixel noch gebrauchen kann. Für die größeren ARMs könnte so ein Display schon eher handhabbar sein, aber die Anwendung fehlt immernoch. Vielleicht ein selbstbau Video Player mit TI DaVinci :D
@Fabian Thiele Also mein Anwendungsfall wird ganz klar GinaSisters oder Tetris ;-) Mittlerweile kann mein LPH Hardware-Scrolling und am Wochenende werde ich die guten alten 'Sprites' oder 'Blobs' realisieren. Meine Frau fragt mich zwar nach dem Sinn, aber ich hoffe ich werde nicht entmutigt ;-) Der Code von ChristianK ist mittlerweile auch nach Assembler übersetzt und ein wenig optimiert. Die Datenaufbereitung fällt fast nicht mehr ins Gewicht. Ich hoffe nur, daß bald die bestellten ATmega128 kommen, der ATmega8515 wird langsam eng (SRAM-mäßig). Das momentan angebundene Dataflash ist zu langsam. Grüße, AK
Bascom-Ansteuerung für ein LS020...-Display http://www.xmail.net/martin-k/display.htm Benötigt wird eine neuere Bascom-Demo-Version, die auf 4 kB Codegröße limitiert ist. MartinK
@The Daz:
Der Supply Boost ist nicht sehr empfindlich. Kannst also ruhig mit der
1mH Spule starten. Empfehlung ist erstmal mit einer kleinen pulse-weite
anzufangen und dann langsam hochdrehen...
Weiterhin empfehle ich für's Lab/Bastellkeller einen
Überspannungsschutz vorzusehen. Wenn z.B. mal das Display - bei
anliegendem PWM Signal - nicht angeschlossen ist, wird sich der
Spulenstrom einen anderen Weg suchen. Der ist sonst vmtl. tödlich für
irgend ein anderes Bauteil. Ich habe zwei 5.6V Z-Dioden in Reihe
geschaltet.
Hier die Initialisierung des Timers 2 für die PWM Erzeugung (16MHz ->
62.5kHz PWM Frequenz). (Achtung, die die den PB7 for LCD_RS genutzt
haben - wie ich in meinen Code-Beispielen - müssen den verlegen z.B.
auf PB5) Puls-Weite ist OCR2/256. PWM Ausgangssignal ist OC2 (PB7)
// backlight PWM generation
// use timer 2 in fast PWM mode for this
PORTB &= ~_BV(PB7); // clear port before enable
DDRB |= _BV(PB7); // will be used for OC2, must be output
TCCR2 = _BV(WGM21) | _BV(WGM20) | _BV(COM21) | _BV(CS20);
TCNT2=0x00;
OCR2=120;
Zur Hardware:
Schottky Diode ist wegen besseren Wirkungsgrad (normale geht aber
auch).
Beim bipolaren Schalttransistor den Basis-Vorwiderstand nicht vergessen
;-)
Grüße
Christian
Hy Leute, Hab das PDF wiedermal auf den neusten Stand der Dinge gebracht. Falls Fehler auftauchen oder sonst was ist wie immer bitte melden. Gruß Lightning
@Christian, merci fuer die Info. Hab mir ein LS020 bestellt und werde demnaechst anfangen. @Lightning, daaaanke fuer den update. Endlich kenne ich die genauen Einbaumasse und es sieht so aus, als ob das Display in ein 1HE 19" Gehaeuse passen wuerde.
@Lightning: Denn Update beim PWM backlight hast du noch nicht mit aufgenommen. Wie erzeugst du das PDF? Von Hand? Grüße Christian
Such mal im netz nach PDF Drucker ;) evtl auch nach Ghostprint oder script hiess das tool meine ich Gruss
hi Lightning, wieso gibts das pdf nur in englisch. ich kann zwar englisch, aber in Deutsch würde ich es besser verstehen. gibt es dafür einen besonderen grund ? mfg Kay
Hy Leute, @ Christian Kranz Hab das PWM Update jetzt eingefügt. Zuerst schreibe ich das Zeug im Word und dann nehm ich den Acrobat 7.0 her und mache aus dem Word Dokument ein PDF. @ Kay Bin seit 2 Tagen drann das PDF nach Deutsch zu Übersetzen jedoch hab ich eher wenig zeit daher dauert das n bisschen. Wenn ich die Deutsche version fertig habe, poste ich sie natürlich auch hier im Forum. Danke nochmal an alle. Gruß Lightning
Leicht OT, aber dennoch passend: Verwendet man anstelle von Microsoft Word den OpenOffice Writer, dann hat man den PDF-Export gleich mit dabei. OpenOffice 2.0 (gibt es seit einigen Tagen) ist kostenlos und weitestgehend kompatibel zu den aktuellen Microsoft-Formaten. Von politischen oder religiösen Überzeugungen abgesehen kann ich wenig Gründe erkennen, die gegen eine Migration sprächen.
@Rufus T. Firefly Da ich mich mit Word schon sehr gut auskenne, geht es schneller wenn ich das ganze ein bisschen umständlicher mache, als wenn ich mich jetzt in OpenOffice einlerne. Gruß Lightning
Ich hab mir die Schaltung jetzt mal mit nem ATMega16 @ 16MHz und nem LS020 Display auf nem Steckbrett zusammengestrickt. Fuer die LED Voltage steht bei diesem uC ja nur 62,5kHz (anstatt 200kHz wie im PDF beschrieben) zur Verfuegung. Auf die benoetigten 10,4V komme ich bei mir erst mit ca. 5mH Spuleninduktivitaet und einem Puls/Pause-Verhaeltnis von 52%/48% (OCR2 = 134). Das kleine Demo-Programm (Hello World) scheint auch nicht zu funktionieren, der Hintergrund wird zwar eingefaerbt, aber es ist kein Text zu sehen. Aus diesem Grund habe ich erstmal nur versucht kleine Rechtecke aufs Display zu zaubern. Dabei hat sich herausgestellt, dass die X und Y Koordinaten vertauscht zu sein scheinen. Egal welchen Rotations-Wert ich einsetze, ich muss X und Y vertauschen. Sehr seltsam, werde das nochmal genauer untersuchen. Ansonsten bin ich bisher ganz zufrieden mit dem Ergebnis. Vielen Dank an Christian und Mark. Good job ! Daz
@Daz: Backlight: Ich benutze 820µH mit 62.5kHz mit n-channel FET und schottky diode. -> funktioniert tadellos, Helligkeit lässt sich über pulse weite sehr gut einstellen, auch extrem hell (und vmtl. weit ausserhalb der LED Spec.) Kann sein dass das an deinen nicht optimalen Bauteilen (bipolar Tr. 1n4148 liegt) Hello World: Schiebe mal die komplette ASCII Tabelle in den Flash Speicher. Ich vermute du hast ein SRAM Problem... (Als Beispiel kannst du dir den Code vom EPSON Display ansehen oder GCC tutorial oder du weisst das sowieso) Gruesse Christian
Christian, dachte ich zuerst auch. Habe deshalb auf FET und Shottky-Diode umgestellt und damit ueberhaupt erst ein braucgbares Ergebnis erziehlt. Die angegebenen Werte beziehen sich daher auf die FET/Shottky Kombination. Ich will nicht ausschliessen, dass der Aufbau auf dem Steckbrett seinen Teil dazu beitraegt. Die ASCII-Tabelle ins Flash zu schieben werde ich heute abend mal ausprobieren. Danke fuer den Tip. Daz
Jo, den Font ins Flash zu verlegen hat das Problem mit der Anzeige des 'Hello World' Strings gefixt. Bleibt nur noch die Sache mit den vertauschten Koordinaten. Aber da scheint es, als ob das Beispiel-Programm mehr weis als das PDF Dokument. Bei 0° Rotation vertauscht die put_char Routine nämlich auch die Koordinaten und schon stimmts wieder. Daz
Angehängte Dateien:
-
Display.jpg
77 KB
@MartinK hi, hab das display jetzt am laufen. hat sogar auf anhieb geklappt. wenn ich den AVR und das display mit Strom versorge, dann dauert es ca. 20 Sekunden bis das Display voll beschrieben ist. Ist das normal ? liegt es daran, das es keine SPI Ansteuerung ist ? mfg Kay
@Kay Bei mir dauert der Bildaufbau maximal 3 Sekunden bei einer Taktfrequenz von 8 MHz. Natürlich wäre eine Ansteuerung über SPI wesentlich!!! schneller. (Bascom unterstützt SPI-Befehle) Selbst ohne SPI läßt sich mein Code noch optimieren. Ich werde mal sehen, was ich da noch ändern kann. Der Vorteil einer Ansteuerung ohne SPI ist, dass sich jeder Portpin eignet. MartinK
@MartinK ok, habe meinen Fehler gefunden. war ja ein neuer mega8. Da ich mit den megas noch nicht so viel gemacht habe, habe ich vergessen, die FuseBits so umzustellen, das er auf externem Quarz läuft. jetzt dauert der Bildaufbau ca 1-2 Sekunden mit 16 Mhz. ja bascom kann SPI. man könnte ja auch SoftSPI benutzen, dann würde man auch jeden Port benutzen können. Müsste nur in Bascom die Ports für den SoftSPI Port definieren. mfg Kay
@MartinK ich habe mal ein wenig am programm rumgespielt, aber ich blicke nicht durch. ich möchte einfach nur den ganzen Screen Blau malen. Könntest Du mir bitte sagen, wie ich das anstelle ? ( Ich habe versucht, aus dem PDF schlau zu werde, nur dieses Englisch .... :-) ) mfg Kay
@Kay Auf meiner Seite http://www.xmail.net/martin-k/display.htm habe ich das Beispielprogramm aktualisiert. Ich benutze jetzt die Shiftout Funktion, die Ansteuerung läuft etwas schneller. Wenn du nur Blau malen willst, so gehst du folgendermaßen vor: (Code aus LS202-RGB.bas) 'Blau malen A = &HEF90 Gosub 16 A = &H0500 ' 00 => Bild wird von oben nach unten gemalt Gosub 16 A = &H0800 'x1 Gosub 16 A = &H092B 'x2 Gosub 16 A = &H0A00 'y1 Gosub 16 A = &H0B7F 'y2 Gosub 16 EF90, 0500, 08.. 09.. 0A.. 0B.. sind die Grafikbefehle zum Malen eines Punktes oder Ausschnittes. Du musst nur noch die Koordinaten einsetzen. In meinem Beispielprogramm beginnt der Ausschnitt bei x1,y1 = 0,0 und endet bei x2,y2 = 2B,7F (Hexadezimal) = 43,127 Diese Werte kannst du beliebig variieren, jedoch darf x nicht größer als 131 und y nicht größer als 175 sein (0 wird mitgerechnet) Als nächstes folgen dann die Farbwerte für die einzelnen Bildpunkte im 16-Bit-Format RRRRRGGGGGGBBBBB Wenn du also nur Blau malen willst, so hat jeder Punkt den Binärwert 0000000000011111 = 31 Für einen kompletten Bildschirm musst du 132*176 = 23232 mal den Wert 31 senden. Alternativ gibt es die folgende Befehlssequenz: EF90, 0500, 06x1, 07y1 Hier definierst du nur den Startpunkt, der Endpunkt liegt automatisch bei 131,175 MartinK
@MartinK also ich habe das neue Beispiel von Dir ausprobiert. Das Bild baut sich wesentlich schneller auf. Wenn ich das ganzen Screen Blau malen will, dann mache ich es, wie du geschrieben hast: 'Blau malen A = &HEF90 Gosub 16 A = &H0500 ' 00 => Bild wird von oben nach unten gemalt Gosub 16 A = &H0800 'Start 00 Gosub 16 A = &H0983 'Ende 131 Gosub 16 A = &H0A00 'Start 00 Gosub 16 A = &H0BAE 'Ende 174 Gosub 16 Das Display zeigt dann auf der ganzen Breite das Blaue, nur zeichnet es nur 1/4 von oben nach unten. ist an meinem code was falsch ? mfg Kay
@Kay Das letzte Kommando müßte korrekt A = &H0BAF (175) lauten, sonst hast du eine Leerzeile. Dein Problem mit dem 1/4 Bildschirm entsteht bestimmt durch eine falsche Schleife. Versuch mal folgende Schleife: Portc.0 = 0 ' RS auf low setzen für Bilddaten F = 31 'binär 0000000000011111 für Blau For R = 1 To 23232 A = F Gosub 16 Next R Portc.0 = 1 'RS high MartinK
@MartinK also mit der schleife gehts auch nicht. da kommt die Fehlermeldung : Value doesn´t fit into byte ---> bei For R = 1 to 23232 wenn ich keinen farbverlauf will, dann kann ich doch normalerweise nur die schleife nehmen, die du im obern Post geschrieben hast oder ? mfg Kay
@MartinK habs hinbekommen. musste R als Word definieren. jetzt habe ich einen wunderschönen blauen screen. sehr gut. denkst du es wäre auch machbar, Bilder auf dem Display mit Bascom darzustellen ? mfg Kay
@MartinK hast du vor, das display mit Bascom per SPI anzusteuern ? ich denke mir die geschwindigkeit des SoftSPI kann zwar nicht mit dem des Hardware SPI des AVR mithalten, sollte aber dennoch schnell genug sein, um einen kompletten Screen in sehr kurzer Zeit zu beschreiben. Und das gute an SoftSPI ist ja, das man jeden beliebigen PIN als SPI Interface konfigurieren kann. mfg Kay
@Kay: Schreibst Du unter 2 Nicks, oder wieso kenn ich Deinen letzten Post schon: http://www.mikrocontroller.net/forum/read-4-243641.html#257716 ??? Zu Deiner letzten Frage: > denkst du es wäre auch machbar, Bilder auf dem Display mit > Bascom darzustellen ? Was sollte dagegen sprechen? Das ist fast schon wie: Denkst Du ich kann mit dem Messer ein Brot schneiden? Meinst Du Luft ist zum atmen da? War die Frage ernst gemeint, oder rhetorisch? Meinst Du, ob es für DICH machbar wäre? Verlier den Mut nicht, aber ließ bitte ein wenig im Datenblatt. Grüße, -- Outstanding ---
@Kay SoftSPI dürfte das gleiche wie Shiftout sein. Mit Bascom werde ich mich sehr wahrscheinlich nicht weiter beschäftigen, weil ich momentan einen M32C (Renesas) programmiere, und da ist nur C angesagt (obwohl ich Basic eigentlich ganz gut finde) Bilder auf dem Display darzustellen ist kein Problem, schau dir mal in diesem Thread die Artikel von Fabian Thiele (ape) an. Bascom unterstützt ja auch die serielle Schnittstelle. MartinK
@MartinK ich werde mal sehen, ob ich das display mittels C ans laufen bekomme. danke für Deine Hilfe @all habe das Display an einen Mega16 mit 16Mhz folgendermaßen angeschlossen: LCD --------- AVR DAT MOSI PB5 CLK SCK PB7 CS SS PB4 RESET OC1B PD4 RS OC2 PD7 da ich mit C noch nicht viel gemacht habe, würde ich gerne wissen, ob es reicht in der lcd.h die Definierung der Ports zu ändern und in der makefile den mega16 zu konfigurieren ? mfg Kay
@ Kay: Nein das reicht nicht. Die Sourcen gehen davon aus, dass alle LCD Signale an den gleichen Port angeschlossen sind. Also warum nutzt du nicht auch Port B für RESET und RS? Ansonsten musst du die Port-Zugriffe umschreiben
@Simone: habe jetzt den PortB für das Display genommen. DAT = PB5 CLK = PB7 CS = PB4 RESET = PB3 RS = PB2 hab dann in der lcd.h die Pins so konfiguriert und den mega16 im makefile eingetragen. nur leider geht garnichts. ich denke, ich werde den mega16 mal tauschen. mfg Kay
@The Daz: könntest Du mir bitte deinen Mega16 Code für das display zukommen lassen ? mfg Kay
@Kay, Obacht ! Beim Mega16 liegt der PWM (OC2) Ausgang auf PortD Pin 7. Daz
@The Daz, danke für den code. hab meinen mega16 nun genauso beschaltet, wie in der lcd.h beschrieben ( bis auf PWM ). Hab alle Leitungen überprüft. Aber auf dem Display erscheint nichts. Das Display muss aber in Ordnung sein, denn wenn ich das Display mit Bascom programmiere, funktioniert es ( bei Bascom benutz ich nur keinen SPI Port ). mfg Kay
@all wieso wird in der lcd.h MISO definiert ? ich dachte, man benötigt nur MOSI für die Dat Leitung. mfg Kay
MISO ist nur der Vollstaendigkeit halber da, wird aber tatsaechlich nicht gebraucht (Zumindest nicht in diesem Fall). Ich hab selbst hin und wieder Probleme, weil die LCD-Initialisierung nicht hinhaut. Vor allem, nachdem ich den assembler code aus Christians Beispiel noch ein bischen auf performance getrimmt hatte. Das scheint eine enorm Empfindliche Sache zu sein. Vielleicht reichen ein paar zusaetzliche NOPs um das Display bei dir ans Laufen zu kriegen. Nimm vielleicht mal Christians Original-Code, verschiebe den Font ins Flash (PROGMEM) und probiers nochmal.
@The Daz danke für die hilfe. aber ich glaube, ich muss mich jetzt erstmal intensiv mit C beschäftigen, weil ich davon nämlich so gut wie garnichts verstehe. Hab zwar im Tutorial was zu Progmem gefunden, weiß aber immer noch nicht, wie ich den Font ins Flash schieben soll. Sollte es dann doch irgendwann klappen, melde ich mich. mfg Kay
So, wenn ich den SPI double speed mode waehrend der LCD Initialisierung abschalte und hinterher wieder ein, klappt die Sache wunderbar. Der Testaufbau auf nem Steckbrett scheint nicht das Gelbe vom Ei zu sein.
Hallo, ich habe nun endlich auch mein Display (LS020) bekommen. Nachdem ich aber mehr bei den PIC zuhause bin, habe ich Christians *.asm Code versucht zu portieren. Leider hakt es an irgend einer Stelle und ich bin an der Fehlersuche. Dabei bin ich auf ein paar offene Fragen gestoßen. Zum einen erlaubt es der PIC die Clock-Polarität einzustellen (Idle = Low/High), d.h. Invertierung. Zum anderen muss ich angeben, wann die Daten an SDO angelegt werden (Fallende/Steigende Flanke). Desweiteren habe ich nirgendwo gefunden, ob MSB first oder LSB-first gesendet werden muss (vielleicht bin ich auch blind :)). Beides konnte ich aus dem Code und ermangels an AVR-Kenntnissen nicht herausfinden. Auch Martins BASCOM-code hält sich zurück. Sein Shiftout sieht so aus: Shiftout portx.x, porty.y, A, A Dabei sollte lt. Dokumentation gerade der vierte Parameter festlegen wie gesendet werden sollte, der Dritte die Daten, also ?? Ich habe meinen PIC-code (Auszug aus einem größeren Projekt) als Attachment angehängt. Kann mir jemand von Euch helfen? Gruß Mario
Hallo Mario, das SPI musst du beim AVR auch entsprechend konfigurieren -> Datenblatt könnte dir helfen. Aber am besten schaust du dir die Screen-Shots auf der Reengineering Seite an. Da kannst du folgendes sehen: a) MSB first b) Daten anlegen mit der fallenden Clock Flanke (übernahme im Display mit der steigenden) Achte auf die CS Ansteuerung. Die ist kriegsentscheidend. Ist ganz schön blöd vor so einem leeren Display zu sitzen....
Hallo Superuser, danke für die Antwort, damit sind schopn mal einige meiner Fragen geklärt. Das langwierige Durchstöbern der AVR Datenblätter wollte ich mir sparen, das Wissen sollte wohl da sein. Ich habe mich auch an dem Screenshot vom Reengineering orientiert, demach ist die clock-polarity auch festgelegt, nur leider wusste ich nicht ob da eine Invertierung zwischengeschalten ist, bzw. was welcher Leitung entspricht ... (RS/RESET/CS) Der Sarkasmuss am Ende motiviert mich leider nicht, aber stimmt, Fehlersuche ist so ziemlich das nervigste .... Aber eigentlich bin ich auf der Suche nach jemandem der mal schnell einen Blick auf den Source-wirft. Vier Augen sehen mehr als zwei, etc. Und vielleicht gibts auch noch einen anderen, der ausser am AVR auch an einem PIC-code interessiert ist. Mario
Hallo, wie steure ich dieses S65 Siemens Display an? Geht dies über I2C Bus oder SPI Bus? Woher bekomme ich ein Beispiel wie man so was ansteuert? Brauche ich da noch andere Spannungen?
HscH fang am besten mal oben an zu lesen, all deine fragen wurden schon zich mal beantwortet
um zu sehen wie man sowas ansteuert kann man sich die alte glcd library für das Nokia 6100 Display anschauen die war noch in C. Die hatte ich auch mal nach Codevision portiert, aber dann doch mit Winavr angefangen wegen der besseren neuen Library. Ich hab auch mal 3 Displays bestellt und werd mich wohl dran machen die glcd Library in Codevision bzw. ANSI-C kompatiblen C-Code umzuwandeln. Sowas in Assembler programmieren macht kaum noch Sinn, da die Compiler heutzutage doch recht Codeeffizient sind. Die Ansteuerung selbst gibts sowieso keine Geschwindigkeitsprobleme, wenn man icht grade 3D-Ballerspiele programmieren will. Problematischer ist eher der hohe Speicherbedarf für die Fonts. Allein zum Testen reicht normalerweise glcdinit da sollte das Display schon die Farbe wechseln, wenn es erfolgreich war, so zumindest beim Nokia Display
Hi, > Sowas in Assembler programmieren macht kaum noch Sinn, > da die Compiler heutzutage doch recht Codeeffizient sind. Täusch Dich mal nicht. Da der GCC ein Allrounder ist und nicht für den AVR optimiert, produziert er manchmal Code, der ein erblassen läßt. Ein PORTD|=0xFF generiert bei O3 z.B.: in R24, PORTD ldi R24, 0xff out PORTD, 0xff Da haut's einen schon um. Zudem ist gerade sowas wie Scrolling und schneller Bildwechsel sehr empfindlich (Ruckler). Wieso sollte man die GLCD wieder nach C übersetzten? Ich denke die läßt sich problemlos gegen ein C-Programm linken? Grüße, André
Es gab 3 wichtige Gründe warum ich die GCLD in Assembler portiert habe: 1.) ich wollte eine echte Link Library bauen. Das wäre auch in C gegangen, aber wenn man es eh einmal macht dann möchte man ja auch gleich mehrere Vorteile haben, und so kommen wir zu den 2 anderen Vorteilen 2.) die ASM GLCD benötigt für mehr Funktionalität ca. nur 50% an Flash ! Es zeigte sich also sehr wohl das der Mensch bei weitem besser optimiert als der Compiler. Und gerade beim WinAVR GCC sind einige Stellen die er bei weitem besser hätte optimieren können. Ich habe in den letzten 20 Jahren einiges an Compiler benutzt und muß sagen das der GCC bei weitem einer derjenigen ist die nicht so gut optimieren. Diese Aussage soll den WinAVR GCC nicht diskretitieren, denn als eine freie Alternative entwickelt von Enthustiasten ist der GCC eine sehr stabile Entwicklungsumgebung. Die letzendlichen Resultate sind: 4500 Bytes an Code für die alte C Version 2800 Bytes an Code für die neue ASM Version, wobei diese aber auch mehr Funktionalität besitzt. 4500 Byte an Code in der C Version, egal welche Funktionen man benutzt. 600 Bytes an Code in ASM Version wenn man nur die nötigsten Funktionen braucht. 3.) die Performance der ASM Version ist ebenfalls bis zu 5 mal besser. Dies hat 3 Gründe: a) die ASM Version geht mit den Registern und Paramatern wesentlich optimaler um. In C sind defakto alle Parameter immer 16 Bit breit auch wenn man nur uint8_t benutzt. Die Asm Version benutzt nun die unbenutzten Register die durch die Aufrufkonventionen vorgeschrieben sind als lokale Variablen. b) die ASM Version ist so konstruiert das die meisten Aufrufenden Funktionen wissen welche Register in den aufgerufenen Funktionen benutzt werden. Ich habe die Register also so verteilt das zb. sehr wichtige Funktionen immer die gleichen Register benutzen und die übergeodneten Funktionen diese Register nicht benutzen. Ergo: es werden wesentlich weniger PUSH/POPs benötigt. c) viele grafik Funktionen wie Linien/Kreise/Ellipsen und Fonts können in Assembler ganz bestimmte Möglichkeiten der CPU benutzen die so in C garnicht verfügbar sind. So zum Beispiel rechnet die Linienfunktion mit 24Bit Integer statt mit 32 Bit Integern in C. Es macht also aus Sicht der Performance und Resourcenverbrauch sehr wohl einen gewaltigen Unterschied aus. Es gibt aber auch Nachteile: 1.) C ist portabler, und gerade die GCLD wurde nun schon auf den PIC, MSP etc. portiert. 2.) Assembler ist wesentlich schlechter wartbar 3.) Erweiterungen von neueren Displays sind in der C Version viel schneller umzusetzen. 4.) die Trennung von HAL und TopLevel Schnittstellen ist in C einfacher. Gruß Hagen
@Hagen genau ähnliche Argumente sehe ich auch. Der AVR-GCC wird von mir nur für das eigentliche Programm benutzt. Die Libraries (MMC, LCD, ...) sind meistens in ASM und werden gegen den C-Hauptteil gelinkt. So kann man den Vorteil beider Welten nutzen. - Höhere Geschwindigkeit. - Minimaler Code (gerade für kleine AVRs). - Dank des Linkers nur Code, der auch benötigt wird. - Schnelle Entwicklung und einfache Wartbarkeit des C-Hauptteils. Ebenso wie Hagen versuche ich PUSH und POP zu vermeiden, indem die Register optimal ausgenutzt werden. Sind ja genug da ;-) Einer der großen Nachteile ist allerdings die schlechte Portierbarkeit. Da ich mich aber nur bei den AVRs wohlfühle (und selbst die mit ihrem IO-Zugriff etwas konfus sind - Historie?) trifft mich das nicht so. Ein anderes LCD? Einfach eine andere (sowas ist relativ schnell portiert) LCD-Lib linken und gut ist - vorrausgesetzt die Funktionen sind gleich. Zudem frag ich mich, warum der AVR-GCC mit O0 fehlerhaften Code (bezogen auf IO-Funktionen) erzeugt. Aber das steht wohl auf einem anderen Blatt. Er ist jedenfalls für Entwickler der beste Freeware-Compiler (wohl auch der Einzigste, oder?). Wenn man erstmal gechecked hat, daß O2(?) mindestens Pflicht ist, geht der Rest relativ locker von der Hand. Grüße, André
>> Ein anderes LCD? Einfach eine andere (sowas ist relativ schnell >> portiert) LCD-Lib linken und gut ist - vorrausgesetzt die >> Funktionen sind gleich. Tja, wenn man die Libs komplett austauschen kann dann ist das noch ok. Aber im Falle der GLCD entsteht ein spezielles Problem. Die sagen wir mal HighLevel Funktionen wie Fonts, Linien, Kreise etc.pp. graifen optimiert auf spezielle HAL-Funktionen zu. Leider stelen diese eben auch eine Funktionalität extra zugeschnitten auf den Display Controller zu Verfügung und sind in der ASM Version eben nicht strikt von den HighLevel Funktionen getrennt. Das wieder auseinanderzuklabüsern ist doch recht schwierig. Ansonsten ist der WinAVR GCC eine recht passable Alternative zu purem ASM oder eben teueren Compilern. Gruß Hagen
Naja, ich hab auch eigentlich einen richtigen Compiler gemeint. :-) Was da rauskommt ist oft nicht mehr viel zu optimieren. Der Assembler Code ist halt immer schwierig zu portieren.
@Hagen > C ist portabler, und gerade die GCLD wurde nun schon auf den PIC, > MSP etc. portiert. Hast du für den MSP430 einen Link? MartinK
@MartinK: Nein habe ich nicht, ich weis halt durch EMails das einer es portiert hat und wegen par Problemen bei mir nachfragte. Gruß Hagen
Hallo, ich habe gesehen, dass mein Hilferuf bzgl. des PIC-codes zwar noch keinen Hinweis auf einen Fehler gebracht hat, aber vielleicht hat ja einer der den Code heruntergeladen hat das Display zum laufen gebracht damit. Würde heissen, meins ist kaputt, bzw. eine Leitung ist nicht durchkontaktiert (Habs zwar schon geprüft, aber ...). Also Erfolgsmeldungen auch hier posten - schließt für mich eine Fehlerquelle aus - Danke! @Martin: Warum schaut Dein BACOM Shiftout so aus? Shiftout portx.x, porty.y, A, A Vierter Parameter sollte aus {0,1,2,3} sein. A sind aber die Daten? Gruß Mario
Hallo, Nachtrag zu meinem vorangegangenen Post. Ich habe nun die Sourcen nach einer Woche nochmals durchgesehen und entsprechend dem Kommentar von SuperUser angepasst. Die Leitungen (CS, RESET, RS) sollten nun auch soweit alle richtig sein- vorausgesetzt ich kann die *.asm Befehler für den AVR richtig deuten. Auch das SPI-Timing sollte passen. Ein paar andere dumme Fehler sollten nun auch draussen sein. Leider funzts nachwievor nicht. Anbei die neuen Sourcen. Vielleicht funktionieren sie bei jemandem anderen, dann wirds eng für mein Display - also vielleicht doch "tot"? Gruß Mario
Hallo zusammen! Super, endlich hat es geklappt! CKE-war falsch gesetzt. Zusätzlich hab ich noch ein sauberes RESET nach Martin's BASCOM-source eingebaut. Manchmal hilft es einfach zu schreiben das es hakt, dann bekommt man die Idee wo's noch haken könnte. So jetzt überflute ich das Forum nicht mehr mit meinen Problemchen. Gruß Mario
Poste doch mal dein Programm, dann haben alle was davon
Hi, verkauft jemand so ein Grafikdisplay von SIEMENS S65?
Hi, ein gewisser Herr 'eBay' hat sowas von viele. Der gibt bestimmt welche ab: http://search.ebay.de/search/search.dll?sofocus=bs&sbrftog=1&catref=C6&from=R10&sbrbin=t&satitle=s65+%28LCD%2CDisplay%29+-Folie+-Schutz*&sacat=48187%26catref%3DC6&bs=Finden&fsop=3%26fsoo%3D1&coaction=compare&copagenum=1&coentrypage=search&sargn=-1%26saslc%3D3&sadis=200&fpos=Postleitza&sascs=2&ga10244=10425&ftrt=1&ftrv=1
DEAR SALES, I WOULD LIKE TO REQUEST YOUR BEST PRICE AND LEAD TIME TO ORDER 4100PCS LS020 COLOR DISPLAY SIEMENS PLEASE ANSWER ME BACK AS SOON AS YOU CAN. THANK YOU SO MCUH HELLEN PAGANI hellen@netcondigy.com.br 55 11 4996-7205 5511 4996-7203 www.netcondigy.com.br
Das ist mir schon klar, dass ich bei Ebay diese Displays erwerben kann. Aber dort erhalte ich nur Displays ohne Anschlusskabel oder Stecker die zur Platine führen. Ich weiss halt nicht wie ich an dem flachen Kabel was anlöten kann. Deshalb frage ich hier in diesem Forum ob jemand ein Display verkauft, mit dem ich gleich loslegen kann.
An den Displays sind Kontakte im 1,27mm Raster ist ja wohl kein Problem da nen paar Drähte dran zu löten...
@DerMax Doch... es soll ja Leute geben, die SMD per Dachrinnenloeter versuchen zu loeten ;) Gruss
@DerMax, Der abstand ist 1,5mm, nicht 1,27mm @Hsch: Eine Platine(oder Fertiges Modul) wird ab übernächste verfügbar sein. Grüße Mark,
Hi Mark, ja was soll denn dieses Modul kosten? Ist es ein Modul ohne Coontroller?
Hallo, ich habe heute ein LS20xx Display bekommen, wie sieht das mit der Spannungsversorgung aus? Sind 3,3V zuviel oder noch gerade so in ordnung?
Hallo Freaks, Ich habe mal ein bischen recharchiert und da ein Datenblatt von einem TFT Display gefunden was bestimmt den gleichen controller (LR38825+LH169C) drauf hat wie das LS020. Für Cellular Phones werden diese oder aber der LR38826 eingesetzt, die zu dem LS020 passen würden. Nu aber zum Eigentlichen... Versucht mal folgende shut down sequence: 0xEF00,0x1B04,0xFEFE,0xFEFE,0x7E04,0xE304,0xE404,0xE201,0x8000,0xE001,0x 7F01 5µS (MIN) 0xE000,0x7F01 5µs (MIN) 0x0101 Nach der Sequence werden bei meinem Display alle Pixel weiß, und nach Abschalten der Spannungsversorgung bleibt es unverändert (Kein Verschwimmen der Pixel oder so zu erkennn). Scheint also zu funktionieren. Ihr könnt ja mal die Pegel etc. checken ob die Abschaltung auch elektrisch am Interface ok ist. Ich hab dazu jetzt keine Nerven. Ich habe nen Kumpel der bei Sharp arbeitet, vielleicht bekomm ich noch mehr raus. Viel Spaß beim probieren :D Gruß Joedi
@Jens, ich hab mein LS020 gemiiensamt mit dem PIC an eine Lithium-Knopfzelle gelegt - direkt ohne Pegelwandler etc.. Lt. Multimeter (ist nicht sehr genau) ist die Spannung 3,3V. Funktioniert prima. Es gibt da aber ohnehin zwei Spannungen. Der Logik-Pegel wird auch in Christians Schaltung von 1V8 auf 2V9 gelegt. Die meisten Controller Vertragen aber bis 3.3/3.6V. Den 2V9 sollte man nicht über 3.3V anheben (lt. Kommentar in Martin's BASOM Source). Warum, wieso?? @ThJoedi, danke. Werde mal ausprobieren ob es funktioniert. Kannst Du die Datenblätter zu den Controllern ins Forum stellen? Gruß Mario
sollte natuürlich "gemeinsam" heissen und nicht ... ja was auch immer.
Hallo! Kennt einer einen Seriösen eBay oder normalen Shop? Suche schon seit zwei Wochen nach einer guten Quelle. Habe aber nur abzocker gefunden. Brauche 8x Stück für mein Mischpult. www.ucapps.de mfg KennyOswald
MartinK >>EF90 0000 nach der Initialisierungssequenz auf dem Bildschirm >>nichts erscheint. (in deinem Asm-File steht dazu: I think not >>necessary...) Genau dieser Fehler hat mich auch ein paar Stunden Fehlersuche gebracht!!! Mein Display ist ein LS020B8UD05 (braun) und hat ohne EF90 0000 am ende der Init auch nichts angezeigt. ##################################### Könnt man im PDF mal drauf hinweisen. ##################################### Nebenbei nutze ich das Display an einem MSP430 bei 3V, noch per Soft-SPI. Vielen Dank allen die es mir ermöglicht haben dieses Display zu nutzen, besonders Christian!
@Rainer Verstehe ich nicht. Meinst du den original Code? Da steht zwar der Kommentar, aber die Sequenz wird trotzdem zum Display gesendet. Wie kommt es zu diesem Fehler?
@Superuser ich habe meinen eigenen Code für den MSP430 geschrieben und zwar nach dieser Seite: http://www.superkranz.de/christian/S65_Display/DisplayProgramming.html Dort fehlt hinter INIT3 das "EF90 0000", ebenso in dem PDF das ich hier mal runtergeladen habe.
@ThJoedi Die shut down sequence funktioniert bei mir. Allerdings liegt danach der Stromverbrauch noch bei etwa 50 uA. MartinK
Hy Leute, Hab das PDF Upgedatet also es ist jetzt wieder auf dem neusten Stand. Auch das mit dem "EF90 0000" am Ende der INIT3 wurde korrigiert. Mfg. Lightning
Hallo, kann mal einer die Dicke des Displays ausmessen? (inkl. Kunststoff-Teil). Die Gesamtmaße habe ich aus dem Bild auf Christians Seite rausgemessen: Über alles: 39 * 56mm Aktives LCD-Feld: 31 * 42mm Vielen Dank, Stefan
@Stefan Kleinwort Die genauen Maße stehen ja im PDF. Die Dicke ist 3,60 mm Mfg. Lightning
@Lightning: Vielen Dank! Ich hatte natürlich nur im alten pdf geschaut ... oh mann ... Gruß, Stefan
@MartinK: Mit der Power down sequence wird ja bestimmt nicht der ganze controller abgeschaltet sondern nur die LCD glass driver. @All: Der Controller des LS020 ist ein Sharp LR38826. Die power off sequence ist vom LR38825+LH169C. Es könnte sein dass einige register miteinander komatibel sind. Ich bleibe dran.....
Hab mal angefangen mit der Initialisierung mit dem AT91SAM7 aus dem Oszi Ist das korrekt, daß RS während der ganzen Initialisierung high ist? Welcher SPI-Mode ist der beste 0,1,2 oder 3? Verändert sich das Display während/nach der Initialisierung wie auch das Nokia Display, so daß man sieht, ob man erfolgreich war? Liefert das Display auch igendwelche Daten zurück?
irgendwie fehlt was. wollt schreiben auf dem Oszi siehts schonmal ganz gut aus aber Display tut nichts
Nach der Initialisierung zeigt es beim ersten mal normalerweise bunte Zufallsmuster. Am besten du machst noch einen clear-screen mit einer nicht weissen Farbe, dann siehst sicher du ob es geht.
Hallo Smartie, hatte zunächst auch Probleme, da ich den Code auf den PIC portiert habe (Code siehe weiter oben im Thread). Schau am besten in Martin's BASCOM-Basic Source. Der ist weitgehendst selbsterklärend. Aber Achtung beim Nachbau. Das CS-Signal ist entscheidendend, also vorerst nicht "optimieren" !! Das hat mich einiges an Zeit gekostet :( Gruß Mario
das CS macht der ARM ja alleine. Das Nokia Display ändert die Farbe nach der Initialisierung da kann man gleich sehen daß man erfolgreich war, deswegen meine Frage, ob das Siemens das auch macht. Wann genau zeigt das Display die Zufallsmuster, erst nach allen drei Init-Sequenzen oder schon vorher?
Für die controller gibt es doch datasheets zum runter laden, oder? Kann man die restlichen Funktionen nicht aus den datasheets entnehmen? (z.B. power down)
Von Sharp hab ich was gefunden steht aber nicht viel drin: http://sharp-world.com/products/device/ic/pdf/lr38826_e.pdf Epson hab ich nur einen TFT Controller gefunden das ist der S1D19105 http://www.epson-electronics.de/upload/PresidioIndustries/product/Semiconductors/LCDController-Driver/SingleChipTFTLCDDriver/S1D19105_TM_rev1_1.pdf der S1D15G10 hat nur 132x132 und ist kein TFT http://www.epson-electronics.de/upload/PresidioIndustries/product/Semiconductors/LCDController-Driver/SingleChipPassiveLCDDriver/S1D15G10D08BE_TM_MF1493_03.pdf aber komplettes Service Manual vom S6 hab ich gefunden: http://www.siediyer.com/Doc/x65SRD.pdf Da steht drin daß die verschiedenen Displays Hardwarecodiert sind also irgendwo wohl Brücken gesetzt und die Software demensprechend das Display nimmt. Dann dürften die aber auch im Handy nicht untereinander tauschbar sein.
Natürlich kann man nicht mehr verlangen, dass man sich den ganzen Thread hier durchliest... Aber neues habt ihr bis jetzt leider noch nicht ausgegraben :-( Die verschiedenen Display's werden an Pull's in den Display's unterschieden. Die SW findet so heraus welches Display angeschlossen ist und benutzt dann den entsprechenden Treiber. D.h. ein Phone unterstützt jedes der Displays.
Naja wird halt auch schnell unübersichtlichg so ein Thread. Hab mal in das Datenblatt von dem Hitachi-Chip reingeschaut, das scheint eine komplett andere Kommunikation zu sein. Kommt immer erst ein Startbyte, wo auch das RS mit drinsteckt und dann Daten und alles 8-Bit-Weise.
Den Treiber Code kannst du ja runterladen und dir anschauen. In diesem Fall reiner C-Code
Nochmal eine frage, Kay Pohl hat geschrieben das der Bildaufbau 2-3 sekunden dauert bei 16 mhz - ist das normal oder ist das nur bei basic so? :P Das ist ja für eine echte Anwendung unzumutbar, was für "framerates" haben die anderen denn so hin bekommen? Ich hab mir überlegt das Display in verbindung mit einem ARM für flüssige Animationen zu verwenden, der ARM wäre ja schnell genug - könnte das gehen oder soll ich das lieber sein lassen? Ansonten ist mir noch das display von http://www.shop.display3000.com/ aufgefallen, ich hab zwar erst gedacht das wäre ein nokia 6100 display aber das scheint ja 16 bit anstatt 12 bit farbe zu haben... hmm
@Lupin: bei display3000 sind doch Nokia 6100 Displays - Mit Epson Chipset.
Hi, ich will ein scrollbares menü machen deshalb interessiert mich die benötigten Bit/s vom µC auch. 16 bit 132 rows 176 cols = 371712 bit pro frame. Wenn der maximale SPI Takt des Displays 13 MHz ist ist die max. Bildfrequenz 13e6/371712= 34,97 Frames/s Mit nem schnellen Controller kein Problem mit nem ATMEGA wirds schwierig da SPI max 10 MHz
"mit einem 16MHz AVR (8 MHz SPI) kann man den kompletten Bildschirm in ca. 50ms schreiben" schon aber du hast ja auch noch andere Aktivitäten des µC. Ausser du hast schon die ganzen Bildinhalte in einem externen Speicher und schaufelst sie nur noch ins Display.
Controller mit mindestens 371712/8=46464 Byte RAM gibts von Atmel nur als ARM. Ob das Sinn macht, den spärlichen RAM-Speicher so zu mißbrauchen, da kann man sich drüber streiten. Scroll-Menüs kann man auch textbasiert realisieren, hab ich bei dem Nokia-Display auch gemacht mit nem 16-MHz-AVR. Oder alles aus einzelnen Bitmaps zusammenbauen, die man im Flash ablegen kann. Außerdem kann man sich bei der Grafikausgabe auf einen Frame beschränken, der kleiner ist als das eigentliche Display.
Am besten ist es wenn man sich auf klassische Konsolen-methoden wie Hintergründe, die aus einzelnen Blöcken zusammen gesetzt sind, beschränkt und nur in Ausnahmefällen sprites zeichnet, das könnte man dann doch alles direkt ins display zeichnen und die grafiken vom flash laden, oder? Wenn man es dann dynamischer braucht muss man sich halt Speicher reservieren. Nun frag ich mich aber wie die 2-3 sekunden für den Bildaufbau zustande gekommen sind.
So, habe mein Display bekommen und es hat sofort funktioniert. Also vielen Dank an Christian für die tolle Arbeit die du geleistet hast!!!
Hat jemand funktionierenden Quelltext für Hardware-SPI, MSP430 und LS020? Bis jetzt klappt es bei mir immer noch nur per Software-SPI, habe alles ausprobiert und stehe auf dem Schlauch...
Salve, zuerst mal herzlichen Dank an Christian. Wirklich tolle Arbeit! Hab gestern von Cellow mein Display bekommen (LPH88, steht direkt drauf). Ich glaube aber, es hat durch den Versand was wegbekommen. Eine Ecke ist angeknickt (war auch nur in Luftpolsterfolie verpackt, ohne Knickschutz). Dummerweise hab ich das erst gemerkt, nachdem ich es angelötet und getestet hatte. Folgender Defekt tritt auf: In der unteren Displayhälfte ist jede Zweite Zeile weiß, egal welche Daten ich dort in den GRAM schreibe. Mir fiel auch auf, daß die erst noch etwas bunt sind, und erst dann richtig weiß werden (nach 1-2 Sekunden Betrieb). Ich vermute ganz stark, daß durch den Knick die Treiberleitungen beschädigt wurden. Die init-Routinen hab ich von Christian übernommen, und auch schon verändert. Die defekten Zeilen sehen so aus wie wenn ein Teil des Displays nicht gescannt wird (kann man in der Init ja festlegen). Falls jemand schonmal etwas ähnliches erlebt hat, wäre eine kurze Nachricht sehr nett. Ansonsten muß ich sehen, ob Cellow das Display mit Lötzinn dran zurücknimmt. ;( Danke schonmal für Tips, Mark
Hi, im Anhang ein kleines Tool zum erstellen von 16 bit Farb defines aus der Windows Farbpalette. Man kann nur die Grundfarben oder die erste custom color zur Liste hinzufügen.
Zum Thema Hardware-SPI hatte ich auch mein Problem. Die Lösung: ich hatte nur gesendet und nicht gewartet bzw. abgefragt ob fertig. Hab dann nach jedem Word 15µs gewartet und dann hats auf Anhieb funktioniert.
Hab eine Platine gemacht, auf die genau das Sharp-Display passt, zwei Spannungsregler für 2,9V und LED-Spannung damit das Display mit 12-15V betrieben werden kann und Spannungsteiler für 5V Ansteuerung und Schalttransistor zum Ein- und Ausschalten der LEDs. Die Bauteile sitzen alle direkt in den Aussparungen des Displays, so daß die Rückseite plan ist. Anbei die Eagle-Dateien, Fotos (leider nur mit Webcam) und meine Demo auf dem Arm7 von Atmel AT91SAM7S256
Ich steuere das Display mit dem R8C an. Ich habe folgendes festgestellt: Wenn ich einen Bereich mit 0xef90 0x0504 auswähle, dann muss ich nun y1,y2,x1,x2 angeben und nicht x1,x2,y1,y2 wie im PDF steht. Ich gebe auch die Pixeldaten von links oben an zeilenweise nach unten an, im PDF ist es von links unten zeilenweise nach oben angegeben. Hat das auch schon jemand bemerkt ?
hab jetzt noch ein bischen das Timing optimiert und festgestellt, daß man bei der Initialisierung nach bestimmten Sequenzen dem Display ein paar µs Zeit geben muß sonst klappts nicht. Die Wartezeit nach SPI send hab ich jetzt bis auf 2 µs runtergeschraubt. Bin jetzt noch am überlegen, wie man die SPI noch optimieren könnte, weil ja immer 2µs gewartet werden muß. Ginge eigentlich nur über einen Software FIFO und ein Interrupt, der die SPI bedient, der müßte dann aber auch mit 1-2µs laufen. Hab noch schnell zwei kleine Routinen fillrect und rect geschrieben, kann ich mal posten falls es jemanden interessiert, ist aber nichts dolles. Verwende die embedded Workbench von IAR, war bei dem Bundle von MSC mit dabei für 149 Euro, ist aber auf 32KB Code beschränkt. Finde die zwar lange nicht so gut wie Codevision für den AVR aber man kann mit arbeiten.
@Smartie: schau mal im Datenblatt unter 29.6.3.4, Figure 29.7: die SPI_Schnittstelle des SAM kann selbstständig Delays erzeugen. Viele Grüße, Stefan
ich will ja grad keine delays. Ein Fillscreen hat fast 45 KBytes. Bei 2µs sind das bei 16 Bit SPI fast 100ms, die die CPU nur wartet.
ahhh ... ich hatte verstanden, dass das Display die 2us braucht, um korrekt die Daten annehmen zu können. Warum schreibst Du die Daten nicht in einen Out-Puffer und startest dann den DMA des SPI? Die Daten werden dann völlig selbstständig ausgegeben. Währenddessen kannst Du die nächsten Daten vorbereiten, in einem anderen Datenblock. Viele Grüße, Stefan
werd mir das mit dem DMA mal anschauen, bin halt noch ganz am Anfang mit dem Arm. Die 2µs braucht es nur bei der Initialisierung, beim Daten schreiben nicht. Hab auch grad nochwas rausgefunden: nach lcd_wrcmd(0xEF90); lcd_wrcmd(0x0504); lcd_wrcmd(0x0800+y1); lcd_wrcmd(0x0A00+x1); lcd_wrcmd(0x0900+y2); lcd_wrcmd(0x0B00+x2); funktioniert lcd_wrcmd(0x0504); lcd_wrcmd(0x0600+y1); lcd_wrcmd(0x0700+x1); nicht mehr richtig, es wird durch den Frame von vorher begrenzt, läuft also über. d.h mit der ersten Befehlsfolge wird definitif ein Clipping-Fenster gesetzt, was für alle weiteren Schreibbefehle gilt.
Hallo Freunde des LS020 Displays... Nachdem ich nun mehrere Display's in Betrieb genommen habe, musste ich noch einmal die INIT-Sequence ändern. Sonst scheinen einige Displays nicht stabil zu starten. Ich hatte erst Wackelkontakt vermutet bzw. Display beim Löten beschädigt. Allerdings hat sich mal wieder die Software als nicht perfekt erwiesen. Ich habe die Web-Page und die glcd upgedated. For den letzten Command (bedeutet vmtl. Display On) muss noch eine Wartezeit eingehalten werden. Tschüss und guten Rutsch Christian
Hallo täusch ich mich oder muss in LCD.asm in der send window write start sequence: nicht r24 stehen? Im orginal ist dort r30 angegeben.
da hast du wohl recht... Fällt hier aber nicht auf, da die Funktion nur einmal benutzt wird und beim init das window schon richtig gesetzt wird.
das LS020 ist wirklich ganz schön zickig... Im Prinzip läuft jetzt zwar alles bei mir, auch Hardware-SPI am MSP430, aber wenn ich was ändere dann klappt meistens nichts mehr. Software-SPI geht, Hardware-SPI mit 4Mhz geht auch, Hardware mit 2Mhz aber NICHT. Kann ja auch sein das ich irgendwo einen blöden Bug in meiner Software habe, aber so komisch hat sich bis jetzt noch kein Display angestellt. Trotzdem, wenn es klappt, dann ist es klasse. Nur eine Anwendung habe ich immer noch nicht gefunden :)
Angehängte Dateien:
-
board_V1.0.jpg
91 KB
Hallo Rainer, als Anregung (und 300'te Post in diesem Thread) hier mal ein Beispiel was ich gerade mit dem Display mache. Im grunde handelt es sich um eine mobiles universelles Gerät, z.B. zur Datenerfassung. Es unterstützt verschiedene Möglichkeiten zum Datenaustausch. Als User-Interface gibt es einen Drehgeber mit push-Taste, sowie zwei Tasten und/oder einem Ziffernblock (z.B. als Folientastatur) Visuell hat es das S65-Display sowie zwei LED's und einen kleinen Lautsprecher oder pieco. Das Gerät wird mit Akkus (LiIon/NiMh) betrieben, mit kompletter Ladeelektronik (für software gesteuertes Laden). Das Gerät lässt sich über eine Taste ein- und ausschalten. Im ausgeschalteten Zustand hat es einen sehr geringen Stromverbrauch, über eine externe RTC (mit Batteriespannung) läuft Zeit&Datum weiter. Das aufwändigste ist (wie immer) die Software Entwicklung. Insbesondere das User-Interface verschlingt sehr viel Zeit (und ich habe noch fast alles vor mir....) Daher ein Vorschlag: Ein grafisch-gesteuertes User-Interface wird wohl jeder brauchen, der mit höher auflösenden grafischen Displays arbeitet. Könnte man das nicht gemeinsam entwickelnt? Grüße und frohes neues Jahr 2006 Christian
Hallo Christian, Güte Idee, bin dafür ein standart library zu machen. Ich schreibe gerade mein grafik libraries, für alle displays. alles in standard C, also portierbar. nur die low-level routinen sind naturlich abhängig von der hardware. Meine HW targets sind: -Keil C167 -Keil C51 -Keil ARM -IAR MSP430 Hast Du einen vorschlag für ein algmeines interface? Grüße Mark de Jong,
Vielleicht etwas in der Art:
Steuerung über Drehgeber (drehen hoch/runter bzw. links/rechts
Auswahl push-Taste)
- Eine Display-Text Zeile als Menu (obere oder untere)
-> 1-4 Auswahlmöglichkeiten (li/re) (aktuelles invers dargestellt)
-> push-Taste wählt das Menu
- Ein Frame des Displays wird als Menue-Fläche definiert
-> Die Applikation muss diesen Frame immer neuzeichnen können, da
Display Inhalt ja mangels Speicher nicht gesichert werden kann
- In diesem Frame kann man ein Menu-Window (single select) öffnen
-> Anfangs rein textbasiertes Menu (hoch/runter)
-> natürlich sind sub-menues möglich
- oder in diesem Frame kann man ein Eingabe-Window öffnen
-> Zahleneingabe (mit Drehgeber support) Texteingabe?
.....
Moin Christian, eigentlich arbeite ich an etwas ähnlichem. Zur Zeit befasse ich mich hauptsächlich mit Grafik-Dateiformaten um Icons usw darstellen zu können. Habe mir ein Tool geschrieben das aus einer BMP-Datei ein Headerfile mit Farbtabelle für das LS020 und Bilddaten macht. Dadurch habe ich zwar nur 256 Farben pro Icon, brauche aber auch nur 1 Byte pro Pixel. Je nach Grafik bringt RLE-Codierung auch noch Platz. Dieses kann man dann leicht in seinen Quelltext einbinden. Für Zeichensätze benutze ich das XBM-Format da dieses eh C-Quelltext ist und sich leicht mit Gimp oder Editor bearbeiten lässt. Würde mich interessieren welche Wege ihr da geht.
Christian, habe mit gerade nochmal dein Board angesehen. Ist eigentlich genau das was ich auch brauche, nur mit einem MSP430 drauf :) Als nächstes wollte ich mich mit der SD-Karte usw beschäftigen. Eine Anwendung hätte ich auch dafür, nennt sich "Tagesgradzähler" und muß über mehrere Monate eine Wassertemperatur aufzeichnen und einen Tagesdurchschnittswert addieren. Ist eigentlich kein Problem, aber irgendwie bisher immer am Gehäuse und der Stromversorgung gescheitert. Mit einem AVR hatte ich es mal so gut wie fertig, aber dann wollte ich doch lieber ein Grafikdisplay anstelle von Text, bin auf MSP430 umgestiegen usw. Jetzt will ich Farbe und wahrscheinlich kommt dann doch noch etwas anderes...
Ich hab mir auch ein S65 display bestellt, ich habe vorgehabt JPEGs zu laden... das soll später mal teil eines kleinen Projektes werden. Die JPEGs liegen dann auf einer MMC karte. Den code zur Dekomprimierung hab ich schonmal auf einem GBA laufen gesehen, sollte also mit einen ARM mikrocontroller nicht so schwer sein.
Angehängte Dateien:
-
Display_S65.jpg
940 KB
Ich Experimentiere gerade am Ls020... mit dem TEST.C rum:
#include <inttypes.h>
#include "../glcd/glcd.h"
#include "../glcd/lfsr.h"
#include "../font/nums.h"
#include "../font/f9x14.h"
#include "../font/f15x22.h"
#include "../font/f8x11.h"
#include "../font/f8x8.h"
void demoScreen(void){
glcdSetOrientation(0);
glcdSetColor(0, SCREEN_COLOR);
glcdSetColor(1, BLACK);
glcdSetColor(2, GOLD);
glcdSetColor(3, RED);
glcdClearScreen(BLACK);
glcdSetFgColor(BLACK);
glcdSetBkColor(WHITE);
glcdFrame(0,0,130,175);
glcdFillRect(110,110,130,130,SCREEN_COLOR);
glcdMoveTo(10,10);
glcdSelectFont(f9x14, 0); // font is stored in FLASH,
demontrate read callback
glcdPrint("Siemens S65 LS020... \n geb 13.04.1966\n", 0);
glcdSelectFont(f9x14, 0);
glcdSetFgColor(BLUE);
glcdMoveTo(11,100);
glcdPrint("12345678901234567890",0);
glcdSetBkColor(RED);
glcdCircle( 80,80,10);
glcdLine(90,80,100,100);
}
int main(void) {
#define cnt 1
#ifndef USE_AUTOINIT
glcdDisplayInit();
#endif
glcdClearScreen(1);
// glcdDisplayOn();
uint8_t o = 0;
demoScreen();
while (1) {
}
}
Jetzt habe ich in der GLCD.inc
define ORIENTATION_DEFAULT ORIENTATION_270 or _90
#ifndef SCREEN_WIDTH
#define SCREEN_WIDTH 175 // Siemens S65
#endif
#ifndef SCREEN_HEIGHT
#define SCREEN_HEIGHT 131 // to (0,0,131,175) to
support hardware scrolling and splitting of display
#endif
#ifndef SCREEN_LEFT
#define SCREEN_LEFT 0
#endif
#ifndef SCREEN_TOP
#define SCREEN_TOP 0
#endif
#ifndef SCREEN_RIGHT
#define SCREEN_RIGHT (SCREEN_WIDTH -1)
#endif
#ifndef SCREEN_BOTTOM
#define SCREEN_BOTTOM (SCREEN_HEIGHT -1)
#endif
eingestellt und bekomme siehe Anhang , alles Spiegelverkehrt angezeigt.
Habe ich was vergessen ?
Und bei glcdSetOrientation(0); kann ich 1, 2,3 etc einstellen und
passiert. Ich wollte die Anzeige Quer verwenden.
Und was ich nicht verstehe -> glcdPrint("12345678901234567890",0);
wenn anstatt eine 0 -> eine 1 reimache wird das Bild immer wieder
aufgebaut. Warum?
Da ich nur wenig mit C - Gemacht habe, habe mit Bascom gearbeitet.
Sind Tips immer gut. Ein gutes Projekt!!
Hallo Rainer, dann könnte dieser Link für dich interessant sein... http://focus.ti.com/lit/an/slaa281/slaa281.pdf Heute würde ich den Atmega 128 auch nicht mehr nehmen, sondern einen ARM7. Mittlerweile ist aber zuviel Zeit in das Projekt geflossen um noch den µC zu wechseln. Ausserdem reicht er. Vorteile vom ARM sind: - mehr Performance - mehr Speicher - weniger Stromverbrauch - niedrigere Versorgungsspannung - nahezu gleicher Preis Den AVR habe ich genommen, weil es dafür soviel Software im Netz gibt. Und das ist immer noch ein gutes Argument für den AVR. Hallo Dirk, die glcd unterstützt derzeit nur eine Orientierung. Das liegt daran, dass der Display Controller lange nicht so flexible Addressierungs modi des Display-RAM's unterstützt wie der Philips Controller für die die GLCD ursprünglich geschrieben wurde. Zumindest sind mir bis heute nur die dokumentierten Modi bekannt. Also wenn du Lust hast, kannst du ja mal versuchen eine andere Orientierung einzubauen. Wenn ich mich richtig erinnere, gibt der letzte Parameter von glcdPrint an, ob die Daten aus dem Program-Flash oder dem RAM gelesen werden. Wenn du aus dem Flash lesen möchtest, musst du die Daten auch dort speichern, sonst ist nicht definiert was passiert...
ich finde das Board auch interessant,hab auch schon was ähnliches im Eagle angefangen. Würde es aber auch mit einem Arm7 machen, das Ding hat massig Speicher, RAM, USB und gibts auch mit Ethernet. Die Programmierung ist auch nicht so kompliziert. Da aber irgendwie jeder seinen Lieblingsprozessor hat, ist es vielleicht besser, entweder verschiedene Boards entwickeln oder ein Universal-Board mit aufsteckbaren Prozessoren machen, dann wäre jedem geholfen. Bei der Softwareentwicklung sollte alles modular sein, und möglichst universell für alle CPUs verwendbar. Mit nem ATMEGA und dem Nokia-Display hab ich mal nen Tempomat/Bordcomputer gebaut, der nur über einen Drehencoder mit Button programmiert und eingestellt wird. Da hatte ich zum Beispiel kurz Drücken für on/off, länger Drücken Geschwindigkeit übernehmen, ganz lang Drücken Menü.
Hello! Ich suche seit Lange ein gutes LCD-Display für mein GPS-Project, aber die S65-LCD wäre für mich die beste Lösung. In Ungarn kostet es etwa 30 EUR, aber es ist noch immer billig und leicht einholbar. Ich habe die Archive dieses Forums durchgelesen, aber ich hätte noch ein paar Frage, und ich bitte euere Hilfe bei diesen. 1. Wenn ich es gut verstanden hatte, Siemens herstellt S65 handys mit drei verschiedene LCD-Kontroller: das LS020xxx hat einen nicht gut bekannten Sharp-Kontroller, das LPH88xxxx hat den gut dokumentiert Hitachi HD66773 Kontroller, und L2F50xxx enthaltet einen Epson Kontroller, dieser letzter hat kein Datenblatt publiziert im Internet, aber Christian hat diesen an besten analysiert und dokumentiert. Wenn ich alle diese Type einholen könnte, sollte ich den Hitachi oder den Epson kaufen? Und wenn ich durch z.B. eBay kaufen möchte, und ich weiss nicht, welche ankriege, ist es 100%, dass ich es unabhängig von Kontroller benutzen kann? (Anders gefragt: Werden die Dokumentationen im Internet (forum, Christian's doc) genug z.B den Sharp-Kontroller zu Arbeit zu vermögen?) 2. Ich habe in Christian's doc gesehen, dass er 2,9V zum 1,8 und 2,9V pins bindet. Ist es gesund die 1,8V pin mit 2,9V zuliefern? In meinem Project gibt es ein 1,8V und ein 3,3V Spannungsquelle (TI TMS470R1B1M ARM7TDMI core prozessor). Wäre es tödlich, das Display mit 1,8V und 3,3V zu quellen? 3. Wenn ich gut denke, ich soll 15V zum Pin LED+ nur dann binden, wenn ich Background-Light möchte. Ist es so richtig? Wenn ja, hat schon jemand die Spannung-Storm Charakteristik dieser LED ausgemessen? Es wäre wichtig, wenn man einen Helligkeitregler aufbauen will. Danke für eure Hilfe vornüber und ich möchte vorwigend Christian und natürlich allen Lesern dieses Forums für die Forschung gratulieren die er und euch für die Erkenntnis der Functionalitäten dieses Displays gemacht haben. Grüsse Tamas aus Ungarn
Hallo Es wurde öfter in diesem Thread darüber gesprochen eine Platine für das Display zu entwerfen. Wollte mich erkundigen, ob daraus was geworden ist. LG Michael
Hallo Michael, Ich erwarte die Platinen Morgen. Sobald ich Sie getestet haben werde ich mich melden. Grüße Mark,
ich hab mir jetzt auch mal das display besorgt, ist ein LPH. die 2.9v sind bei mir 2.94 und die 1.8v sind 1.86 - also noch im grünen bereich oder? Beide spannungen werden aus 3.3v geteilt (einmal mit R1=10k und R2=7.5k und einmal mit R1=10k und R2=1k) Das ganze funktioniert natürlich nicht... ich benutze einen LPC2106 und bin mit dem SPI takt schon auf einen halben mhz runter gegangen aber das display zeigt rein gar nix an. In den Kommentaren bei der init sequenz steht zb sowas wie // start at 240ms Aber ich kann da nirgends einen delay aufruf über 240 ms finden - woher kommt diese zeit? Hab nochmal meine abgeänderte disp.c angehangen, ist fast genau so wie im Beispiel. Mein SPI ist übrigens als Master eingestellt, kein CPOL oder sonstige Einstellungen.
Im Beispiel sind der 2,9V und der 1,8V Anschluss beide an 2,9V gehaengt worden.
ja das ist aber bestimmt nicht so gut... werds trotzdem mal probieren
Hat nicht funktioniert, ich hab mal mein messgerät dazwischen gehangen (zwischen 2.9v und den versorgungs-anschluss am display) und der zeigt 0mA an - ist das teil kaputt? Ich war auch so schlau und hab mit meinem (billig)-multimeter gemessen ob es zwischen den pads am display einen Kontakt gibt... war vielleicht keine gute Idee :(
Noe, das ist kein Problem. Aber 0mA ist nicht gut. Ich finde deinen Spannungsteiler im kOhm Bereich aber ziemlich verdaechtig. Versuch doch mal das gleiche mit einem Teiler im wenigen 100 Ohm Bereich.
Mit welcher Spannung laeuft der uC ? Die Signale von dort sollten den 2,9V Level auch nicht uebersteigen. Hatte das zuerst bei meine LS Display vergessen, hat aber keine Schaeden hinterlassen.