Aus Speicherplatzgründen habe ich den AT90S8535 in meiner Schaltung (DCF77 Uhr) durch einen ATMEGA16 ersetzt. Ich habe alle Register die AVRGCC 20030913 beim Compilieren als ungültig anzeigte wie im Datenblatt (Replacing AT90S8535 by ATMEGA8535) von ATMEL entsprechend durch die neuen Namen ersetzt. Das Fusebyte habe ich von 11100001 auf 1111111 geändert um einen externen 4MHZ Quartz benutzen zu können. Das hohe Fusebyte habe ich von 10011001 auf 11011001 gesetzt um die JTAG Pins normal benutzen zu können. Zum Programmieren und Setzen der Fusebytes verwende ich sp12. Nun die auftretenden Effekte: Das UART sendet wie erwartet einen Text, der mir mitteilt, dass die Uhr neugestartet wurde. Die 7 Segment-Anzeigen zeigen jedoch nur unverständliche Symbole an. Wenn ich an den AVR per RS232 den Befehl sende mit mir zu kommunizieren, werden die ersten zwei Zeilen halbwegs Korrekt übertragen, dann löst der Watchdog aus. Im AT90S8535 lief das Programm seit über 6 Wochen (ununterbrochen) größtenteils ohne Fehler. Habe ich irgendwas übersehen, was ich noch ändern muss?
Die LCD Routinen sind empfindlich beim Timing. Es sollte reichen, wenn du die delay Routine, die dort benutzt wird, anpasst.
>Die LCD Routinen sind empfindlich beim Timing. Es handelt sich um 7-Segment LED Anzeigen, die im Multiplex Verfahren durch Timer 3 gesteuert werden. Nur in den ersten 0,5-1 Sekunden zeigen die LEDs korrekt 0:00 Uhr an. Beim Versuch über RS232 zu kommunizieren erhalte ich die Infos über die eingestellte Uhrzeit, die mehr oder wenige willkürlich wechselt. Danach gibts einen Watchdog Reset. Auch beim Verwenden eines anderem Netzteils gabs den gleichen Effekt. Als Anhang mal, wie die Anzeige aussieht.
Also ich hab jetzt mal ein simples Programm geschrieben, was nichts weiter tut als eine Variable raufzählen und diese direkt (als Binärzahl) auf den LEDs auszugeben. Um dass Programm ungefähr genau so groß zu machen wie das nicht funktionierende, hab ich ein paar tausend mal asm volatile ("nop"); an den Anfang des Programms geschreiben. Das Programm läuft fehlerfrei. Somit muss es wohl an meinem Programm liegen. Was ich aber nicht verstehe, da es ja im AT90S8535 eindanfrei läuft. Mal sehn wie weit ich das Prog abspecken muss, bis es läuft. :-|
So, das Programm läuft jetzt. Die Ursache dass es vorher nicht ging lag darin, dass beim AT90S8535 nur die untere 3 Bit des ADMUX Registers beschrieben werden konnten. Weil ich 0 Byte Flash frei hatte, hab ich gespaart wo es ging und mich darauf verlassen, dass beim schreiben einer 8 nur die unteren 3 Bit beschrieben wurden, also beim Auslesen eine 0 erwartet wird. Da nun diese Zahl auch dafür verantwortlich ist, in welche Stelle eines Arrays Werte geschrieben wurde und für das Array nur Speicherplatz für 8 Einträge reserviert war, wurden im ATMEGA16 die nachfolgenden Variablen überschrieben... Die untere if-Anweisung in der unteren Interrupt Routine war es, die Fehlte: SIGNAL(SIG_ADC) { u08 nowconvert; cconv += ADCW; convno++; if (convno == 32) { //Wenn 32 Convertierungen convno = 0; nowconvert = inp(ADMUX); //ermittle, welcher Kanal verwendet wurde adwerte[nowconvert] = cconv / 32; //schreibe A/D Wert in Array nowconvert++; if (nowconvert == 8) { //Beim ATMEGA16 nötig, da hier alle Bits des ADMUX beschreibbar sind nowconvert = 0; } outp(nowconvert,ADMUX); //Nächsten A/D Kanal (nur die unteren 3 Bit von ADMUX sind im AT90S8535 schreibbar) cconv = 0; } sbi(ADCSR,ADSC); //Setze Bit, um neue Konvertierung zu starten }
Bitte 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.