Umstieg von AT90S8535 auf ATMEGA16 macht Probleme

[Malte Marwedel (Gast)]

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?

[Fritz Ganter (Gast)]

Die LCD Routinen sind empfindlich beim Timing. Es sollte reichen, wenn
du die delay Routine, die dort benutzt wird, anpasst.

[Malte Marwedel (Gast)]

>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.

[Malte Marwedel (Gast)]

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. :-|

[Malte Marwedel (Gast)]

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
}