Hallo,
ich habe eine LCD mit HD44780 Controller. Der Code ist aus dem Tutorial
und an meine Port Belegung angepasst. Die Schaltung hat einen 8Mhz
Quarz, Frequenz ist entsprechend eingestellt.
Auf dem Atmega8 läuft das Ganze hier problemlos, Display initialisiert
und ich kann Dinge ausgeben.
Nun habe ich im M-File statt dem Mega8 einen Mega168 eingetragen, da
später alles darauf laufen soll und den Prozessor getauscht. Mega168
entsprechend die Fusebits gesetzt, dass er mit 8Mhz Quarz läuft, CDIV
Fuse nicht aktiv.
Leider initialisiert das Display dort nicht mehr. Habe auch den internen
Oszi (8Mhz CDIV nicht aktiv) erfolglos versucht. Rückgbau auf Mega8 und
Display läuft wieder. Da die beiden Pin-kompatibel sind und ich an der
Ansteuerung nichts geändert habe, weiß ich im Moment nicht, wo der
Fehler sein kann. Richtiger Takt ist 100% eingestellt, daher sind die
delay Zeiten identisch.
Hat einer einen heißen Tipp, wo man noch nach einem Fehler suchen
könnte?
Gruß
Pin kompatibel heisst nicht zwingend Code kompatibel, auch wenn der
Befehlssatz der Gleiche ist. Den ploetzlich sind die Register an einem
anderen Ort, und wenn man die Register anspricht, geht
Out Reg,Data
nicht mehr, sonder man muss ueber
STS ...
raus. Schau mal ins manual der beiden controller.
Sven schrieb:> Hat einer einen heißen Tipp, wo man noch nach einem Fehler suchen> könnte?
Ja.
Im nicht gezeigten Code.
Ich finds lustig, daß man die Leute hier immer für Gedankenleser hält.
Peter
So anbei der Code in der main.c. In der lcd.h sind die Ports angepasst
auf meine Display-Belegung (diese Datei ist UNVERÄNDERT und wird so auch
beim Mega8 verwendet).
Ebenso die Datei main.c ist unverändert.
Die einzige Änderung die ich gemacht habe, ist im m-file den Typ von
Atmega8 auf Atmega168 umgestellt.
Hallo Sam,
meinst du die SPIEN fuse?
Diese kann ich mit meinem normalen ISP nicht verändern.
War auch so von Werk, der Chip war gestern noch jungfräulich...
Martin schrieb:
> meinst du die SPIEN fuse?
Der Atmega168 hat kein JTAG. Wenn du den SPIEN deaktivierst dann kannst
du den Atmega nicht mehr über ISP flashen.
Ok, habe nämlich gerade das Datenblatt danach abgesucht und auch nichts
gefunden. Ebenso wir mir ja keine Fuse angezeigt.
Das Problem ist aber dennoch ungelöst :-(
Martin schrieb:> Die einzige Änderung die ich gemacht habe, ist im m-file den Typ von> Atmega8 auf Atmega168 umgestellt.
Und du hast hoffentlich auch darauf geachtet, dass nach dem Make dann
auch tatsächlich alles neu kompiliert und gelinkt wurde?
Ob deine Fuse-Umstellung für die Taktfrequenz geklappt hat, hast du
kontrolliert?
(Nicht glauben das ... sondern kontrollieren. IM einfachstn Fall ein
Testprogramm schreiben, welche mittels _delay_ms( 1000 ) eine LED
blinken lässt. Dann sieht man sehr schnell ob die Geschwindigkeit passt)
Karl Heinz Buchegger schrieb:> Und du hast hoffentlich auch darauf geachtet, dass nach dem Make dann> auch tatsächlich alles neu kompiliert und gelinkt wurde?
Ja, ich habe nochmal sämtltiche Dateien außer .c, .h und das Makefile
gelöscht.
Habe zwei LEDs an PORTB eine und an PORTD eine und den angehängten Code.
LEDs leuchten abwechseln jede für 1 Sekunde, aber das Display streikt
weiterhin.
Stecke ich den Mega8 auf mit gleichem Code wird das Display
initialisiert.
Danke für den Tipp, leider hat es nichts gebracht.
Die LEDs haben ja den richtigen "Blinkrythmus", daher sollte die delay
Funktion klappen. Ebenso bin ich der Ansicht, dass wenn die Frequenz im
makefile angegeben ist, dieses #define sowieso hinfällig ist...
Aber dennoch nochmals danke, bin für jeden Hinweis froh, da das hier
echt zum Mäuse melken ist. Gleiche Schaltung, gleicher Code, nur anderer
Prozessor und es geht nicht mehr.
Habe auch mittlerweile einen zweiten fabrikneuen Mega168 versucht,
gleiches Phänomen.
Hallo,
nein, aber die Routine initialisiert ja das LCD mit dem Mega8 und exakt
identischem Code. Daher glaube ich nicht, dass es an der Routine liegt.
Habe auch mal die delay-Zeiten der Routine um 25% erhöht, hat aber auch
nichts gebracht (es ist ja auch imho die gleiche Schaltung, d.h. auch
gleicher Quarz...)
Hallo Holger,
deine HEX-Datei funktioniert.
Display zeigt in Zeile1 "Line1" und in Zeile2 "Line2".
Wenn du mir jetzt noch verätst, wo der Unterschied zwischen deiner und
meiner Routine genau liegt, wäre ich für heute Abend wohl der
glücklichste Mensch :-)
Leider kann ich diesen Fehler auch ausschließen.
Habe eben mal noch einen Mega88 genommen, gleiches Programm. Läuft dort
ebenfalls nicht. Nehme ich das für Mega88 kompilierte HEX-File und
spiele dieses HEX (compiliert für Mega88!) auf den Mega8, initialisiert
er das Display ohne Weiteres.
Das Mysterium lässt sich wohl nur durch Holger klären, also muss ich
mich gedulden :-)
>deine HEX-Datei funktioniert.>Display zeigt in Zeile1 "Line1" und in Zeile2 "Line2".>Wenn du mir jetzt noch verätst, wo der Unterschied zwischen deiner und>meiner Routine genau liegt, wäre ich für heute Abend wohl der>glücklichste Mensch :-)
Erst noch mal dein eigenes Programm probieren, siehe Anhang.
Habs mal für dich übersetzt mit deinem makefile.
Hallo Holger,
zunächst noch einmal hierfür vielen Dank.
Ich kann auch hier positive Rückmeldung geben, das Programm
funktioniert. LEDs blinken, Display Zeigt TEST und Hallo Welt wie es
soll...
Aber wo liegt nun mein Fehler?!?
>Aber wo liegt nun mein Fehler?!?
Nirgends, ich hab alles so gelassen wie es war.
So wie es aussieht hast du nach Änderung des makefiles
dein Programm nicht komplett neu übersetzt (oder ein anderes?).
Oder wie Karl Heinz schon sagte die falsche HEX Datei gebrannt.
Wenn du selber am makefile was änderst machst du am besten
erstmal "make clean". Das entsorgt alte Dateien die dann
neu übersetzt werden müssen.
Ist zwar unwahrscheinlich, aber die Compilerversion könnte es auch noch
sein. Ich hab allerdings auf die Schnelle keine Errata gefunden, die
irgendwie weiter Licht ins Dunkel bringen.
Ich denke auch, dass du die ganze Zeit das Mega8-Hex erstellst/brennst.
Das hier
> Nehme ich das für Mega88 kompilierte HEX-File und spiele> dieses HEX (compiliert für Mega88!) auf den Mega8, initialisiert> er das Display ohne Weiteres.
passt genau in das Schema.
Also ich komm nicht weiter.
Ich nutze avr-gcc (WinAVR 20100110) 4.3.3.
Habe nun make_clean und neu kompiliert. Habe das Verzeichnis geändert
und aus dem neuen Verzeichnis geflasht.
Habe vom festen PC auf Laptop umgestellt, dort nochmals WinAVR
installiert, neu kompiliert, das gleiche.
>Ich nutze avr-gcc (WinAVR 20100110) 4.3.3.
Mein Compiler ist noch 4.3.0.
>Habe nun make_clean und neu kompiliert. Habe das Verzeichnis geändert>und aus dem neuen Verzeichnis geflasht.>Habe vom festen PC auf Laptop umgestellt, dort nochmals WinAVR>installiert, neu kompiliert, das gleiche.
Hört sich alles sehr komisch an.
Pack dein aktuelles Verzeichnis doch mal in ein ZIP und poste es hier.
Aber bitte nichts daran ändern!
Also ich habe es jetzt mal in AVRStudio kompiliert, darin gehts.
Zuvor hatte ich es direkt aus dem Programmers Notepad aus dem WinAVR
kompiliert und damit ging es nicht.
Trotzdem ein wenig seltsam, da ich bisher alle Projekte problemlos im
Programmers Notepad erstellt und kompiliert hatte...
Falls jemand eine Idee hat, woran das liegt oder warum dies so ist, wäre
ich noch dankbar.
Ansonsten habe ich zu danken, bei allen die versucht haben zu helfen.
>Zuvor hatte ich es direkt aus dem Programmers Notepad aus dem WinAVR>kompiliert und damit ging es nicht.
Na dann zeig mal deine Projektdatei für Programmers Notepad.
Ich denke das es daran liegt.
Nach meiner Erfahrung sind das oft Optimierungsprobleme in den
Zeitschleifen (Timing). Nimm mal die Optimierung des Compilers heraus.
In deinem Make-File steht sie auf OPT=s:
1
# Optimization level, can be [0, 1, 2, 3, s].
2
# 0 = turn off optimization. s = optimize for size.
3
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
Bernd Eckebrecht schrieb:> Nach meiner Erfahrung sind das oft Optimierungsprobleme in den> Zeitschleifen (Timing).
Ganz im Gegenteil, die Delay.h des AVR-GCC benötigt die Optimierung,
vorzugsweise -Os.
Mit -O0 geht sie total falsch.
Peter
Richtig, das habe ich über die Suche auch schon herausgefunden als
Fehlerursachen mit der Optimierung, aber die ist ja richtig
eingestellt...
Das komische ist ja, dass das identische makefile im AVRStudio geht, im
Programmes Notepad ja nicht, sprich auch mit gleicher
Optimierungseinstellung.
Mir ist es immernoch rätselhaft, aber nun ja. Werde ich es eben im
AVRStudio kompilieren. Falls jemand noch eine Idee hat, woran es liegt,
gerne her damit.
Das Programm hat übrigens im Programmers Notepad ein paar byte weniger
(0,2% weniger Speicher) als in AVRStudio kompiliert.... Auch seltsam,
aber wohl der kleine Unterschied...
Hallo,
Hatte vor kurzem ein aehnliches problem mit avg-gcc in linux. Es hat
sich herausgestellt, das nach einem update des compilers und der
avr-libc, die delay-routinen ploetzlich etwas ahem.. 'kuerzere'
millisekunden benutzten, was dazu fuehrte, dass das display nicht
initialisierte. Den code fuers display hatte ich urspruenglich aus einer
avr-libc beispieldatei. Ein oberflaechlicher vergleich war recht
erleuchtend, denn es waren ploetzlich neue delays vorhanden, die im von
mir benutzten(alten) code noch fehlten.
Ein anderer belieber stolperdraht, den Ich auch schon ausprobieren
durfte, betrifft 'nop' Instruktionen. Neuere compiler versionen, meinen
mehrere 'nop's in einzelnen asm-statements wegoptimieren zu duerfen. Mit
einem einzelnen asm statement und mehreren 'nop's hingegen funktioniert
es.
