Hallo, hat jemand gute Erfahrung mit einer LCD Library gemacht? Ich suche vor allem eine, bei der man mit einem Befehl ähnlich printf Buchstaben und Variablen mit einem Befehl ausgeben kann, damit ich mir das nicht erst manuell in einen String fummeln muss. mfg.
Herr LCD schrieb: > Hallo, > > hat jemand gute Erfahrung mit einer LCD Library gemacht? Ich suche vor > allem eine, bei der man mit einem Befehl ähnlich printf Buchstaben und > Variablen mit einem Befehl ausgeben kann, damit ich mir das nicht erst > manuell in einen String fummeln muss. Was hat das eine mit dem anderen zu tun? Die paar Hilfsfunktionen, die man dazu in einem Projekt normalerweise benötigt, sind erstens meistens auf das Projekt selber abgestimmt und zweitens schnell geschrieben, wenn man die Basisfunktion "1 Zeichen auf einem Gerät ausgeben" erst einmal hat. Und diese Basisfunktion hat nun wirklich jede LCD-Library. Selbst die aus dem AVR-GCC-Tutorial
Wenn du dich von einem Hauch C++ nicht abschrecken lässt, hätte ich eine m.E. elegante Lösung: http://mfgkw.dyndns.org/AVR/AVR_LCD44780_cpp/Makefile http://mfgkw.dyndns.org/AVR/AVR_LCD44780_cpp/AVR_LCD44780.cpp http://mfgkw.dyndns.org/AVR/AVR_LCD44780_cpp/LCD44780.h Es gibt mehrere überladene printf()-Versionen. Alle sind Methoden einer Klasse, werden also in der Art: meinlcd.printf(...) aufgerufen. Mit den üblichen Parametern wird jeweils ab einer aktuellen Position ausgegeben. Interessanter sind die Versionen, die 3 Parameter vorweg bekommen: - eine Spaltennummer (ab 0 gezählt) - eine Zeilennumer (ab 0 gezählt) - eine Anzahl auszugebender Zeichen. Falls diese Länge nicht reicht, werden nur # ausgegeben als Zeichen, daß es zuwenig war. Wenn die Ausgabe weniger Platz braucht, wird das Feld mit Leerzeichen aufgefüllt. Das ist nett, wenn man Werte gezielt in Bildschirmbereiche schreiben will. Ohne diese maximale Anzahl würde ja bei kurzen Ausgaben der alte Inhalt hinten dran kleben. Ich habe es mit allen LCDs getestet, derer ich habhaft werden konnte (siehe Kommentar in LCD4470.h). Wer es mit anderen probiert, könnte so nett sein und mir Bescheid sagen, ob und wie es damit klappt. Insbesonder die 1x16-Varianten habe ich nicht, würde sie aber gerne mal probieren (lassen). Man kann damit auch 4x40-LCDs mit 2 Controllern verwenden (zwei Parameter mehr beim Initialisieren für Port+Pin des zweiten Enable-Signals). Außerdem können mehrere LCDs an einem MV verwendet werden. Dann dürfen sich die Pinbelegungen überschneiden, müssen aber nicht. Nur das Enable (bzw. beide Enable bei 4x40) aller LCD müssen auf unterschiedlichen Pins liegen. Die *_P()-Versionen nutzen Strings aus dem Flash. Das sonst kursierende Makefile ist nicht für C++ geeignet (es löscht beim Übersetzen die Quelltexte :-); deshalb lieber meines nehmen und je nach Projekt anpassen. Die C++-Datei ist nur als Vorlage zur Verwendung dabei. Für die Routinen selbst ist kein Quelltext nötig außer der Headerdatei LCD44780.h, also auch kein Eintrag im Makefile.
PS: die Definition von eigenen Zeichen ist BNaustelle, die hatte ich angefangen und nicht mehr getestet. Das kommt mal, wenn ich mehr Zeit habe.
Klaus Wachtler schrieb: > Außerdem können mehrere LCDs an einem MV verwendet werden. Dann dürfen Besser: Außerdem können mehrere LCDs an einem MC verwendet werden. Dann dürfen
Jein. Einige Sachen von C++ klappen prima und ermöglichen für lau elegantere Wege als C (inline, Überladen von Funktionen und Operatoren), anderes sollte man vermeiden wie der der Teufel das Weihwasser (z.B. intensive Nutzung virtueller Funktionen). Solange man aufmerksam ist spricht nichts dagegen, EINIGE Möglichkeiten von C++ zu nutzen (außer der inneren Trägheit, wenn man alles jahrelang in C gemacht hat).
Bei dem LCD-Beispiel ist C++ zugegebenermaßen ein nettes Gimmick, aber nicht unbedingt nötig. Gegenüber C nutze ich hier: - Referenzen als Parameter, das spart lästige Pointer und ermöglicht z.B. beim Initialisieren die schnöde Übergabe eines Registers wie PORTA, wodurch dann intern automatisch die Adressen der DDRx berechnet werden -> einfachere Verwendung der Lib als in C, bessere Kapselung - OO: man kann mehrere LCDs initalisieren und einfach in der Art lcd1.printf... und lcd2.printf... verwenden - automatisches Inlining - exakt dieselbe Schnittstelle zum Aufrufer lässt sich für andere MC genauso definieren, dadurch hat der Aufrufer weniger systemspezifisches im Code (nur falls sich jemand die Mühe macht, das für andere MC zu portieren, also hypothetisch) - Überladen von Funktionen (vermeidet viele kryptische Namen, die ich mir eh nicht merken kann) - Bessere Trennung von internen und externen Dingen durch private und public; nur was der Aufrufer verwenden soll, ist public. Bei den bisherigen Lösungen steht zum Einen im Bereich des Aufrufers immer irgend etwas, was eigentlich in die Lib gehört, und andererseits muß die Headerdatei je nach aktuellem Projekt geändert werden, um z.B. Pinzuordnungen zu ändern. -> C++ sorgt für mehr Sicherheit und Klarheit, Lib und Anwendung sind sauberer getrennt Wesentlich mehr Vorteile von C++ sieht man bei so etwas wie der Festkommageschichte: Beitrag "Festkommazahlen in Würde" Das geht in reinem C überhaupt nicht befriedigend.
Nicht zu vergessen, das in C++ enums so funktionieren, wie sie in C eigentlich schon immer hätten funktionieren sollen. Für mich ist so etwas wichtig. Denn so etwas card.setColor( King ); soll gar nicht funktionieren, sondern einen Fehler geben. King ist ein Kartenwert (von Spielkarten ist die Rede) und keine Farbe.
Ja, stimmt. (Hast wohl nix zu tun im andern Thread? :-) Das ist da ja wie bei den Ghostbusters. Kaum glaubt man, das Biest wäre tot, zischt es wieder aus irgendeiner Ritze.)
Klaus Wachtler schrieb: > Ja, stimmt. > > (Hast wohl nix zu tun im andern Thread? :-) > Das ist da ja wie bei den Ghostbusters. Kaum glaubt man, > das Biest wäre tot, zischt es wieder aus irgendeiner Ritze.) Stimmt. Obwohl: Ich denke er hat es immer noch nicht verstanden. Den Exkurs "was ist denn jetzt eigentich volatile", je nach Schreibweise, spar ich mir für heute. Er schwimmt auch so schon genug bei Pointern.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.