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
Angehängte Dateien:
-
fusebits.pg.jpg
69 KB
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.
Schau mal Deine Fuses an und setz mal JTAGEN auf disable. Damit solltest Du PORTC wie gewohnt verwenden können. Gruß, Sam
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.
Der Vollständigkeit halber auch gerne noch das Makefile anbei...
Ich meine, dass F_CPU vor dem Aufruf der Datei delay.h definiert sein muss. Delay.h hat so seine Tücken. Bin mir aber nicht sicher!
1 | #ifndef F_CPU
|
2 | #define F_CPU 8000000UL
|
3 | #endif
|
4 | #include <util/delay.h> |
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.
Mal mit andere LCD routine probiert?
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 :-)
Meistens sind's ganz banale Dinge, wie zb das falsche Hex-File in den µC geflasht.
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!
Anbei das komplette Verzeichnis inkl. meiner HEX-Datei und Makefile. Danke.
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.
Hmm, ich habe dort keine Projektdatei. Ich öffne einfach die main.c und gehe oben auf Tools und Make All. Dann compiliert es mir.
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.)
|
4 | OPT = s |
Probier mal O0, O1, O2 oder O3 aus.
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...
>Das komische ist ja, dass das identische makefile im AVRStudio geht, im >Programmes Notepad ja nicht, sprich auch mit gleicher >Optimierungseinstellung. Wenn ich die main.lss von dir und mir vergleiche fehlen da folgende Zeilen bei dir: 00000084 <__do_copy_data>: 84: 11 e0 ldi r17, 0x01 ; 1 86: a0 e0 ldi r26, 0x00 ; 0 88: b1 e0 ldi r27, 0x01 ; 1 8a: e4 e2 ldi r30, 0x24 ; 36 8c: f3 e0 ldi r31, 0x03 ; 3 8e: 02 c0 rjmp .+4 ; 0x94 <.do_copy_data_start> 00000090 <.do_copy_data_loop>: 90: 05 90 lpm r0, Z+ 92: 0d 92 st X+, r0 00000094 <.do_copy_data_start>: 94: a0 30 cpi r26, 0x00 ; 0 96: b1 07 cpc r27, r17 98: d9 f7 brne .-10 ; 0x90 <.do_copy_data_loop> 0000009a <__do_clear_bss>: 9a: 11 e0 ldi r17, 0x01 ; 1 9c: a0 e0 ldi r26, 0x00 ; 0 9e: b1 e0 ldi r27, 0x01 ; 1 a0: 01 c0 rjmp .+2 ; 0xa4 <.do_clear_bss_start> 000000a2 <.do_clear_bss_loop>: a2: 1d 92 st X+, r1 000000a4 <.do_clear_bss_start>: a4: a0 30 cpi r26, 0x00 ; 0 a6: b1 07 cpc r27, r17 a8: e1 f7 brne .-8 ; 0xa2 <.do_clear_bss_loop> aa: 0e 94 63 00 call 0xc6 ; 0xc6 <main> ae: 0c 94 90 01 jmp 0x320 ; 0x320 <_exit> Also im Prinzip der komplette Startupcode der data und bss initialisiert. Warum das bei Programmers Notepad so ist kann ich dir aber auch nicht sagen. Ich hab das einfach ohne Änderung mit "make clean" und dann "make all" aus deinem Code übersetzt.
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.
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.