Hallo,
ich heute ein 4x27 Zeichen LCD (das von Pollin) an meinem ATmega8
angschlossen und es funktioniert bei einm Takt von 1 MHZ recht gut
(manchmal Störungen).
Doch wenn ich dann 4 oder 8 MHZ einstelle und natürlich auch den Code
anpasse, kommt das Display nichtmehr zurecht.
ich benutze eine eigens für dieses Display angefertigte Lib.
(wintek2704) basiert auf der von P. F.
Vielleicht weiß jemand von euch woran es liegen könnte?
jonas
"Vielleicht weiß jemand von euch woran es liegen könnte?"
Ja, an Deiner Library...
Gib mal mehr Details, wie z.B. hast Du den Code angepaßt?
Was passiert bei höherer Geschwindigkeit?
Benutzt Du das Busy-Flag?
Die Lib. ist extra für dieses Display gemacht worden, das es über 2
Controller verfürgt.
Die Lib muss so nicht an das Display angepasst werden.
mit code angepasst meine ich, dass ich in der makefile die F_CPU neu
eingestellt habe.
Busy-Flag - Dazu habe ich mir keine weiteren gedanken gemacht, denke in
der Lib wird es benutzt wenn ich die funktion für das schreiben von
texten benutzte.
Es sind auch alle Pins für die 4-Bit Methode angschlossen.
RS
R/W
E1
E2
D4
D5
D6
D7
jonas
Ja ich ändere die Frequenz im Code und natürlich auch an der hardware.
Ich benutze den internen taktgeber des Contollers doch auch mit externen
4 mhz quarz klappt es nicht.
ja es werde mehrere delay routinen benutzt.
jonas
Hallo jonas,
vor der (vollständigen) Initialisierung funktioniert
die Abfrage des "Busy-Flag" nicht. Da müssen auf jeden
Fall die "Delays" angepasst werden.
Gruss Otto
Also ich habe mit dem 4x27-LCD von Pollin keine Probleme. Ich betreibe
es u.a. auch am Mega8 mit 7,3728 MHz. Allerdings nicht in C, sondern in
Assembler, und nicht mit zusammengefundenen Bibliotheken sondern mit
meinen eigenen Routinen.
...
Hannes, recht hast du, statt sich mit dem Datenblatt des Display
auseinanderzusetzen und sich das bischen Code selbst zu schreiben
handelt jeder dritte Thread von irgendeiner LIB die mal wieder nicht
funktioniert.
Joe wrote:
> Hannes, recht hast du, statt sich mit dem Datenblatt des Display> auseinanderzusetzen und sich das bischen Code selbst zu schreiben> handelt jeder dritte Thread von irgendeiner LIB die mal wieder nicht> funktioniert.
Ich kann ja verstehen, dass man das Rad nicht erneut erfinden möchte.
Ich meine aber, dass es sehr hilfreich ist, wenn man seine Funktion
versteht.
Dass fremde LIBs nicht funktionieren, liegt selten an den LIBs, sondern
eher an Missverständnissen zwischen "Macher" und Nachnutzer. Wie bereits
gesagt, das Verständnis der Funktion erleichtert die Handhabung...
;-)
...
> Ich kann ja verstehen, dass man das Rad nicht erneut erfinden möchte.
Wenn ich mir die LIB ansehe dann scheint es dringend geboten. Ich komme
mit 263 Byte inklusive "Startup Code" hin.
Diese Codemonster sind grausam und überfordern jeden Anfänger, was
meinst du warum jeder dritte Thread mit dem Betreff "Mein LCD geht
nicht" daherkommt ?
Das Problem an den Libs ist, dass diese entweder nur für einen uC
speziell gemacht sind (vor allem wenn z.B. Timer oder andere Sachen
verwendet werden die sich je nach AVR unterscheiden), oder aber mit
einer Unmenge an #ifdef usw. sich selbst an den jeweiligen AVR anpassen.
Dann muss man manchmal schon ziemlich gut C können um wirklich den Code
verstehen zu können.
Außerdem enthalten vollständige Libs alle möglichen Funktionen wie die
Ausgabe von Zahlen, Strings aus Flash und RAM usw. In einem
durchschnittlichen Programm braucht man vermutlich nicht mal 50% dieser
Funktionen.
Noch schlimmer ist, wenn auch Hardwarefehler nicht auszuschließen sind
(was eigentlich immer der Fall ist).
Das allerschlimmste ist, wenn die Anwender der Libs Null Ahnung haben
(weder von uC noch von Elektronik). Dann laufen AVR und LCD auch mal an
12V, und der Fehler liegt natürlich in der Lib von jemand anderem...
Joe wrote u.a.:
> was> meinst du warum jeder dritte Thread mit dem Betreff "Mein LCD geht> nicht" daherkommt ?
Weil viele Menschen faul sind und mal schnell fremden Code oder fremde
LIBs nutzen wollen, ohne sich damit vertraut gemacht zu haben.
Ich habe Hochachtung vor C-Programmierern, die in der Lage sind,
effizienten Code zu schreiben (und dementsprechend auch ASM beherrschen
um ihren Code zu prüfen). Ich finde es aber lächerlich, wenn jemand
meint, durch das Benutzen einer Hochsprache mit fremden LIBs um
ASM-Grundkenntnisse, Verständnis der Architektur des MC und Verständnis
der verwendeten Peripherie drumherum zu kommen. Ich rede vom AVR, nicht
vom PC oder anderen Systemen mit OS.
...
danke das ihr euch soviele gedanken macht.
Was das verständniss der Lib angeht:
ich habe keine probleme die Lib an den Atmega 8 und un meine
Portkonfiguration anzupassen.
auch das schreiben von texten funktionier mit 1 mhz gut. nur ich
dachte, dass jemand von euch vll. ähnliche probleme hat und eine lösung
weiß.
ich werde jetzt selber ein paar funktionen die ich brauche un C
schreiben, da ich dann wenigstens weiß was mein code macht. (C ist
nicht so das problem habe auch schon mehrere binär-uhren programmiert
die ohne probleme mit wenig code auskommen.)
achso ich werde jetzt nochmal alles an einem ATmega32 mit gutem nezteil
usw. testen und dan vll. schon die lösung haben.
mfg
jonas
Jonas,
ich freue mich das du die Kritik positiv aufgenommen hast. Super das du
es durch eine eigene Lösung hinbekommen hast. Glaub mir, jetzt hast du
was gelernt ;-))
Marco Schwan wrote:
> poste doch mal die lib schons kann man dir nie helfen
Ihm wurde doch bereits geholfen...
Oder wurde er geholfen??? - Egal, er schreibt doch, dass es jetzt
funktioniert. Und nur das zählt.
@Jonas:
Gratuliere, und viel Erfolg weiterhin...
...
> sorry die erfolgsmeldung habe ich nicht war genommen.
passiert im Gedränge* auf'm Frauenklo.....
* Gedränge: Spielsituation beim Rugby, bei der nur die Füße aus dem
Knäul herausragen