Also nachdem das mit dem LCD jetzt überhand nimmt und die Lösungen überall Artefakmäßig Verteilt sind hier mein Lösungsvorschlag: Eine Wikipage mit allen Funktionierenden Ansteuerungsroutinen aller µC und Sprachen. Eine Codesammlung also. Über den Titel bin ich mir noch nicht im klaren, aber vieleicht gibts ja schon Vorschläge( z.B. LCD Codesammlung o.Ä. ). Die Wiki soll eine Tabelle werden wo die Distri-Bezeichnungen drinstehten, der LCD-Controller und eine Spalte mit dem Quellcode. Im Quellcode ( Zip-File ) sollten enthalten sein: * Der Code, Header und Inc-Files sein ( sobalt vom Standart abweichend oder selbstgeschrieben ) * Beschreibung mit: Anschlußplan, Fuses ( Takt etc. ), kurze Erklärung der Routinen * Das LCD-Controllerdatenblatt ( wenn möglich vom Hersteller, nicht vom Distri ) Was könnte man den noch beifügen? Nehn HexFile das Funktioniert zum Testen, wird aber schwer da es ja ne große menge möglicher Zielcontroller gibt. Ne Checkliste wäre nicht schlecht oder was meint ihr? Freue mich auf das Gemeinschaftsprojekt mal schauen was draus wird, hoffe das es klappt. Grüßle
Ein guter Ansatz war schon mal die Codesammlung. Problematisch ist allerdings die Tatsache das man sich durch die Threads hangeln muss, und irgendwann zwischen Mitte und Ende der ausgebesserte Code steht. Mag sein das ich zu faul bin, aber es währe mir lieber wenn es nach Prozessorfamilie aufgeteilt wird.PIC-LCD-WIKI , AVR-LCD-WIKI. Auch sollte trotz allem am Anfang das Display an sich besprochen werden. Flussdiagramme für Initialisierung, senden eines Datenbytes, usw. Um schon im vornherein zu verhindern das die Leute auf die Idee kommen den Code ala cut&paste zu nutzen. Und ein fett gedruckter Satz am Anfang. Wer will das es funktioniert der muss den Code selber schreiben!!!
Ich vergaß noch etwas wichtiges. Strukturierung nach Controller. Das eine 16x2 hat mit einem anderen 16x2 schlimmstenfalls überhaubt nichts gemeinsam. ICh hatte mich im Anfang mit dem "AVR-Tutorial:_LCD" auseinander gesetzt. Bis ich nach zahlreichen Misserfolgen das Datenblatt des Controllers suchen wollte um zu merken das mein LCD-Display kein HD44780 sondern einen S6A0069 zur Ansteuerung besitzt. Deswegen mein Verständnis für Leute die irgendwann dann doch mal im Forum nachfragen :) Trotz allem ein großes Dankeschön an die Leute die das "AVR-Tutorial:_LCD" geschrieben haben. Sonst hätte ich das Rad neu erfinden müssen. Und als Start ist es super
So also ich hab mal mit der Wiki angefangen: LCD Codsammlung Die Codes werden noch geupploaded ( werde erst mal die ASM hochladen, die in C muss ich noch schreiben ), werde noch für das EADIP128 einen Code schreiben, das hbe ich auch noch. Wenn ihr für Displaycontroller funktionierende Codes habt bitte ich euch diese mit reinzustellen oder mir zu schicken, ich stell sie dann rein und schaue auch nach dem DB ( falls nich Vorhanden ) EDIT: Mist ich hab bei dem Artikelnamen nene fehler, wie kann ich den ändern? Danke
Lord of Lightning wrote: > So also ich hab mal mit der Wiki angefangen: > > LCD Codsammlung und direkt verschrieben? Codesammlung wohl eher. Und hosten auf fremde Mirrors ist nicht immer das Beste, wegen der Verfügbarkeit.
Die Wiki Idee ist klasse, man sollte die Anschlussart noch Unterteilen, also 8 Bit 4 Bit-Bus oder Seriel. Gruß hans
Wenn man mir verrät wie ich auf µC.net hosten kann werde ich das gerne tun
Lord of Lightning wrote: > Wenn man mir verrät wie ich auf µC.net hosten kann werde ich das gerne > tun Eine Alternative, die ich wüsste, wäre im Forum hochladen.
So die Seite hab ich jetzt mal richtig benannt LCD Codesammlung für AVR Ein fleißiger Admin hat die andere ja schon gelöscht, das ging ja fix danke.
Mal eine dumme Frage: Bevor zu jedem LCD Controller eine eigene Software entsteht, wäre es nicht erstmal sinnvoller eine Liste mit HD44780 kompatiblen LCDs zu machen, und zu allen nur teilweise kompatiblen einen extra Code, bzw. dazu schreiben was man beachten muss ? Was ist z.B. beim S6A0069 anders als beim 44780? Beim Überfliegen des Datenblatts sehe ich zumindest auf die Schnelle keinen Unterschied.
Genau das ist das Problem, bei den wenigsten siehste beim überfliegen die kleinen Unterschiede beim KS0070B ist das Timing und die Init leicht anders, aber das macht sich deutlichst bemerkbar. Eine Liste brauchst ja nicht machen, trägste einfach den LCD in die entsprechende spalte ein, ne Fußnote dabei das der 100% kompaktibel ist, und fertig. Neue Software hab ich noch nicht geschrieben, das waren alles alte Codes, nur die C-Codes schreibe ich neu, sowieso auch aus persönlichem Interesse, von daher
Lord of Lightning wrote: > Genau das ist das Problem, bei den wenigsten siehste beim überfliegen > die kleinen Unterschiede beim KS0070B ist das Timing und die Init leicht > anders, aber das macht sich deutlichst bemerkbar. Also ich sehe beim Timing keinen Unterschied (ob da jetzt 37 oder 39µs steht ist doch egal, wer das Timing so knapp einstellt, der ist selber schuld.) Und auch die Init ist in meinen Datenblättern identisch. Ebenso beim S6A0069. Falls ich doch was übersehen habe, klärt mich bitte auf. Ich habe eine Software, die lief bisher an jedem LCD und jedem µC (und ich habe schon viele LCDs angesteuert!). Ich werte allerdings auch das Busy aus. Und die Software hält sich exakt an die Init aus dem 44780 Datenblatt mit etwas großzügigeren Timingwerten. Klar, es gibt einige LCD Controller die haben zusätzliche Einstellungen, die es beim orginalen 44780 nicht gibt, aber die sind dann auch nicht 44780 kompatibel.
Das erinnert mich irgendwie an die Anfangszeit mit PC. Da wollte mir ein Gymnasiast einige Disketten mit gesammelten config.sys und autoexec.bat andrehen, die man bei DOS-Problemen einfach alle durchprobieren kann. Ich zog es vor, mir meine Konfigurationsdateien selbst zu schreiben... Eine Sammlung mit LCD-Routinen macht m.E. keinen Sinn. Eine Auflistung aller "Kompatibler" mit Angabe der Unterschiede zum Original halte ich für eine sehr gute Idee. Leider verfüge ich über zu wenig Typen, um an dieser Liste mitzuarbeiten. Vielleicht sollte aber auch etwas auf unterschiedliche Konzepte eingegangen werden. So kann man das LCD direkt ansprechen, was recht viel Rechenzeit durch Busywait oder Warteschleifen vertrödelt, bei einfachen Sachen aber oft anzutreffen ist. Man kann aber auch einen Bildschirmspeicher im AVR-SRAM einrichten und diesen im Hintergrund (Task) an das LCD senden, wobei der AVR in den Wartepausen andere Jobs (Tasks) der Mainloop erledigt. Hier können auch gleich die verschachtelten Zeilenadressen entwirrt werden, wodurch der Bildschirmspeicher mit Fließtext beschrieben werden kann, der auch einige Steuerzeichen (CRLF, Home, Clear, Blink-aus, Blink-Start, Blink-End, Locate) enthalten kann. Letztens reichte dazu der RAM nicht (UART-Terminal mit Tiny2313. LCD 4x40, 4 Tasten, Anzeige von Menü und Parameterliste mit 20 dreistelligen Parametern, dient zum Parametrieren anderer Geräte mit Tiny2313), da wurde die LCD-Ausgabe in die Mainloop gelegt, per Merker vom Timer synchronisiert, und die Mainloop-Jobs (Tastenentprellung, Menüführung, Blinkposition, UART-Handling) während der Wartepause auf den nächsten Synchron-Merker aufgerufen. Geht auch gut und spart Ressourcen. Welche Methode die richtige ist, ist vom Einzelfall abhängig, erfordert also schon vom Programmierer, dass er weiß was er tut, und nicht nur (unverstandene) Codestücke aus dem Wiki zusammenkopieren kann. KH
Gut das blinde rein kopieren bringt nichts, das gebe ich zu. Uach habe ich nicht das deshalb angefangen, damit alles durchprobiert werden soll, aber man kann doch seine LCD-Codes gesammelt veröffentlichen, dann können andere diesen Code kopieren und müssen ihn nicht gleich neu schreiben. Das mit den Unterschiedlichen Konzepten ist auch klar, aber vielleicht finden sich Leute die jetzt z.B. die von dir genanten Routinen schon geschrieben haben, also in die Sammlung gepackt und jeder kanns ändern, verbessern etc. Anmerkung zur Kompatibilität: Es ist definitiv so das sich der HD44780 und der KS00700 in der selben Schaltung mit dem selben Programm anders verhalten, der HD44780 funktioniert ohne Problem, während der KS gar nicht geht, erst wenn die Init verändert wird, das ist nicht nur bei mir so ( gucken machen in Forum )
lightninglord wrote: > Anmerkung zur Kompatibilität: Es ist definitiv so das sich der HD44780 > und der KS00700 in der selben Schaltung mit dem selben Programm anders > verhalten, der HD44780 funktioniert ohne Problem, während der KS gar > nicht geht, erst wenn die Init verändert wird, das ist nicht nur bei mir > so ( gucken machen in Forum ) OK, den KS0070 habe ich bisher noch nicht probiert. Aber KS0066, S6A0069, SPLC780 und HD44780 laufen definitiv mit der selben, unveränderten Software im 4 und 8bit Modus. Ich muss nochmal suchen ob ich irgendwo auch ein KS0070 LCD rumliegen habe. Ich behaupte immer noch, dass es an einer schlechten Software liegt. Siehe dazu auch das hier: http://www.data-modul.com/de/support/faq/displaytechnik.html#faq_d_09 Ich habe das selbst auch schonmal mitbekommen, wie ein großer, bekannter deutscher Hersteller plötzlich Probleme bekam, als Hitachi den HD44780 einstellte, und danach irgendein Samsung Controller auf dem LCD war. Dies lag ganz einfach daran, dass sich der Hersteller auf die typischen Timingwerte aus dem Datenblatt verlassen hat, die Hitachi erstaunlicherweise auch gut eingehalten hat, während Samsung zum Beispiel den zulässigen Toleranzbereich doch etwas weiter ausnutzt. Und dabei ging es um etliche 1000 LCDs pro Jahr! Ich möchte hier jetzt auch nicht rumnerven, sondern verhindern dass der Artikel ein reines Chaos wird, wenn hier dutzende Verschiedener Versionen in dem Artikel auftauchen, die alle irgendwie so hingepfuscht sind, dass sie gerade so mit dem entsprechenden Controller laufen. Bisher sind da nämlich schon Fehler in dem Artikel: Die 164 und 204 (vielleicht sollte man hier auch noch den Hersteller dazuschreiben, denn viele nennen ihr Displays so), haben nur einen KS0070. Weiterhin sollte man vielleicht die Software auch möglichst einfach halten (also keine extra aufwendigen Tricks einbauen die keiner kapiert und die erstmal aufwendig an den AVR angepasst werden muss), sondern wirklich nur die grundlegenden Routinen (vielleicht inkl einer kleinen Ansteuerung die sowas wie "123 LCD Test" anzeigt) reinstellen.
Nachtrag: Laut diesem Datenblatt habe ich doch LCDs mit KS0070 Controller. Und die laufen auch mit ein und der selben Software wie alle anderen, ohne veränderte Init... http://www.pollin.de/shop/downloads/D120545D.PDF
> aber vielleicht > finden sich Leute die jetzt z.B. die von dir genanten Routinen schon > geschrieben haben, Das ist ja eben der Haken... Wenn diese Routinen in gesammelter Form zum Herunterladen zur Verfügung stehen, dann wird sich kaum ein Anfänger die Mühe machen, selbst über die LCD-Ansteuerung nachzudenken. Er wird die Routinen ausprobieren, sie werden nicht zufriedenstellend laufen, weil er die Konventionen betreffs Hauptprogramm (Aufruf der Routinen) mangels eigenen Denkens nicht einhält und wird frustriert sein, weil der schnelle Erfolg ausbleibt. Ja, ich habe bereits verschiedene Konzepte mit LCDs realisiert, habe sie aber an zuwenig verschiedenen LCDs (unterschiedlicher Herkunft) testen können um sie mit reinem Gewissen im Netz veröffentlichen zu können. Denn Unfug ist schon mehr als genug im Netz veröffentlicht. Ich strebe auch nicht danach, die ultimativen LCD-Routinen zu schreiben, mir reicht es, wenn die LCDs an meinen AVRs einfach nur zuverlässig ihren Dienst tun. Und dies wird je nach Konzept auf unterschiedliche Art und Weise erreicht. KH
Ich habe mal meine Software an verschiedensten LCDs ausprobiert. Dabei waren HD44780 in verschiedensten Varianten (orginal Hitachi, Motorola), KS0066, T7934, LC7985, S6A0069, irgendein Philips Controller und ein KS0070 (wenn man dem Pollin Datenblatt glauben kann) und noch einige weitere von denen ich gar nicht weiß, was für ein Controller da drauf ist. Ansteuerung im 4bit Modus, einmal mit und einmal ohne RW Pin, mega8 auf 18MHz übertaktet und etwa 50cm lange Kabel um ganz sicher zu gehen, dass bei etwas knappen Timing Probleme auftreten. Das Ergebnis war wie erwartet: Alle LCDs laufen ohne Probleme an ein und der selben Software!
Und hier die Software dazu. @ Alle die Probleme mit der normalen HD44780 Software haben: Probiert diese Software mal bitte aus. Ich behaupte diese läuft mit allen LCDs die sich HD44780 kompatibel nennen, egal welcher Controller da letztendlich drauf ist. PS: Wer meint die Wartezeiten wären etwas lang, dem stimme ich zu, allerdings müssen diese so lang sein, damit das ganze zuverlässig funktioniert. Alles andere ist Pfusch! Die üblichen Wartezeiten gelten nämlich für 270kHz Taktfrequenz. Einige Datenblätter geben die Taktfrequenzen an, ich habe da z.B. schon Werte wie 120kHz gefunden. Das ist nicht mal die Hälfte der 270kHz, dementsprechend werden die Zeiten mehr als doppelt so groß! Dazu kommt noch, dass selbst beim originalen HD44780 die Oszillatorfrequenz mit +/-30% spezifiziert ist, und das bei 5V +/-10% ! Bei 3,3V ist das ganze nochmal ein ganzes Stück langsamer... Wenn die Rückmeldungen alle positiv sind, werde ich die Software dann in die oben genannte Codesammlung stellen.
Also ich habe mir nun mal die vom Licht-Lord veröffentlichten Routinen angesehen und fühle mich in meinen Befürchtungen bestätigt. Denn das Nonplusultra ist das nicht gerade. Für den Hausgebrauch ist es ja gut und schön, auch als Antwort auf eine Forumfrage ist es akzeptabel, aber als Vorzeigebeispiel finde ich es nicht so doll. Hier einige Punkte, die mir aufgefallen sind: Du legst die unbenutzten Datenleitungen an GND, teils sogar über Widerstände. Hast Du mal darüber nachgedacht, dass viele LCDs ihre Datenleitungen per PullUp nach Vcc ziehen? Zu erzeugst damit unnötigen Stromverbrauch, mit Widerständen sogar undefinierte Pegel (Spannungsteiler). Und ja, es gibt glaube LCDs, bei denen die unbenutzten Datenleitungen auf L müssen, aber bei den meisten ist das nicht der Fall. Vor der Initialisierung wird gerade mal 50ms (10 * 5ms) gewartet. Das ist für viele LCDs zu kurz. Da die Init nur einmal aufgerufen wird, kommt es auf ein paar hundert Millisekunden nicht an. Nippel findet man an Maschinen (Schmiernippel), vielleicht auch an Mädels, ein halbes Byte ist aber ein Nibble. Klar, nur ein Fehler zum Schmunzeln, aber in einer ernstzunehmenden Cod(e)sammlung schon etwas peinlich. Das Macro LCDPos finde ich nicht gerade anwenderfreundlich. Das kann man auch anders machen. Z.B. so ähnlich wie hier:
1 | .macro locate ;Zeile (0,1), Spalte (0...39) ;Positionierung der Ausgabeposition |
2 | push wl ;Register sichern |
3 | ldi wl,128+((@0 & 1)<<6)+(@1 & 63) ;Zeile in Bit 6, Spalte in den Rest |
4 | rcall lcd_command ;an LCD als Befehl ausgeben |
5 | pop wl ;Register wiederherstellen |
6 | .endmacro |
Es funktioniert bei 16x2, 20x2, 24x2 und 40x2. Auch die Routine(n) zur Ausgabe von Strings aus dem Flash finde ich etwas umständlich. Zumindest, wenn man es schon mal anders gesehen hat:
1 | .macro printf ;Startadresse des Strings im Flash (als Label angegeben) |
2 | ;Gibt einen String aus dem Flash an LCD aus |
3 | ;Der Parameter beschreibt die Startadresse, |
4 | ;das Ende ist $00 |
5 | push zh ;verwendete Register |
6 | push zl ;sichern |
7 | ldi zh,high(2*@0) ;Pointer |
8 | ldi zl,low(2*@0) ;setzen |
9 | rcall lcd_printf ;Aufruf... |
10 | pop zl ;verwendete Register |
11 | pop zh ;wiederherstellen |
12 | .endmacro |
13 | |
14 | lcd_printf: ;Wird vom Makro aufgerufen. Gibt Flash-String an LCD aus. |
15 | push wl ;Variable beschaffen |
16 | lpm wl,z+ ;Zeichen holen |
17 | tst wl ;Ende-Kennung? |
18 | breq pc+3 ;ja... |
19 | rcall lcd_data ;nein, ausgeben |
20 | rjmp pc-4 ;nochmal |
21 | pop wl ;Variable entsorgen |
22 | ret ;fertig, zurück... |
Der Aufruf erfolgt dann einfach durch: locate 0,0 ;Zeile 0, Spalte 0 printf hallo ;String am Label "hallo:" ausgeben und irgendwo im Programm steht dann: hallo: .db "Hallo Welt...",0 Wie soll man das eigentlich deuten?
1 | ;---[ 190�S warten ]---------------------------------------------------------------- |
2 | |
3 | waitus50: ; Genau 100�S warten |
4 | |
5 | ldi r17, $FC |
6 | WGLP3: dec r17 |
7 | brne WGLP3 |
8 | nop |
9 | |
10 | ret |
Beim Aufruf steht allerdings 50 Mikrosekunden. Sind es nun 50, genau 100 oder gar 190 Mikrosekunden? Nunja, für den Hausgebrauch ist das ok, auch einige meiner Programme haben solche Stilblüten. Aber vor einer Veröffentlichung in einer ultimativen LCD-Codesammlung sollte man sowas schon etwas bereinigen. Das waren die Dinge, die mir beim flüchtigen Drüberschaun so ins Auge gesprungen sind. Nach mehr will ich nicht suchen, dazu fehlt mir Zeit und Lust. KH
Nun ja ohne mich rausreden zu wollen: Bei denen war mir die Funktion erstmal wichtig, außerdem hab ich sie zu einer Zeit geschrieben wo ich eher wenig Erfahrung mit ASM hatte, bin aber auf C umgestiegen, weil deutlich freundlicher zum Programmieren. Das mit den Widerständen gegen GND, bei LCD-Modulen mit HDD4780 bzw kompatiblen habe ich aus einem Hobbyelektroniker Magazind desse Elektor äh Namen ich nicht nennen möchte. Danke für die Hinweise werde das verbessern ( heute aber ned mehr ). Grüßle
@lightninglord (Gast) Da C nicht mein Ding ist, kann ich Benedikts Code nicht beurteilen. Ich weiß aber ziemlich sicher, dass Benedikt kein halbseidenes Zeugs veröffentlicht. Ehe Du Deine bereits veröffentlichten Codes überstürzt überarbeitest, solltest Du Benedikts Code mal genauer analysieren. Vielleicht findest Du ja die Stellen, an denen verschiedene LCDs schlapp machen und kannst den ASM-Code so überarbeiten, dass er auch mit (fast) allen LCDs funktioniert. Damit wäre Allen mehr geholfen als mit vielen individuellen Versionen, deren einziger Unterschied in der Dimensionierung der Warteschleife zu sein scheint. Achja, Warteschleifen kann man auch so codieren, dass der Präprozessor die Startwerte der Schleifenzähler anhand der Taktfrequenz berechnet. Das erübrigt Anpassungen bei anderen Taktfrequenzen. Dabei lieber ein Register mehr benutzen, damit auch bei übertaktetem AVR alle Bits in den Zähler passsen. Statt eines NOP kann man auch ein RCALL auf das RET der Routine schreiben, das bringt statt eines Taktes gleich mal 7 Takte (RCALL + RET). Mit ober(st)en Registerpaaren und SBIW gibt es auch einen praktischen (übersichtlichen) 16-Bit-Schleifenzähler. KH
Ich habe gerade mal den Code von lightninglord mit meinem verglichen: Vom Timing her sind beide identisch, nur die Init sieht anderst aus (von den Werten her), aber weder mein noch der Code von lightninglord entspricht der Init des KS0070 aus dem Datenblatt. Welches jetzt von beiden jetzt für den KS0070 richtiger ist, kann man nicht beurteilen, meine ist streng nach HD44780 Datenblatt und müsste somit kompatibel zu allem sein, was sich HD44780 kompatibel nennt. Aber da ich den Pollin Datenblättern nicht vertraue kann ich nicht sicher sein, ob mein Code definitiv mit dem KS0070 läuft. Daher die Frage: Hat jemand mal meinen Code auf einem KS0070 Display ausprobiert?
Tja, Benedikt, da ist (k)ein reger Andrang. :( 43 Downloads der Fotos, aber nur 10 Downloads Deiner Software, wovon einer ich war, obwohl ich von C nix verstehe, aber man schaut ja auch mal über den Tellerrand. Das Problem "LCD geht nicht" scheint also doch nicht sooo groß zu sein wie hier vermutet wird. Ansonsten wäre da mehr Interesse. Übrigens: Danke auch nochmal für Deinen Textgenerator (Mega8, TV, 25 Zeilen a 40 Zeichen), der eine prima Vorlage für mein OSD-Projekt (10 Zeilen je 32 Zeichen) mit Mega8 war. Das hätte ich mir ohne Deine Vorlage nie zugetraut. Bit & Bytebruch, Hannes (oder einfach nur "...")
Hannes Lux wrote:
> 43 Downloads der Fotos, aber nur 10 Downloads Deiner Software, wovon
Die Downloadzahlen bei Anhängen kamen mir immer schon komisch vor.
Bisher habe ich mir das so erklärt, dass wählerische Spider/Bots viele
Downloads machen. Bilder und PDFs schmecken denen anscheinend, Archive
eher weniger.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.