Hallo! Habe ein Powertip LCD-Display, 4x20 Zeichen und einen C167 µC. Wenn ich das Display anschließe, leuchten überhaupt nur die erste und dritte Zeile (Kontrast läßt sich hier regeln), die anderen beiden bleiben weiß. Jeder Versuch, dem Display einige Zeichen zu entlocken, schlug bisher fehl. Hat vielleicht zufälligerweise jemand einen C++ Sourcecode für den den C167er für ein solches oder ähnliches Display mit HD44780-Controller? Danke, Harry
Welches ist die haeuftigste gestellte Frage in dieser NG ? Mit welchem Thema befassen sich die absolut meisten von Hobbyelektronikern erstellten WebSeiten ? Warum liest man nicht erst die FAQ und folgt dann dem darin enthaltenen Link
formatting link
(Handbuch für alfanumerische) wenn man Problem mit dem Zeug hat ?
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
Ja. Um das Busy-Flag nicht abfragen zu müssen, warte ich lang genug.
5ms zB sollten ausreichend sein.
Zuerst im 8-Bit Modus an Port 6 die Daten und an Port 2 RS, RW und E. Dann im 4-Bit Modus alles an Port 6.
"cooles" C++
Freilich, warum auch nicht? C++ wurde schließlich, so wie die meisten anderen höheren Programmiersprachen auch, erfunden, um nicht alles in Assembler coden zu müssen. Wenn Du lieber in Assembler schreibst, sei Dir das freigestellt. Aber bitte räume anderen die Freiheit ein, in C++ zu programmieren. Für konstruktive Hilfe bin ich übrigens dankbar. LG Harry
Wie hast Du das Display denn an den C167 angeschlossen? Direkt am Bus ist der C167 wohl zu fix für das Display... Wenn Du den Zugriff per Port-Bit-Bangig machst, dann solltest Du Dir die Timingdiagramme mal genau ansehen und nachbilden (falls Dich C++ nicht daran hindert).
MaWin hat Dir ja schon ein Dokument genannt, da solltest Du Kapitel 2.2.2. mal ganz genau durchlesen und die in den Diagrammen angegebenen Zeit sklavisch (eher etwas länger) einhalten, denn bei der Initialisierung ist der HD44780 sehr pingelig. Hilfreich ist hier ein Scope um das ganze auch mal direkt nachzuprüfen. Ich kenne Deine Software-Entwicklungsumgebung nicht und weiß daher nicht "wie nahe Du an der HW" programmieren kannst und wie Du exakte Timings abschätzen/einhalten kannst.
Da ich den C167 nicht in C/C++ programmiere gibts auch keine Code von mir sondern nur einen freundlichen Gruß und lass den Kopf nicht hängen, das Datenblatt vom HD44780 haben wir alle fressen müssen ;-)
Ingolf
PS: Irgendwo in der PC-Welt wird der HD44780 doch auch für die Case-Modder und PC-Videorecorder-Bauer mit C/C++ betan, oder?
Ich hab da was, das hier auf einem M16C läuft (2x20 Zeichen). In initDipslay() wird voher noch der D/A-Wandler für die Kontrasspannung eingestellt. Im Grunde mußt Du nur die beiden letzten Funktionen ReadDevice() und WriteToDevice() an Deine Ports anpassen. Vorraussetzung ist natürlich, dass Dein Timing funktioniert. P0 ist der Datenbus, P1_1 ist E, P2_1 ist RS und P2_0 ist R/W. pdXX sind die Direction register und puXX sind pull-up register.
Es gibt aber noch andere Timings außer das BUSY-Flag. z.B Müssen bestimmte SETUP und HOLD Zeiten eingehalten werden.
Sollte beides gehen...
Aber gerade bei embedded Systeme oder auch uC-Schaltungen wird der Speicherbedarf enorm durch den C++ overhead strapaziert.
Ich verwende Assembler nur für die LOW LEVEL TREIBER wie z.B. für die Treiber um das LCD-Display anzusteuern. Da kann ich mir das Timing (mit dem Du höchst wahrscheinlich Probleme hast) aus den Taktzyklen zusammen rechnen und brauche nicht irgendwelche delay() oder wait() Funktionen aufrufen....
Du darfst gerne in C++ programmieren. Nur manchmal wird C++ auch überbewertet. Da werden sämtliche Funktionen gekapselt hier ein Objekt erstellt das dann wiederum als Vorlage für eine Abstraktion genommen wird weil doch nicht alle Memberfunktionen das Richtige Verhalten haben ....
Du kannst natürlich auch sagen das Du in C++ programmierst und letztlich doch nur C-Standard(einfache Funktionen, keine Objekte (außer "strucs")) verwendest.
In meinen Augen macht C++ bei Datenbanken und grafischen Oberflächen (KDE, Windows) einem das programmieren leichter aber bei kleinen uC-Schaltungen (und hierzu zähle ich auch einen 16Bitter) ist es meiner Meinung nach vollkommen übertrieben.
Natürlich darf jeder in der Sprache programmieren die er für Richtig hällt. Egal ob es BASIC, C, C++, Fortran, Pascal, Delphi oder auch Assembler ist. Ich werde z.B. auch öfters ausgelacht weil ich einen AVR z.T. in C programmiere (bis auf LOW LEVEL Funktionen) nur weil andere meinen C ist vollkommen übertrieben. Ich habe aber keine lust mich Stundenlang damit zu beschäftigen wie ich die Speicheraufteilung und wie ich die Register verwende. Das überlasse ich dann doch lieber dem Compiler ... und der AVR-GCC macht das meiner Meinung nach recht Ordentlich.
Also, mein Tipp schau Dir das Timing am LCD am besten mal mit einem Oszi an und vergleiche das gemessene mit dem gedruckten.
Ich habe nie behauptet das ich C/C++ Programmierer bin. Ich habe lediglich versucht darzustellen das C++ in vielen Fällen vollkommener Blödsinn ist.
Aber laß es mich anders versuchen:
Assembler Programmierer sind die besseren C Programmierer und C Programmierer sind die besseren C++ Programmierer...
.. weil bei jeder nächst höheren Abstraktionsstufe das Wissen (und die Kenntniss) von der Hardware verlohren geht und vom Programmierer auf den Comiler übertragen wird.
Gut, für Datenbanken brauche ich nicht zu wissen welches IC wie funktioniert. Aber es ging hier um die Ansteuerung eines LCDs und das ist nunmal Hardware pur.
Das war mal so, aber bei den heutigen Compilern und großer Hardware ist es schon verdammt schwer, optimierteren Assemblercode zu schreiben als ein guter Compiler.
VLIW kann man fast gar nicht mehr im Kopf optimieren.
Das ist zwar noch Big Iron im Vergleich zu uCs, aber die Technik wird ja durchgereicht.
Ansteuerung eines LCD ist auch eigentlich schon weit weg von Hardware. LCD-Displays selbstbauen wäre Hardware... Ok, sag ich als Physiker ;)
Google 'c167+hd44780' eingeben, gleich der erste Treffer...? Wenns wirlich nicht klappen sollte mail an mich, ich hab noch irgendwo einen source rumliegen (der IMO aber nicht so elegant über den Adressbus geht, dafür aber keine zusätzliche Hardware braucht).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.