|
Anzeige
|
AtMega162 resettet dauernd
Gast
#1783092
Gibt es irgendeinen Trick den ich nicht kenne warum mein Mega162 nicht startet ? Mein ursprüngliches Programm war für einen AtMega8 hab es dann quasi genauso für den 162 übernommen . Den Reset Pin habe ich nicht beschaltet Fuses stimmen ?. Hat jemand eine Idee ?
Gast
#1783097
Chris schrieb: > Hat jemand eine Idee ? Ja.
Gast
#1783099
Und zwar ;-) Warum hast du den Reset-Pin in der luft hängen?
Gast
#1783116
Brown-Out Detection oder Watchdog aktiv?
Gast
#1783131
gonzo schrieb: > Brown-Out Detection oder Watchdog aktiv? Nein beides zum Test deaktiviert .5V liegen aber einwandfrei an . Habe auch ein Display angeschlossen .Da sieht es aus als würde es ständig neustarten quasi wie bei watchdog zb - Wie gesagt ist aber beides aus ?!. Chris schrieb: > Habe auch ein Display angeschlossen .Da sieht es aus als würde es > ständig neustarten quasi wie bei watchdog zb - Mit 'sieht so aus' kommt man nicht weiter. Programm modifizieren: Als erstes wird in main() ein Ausgang konfiguriert, eine LED eingeschaltet und eine halbe Sekunde gewartet. Danach LED wieder aus. Und dann wird getestet: ist die LED mehr oder weniger ständig an, erfolgt ein Dauerreset. Ist sie überhaupt nie an, läuft der Prozessor erst gar nicht los Ist sie nur einmal an und dann nie wieder, ist es irgendwas anderes.
Gast
#1783134
> Mein ursprüngliches Programm war für einen AtMega8 hab es dann quasi > genauso für den 162 übernommen . Wie genau ist 'quasi genauso'? Unverändert? Neu compiliert? Register angepasst (m8 und m162 sind nicht 'registerkompatibel')? HTH
Gast
#1783140
Interrupttabelle angepasst?</ingrid> Je nachdem wie es programmiert ist, sollte man auch die Konfigurationsregister und deren Bits vom Mega8 mit denen vom Mega162 vergleichen. Wenn sich Bits in ihrer Lage verschoben haben, dann kann man das schon so programmieren, das es zu einem Reset kommt. Nämlich dann wenn man mittels Binärschreibweise plötzlich einen ganz anderen Interrupt freigibt als ursprünglich beabsichtigt.
Gast
#1783148
Ja Interrupt war das Stichwort .Ich hatte einen Timer interrupt drin
.Wieso der allerdings nicht richtig ist weiß ich auch gerade nicht .
//======================================================================
void initTimer0()
{
TCCR0 = 0b00000001; // 0b00000001, Vorteiler 1
TIMSK = 0b00000001; // 0b00000001, Timer-Overflow
}
//======================================================================
//======================================================================
SIGNAL(SIG_OVERFLOW0) // Zeitsignal ( 1 Sekunde )
{
i = i+1;
if (i == 31250)
{
i = 0;
Timer = Timer+1;
if (Timer >= 200)
{
Timer = 0;
}
Zeit_berechnen();
Timer = Timer+1;
}
}
//======================================================================
Chris schrieb: > Ja Interrupt war das Stichwort .Ich hatte einen Timer interrupt drin > .Wieso der allerdings nicht richtig ist weiß ich auch gerade nicht . Dann lerne. > TIMSK = 0b00000001; // 0b00000001, Timer-Overflow Das, schreibst du niemals wieder so. Sondern immer so TIMSK = ( 1 << TOIE0 ); Denn: Während das Bit für den Timer Overflow beim Mega8 in der Tat das Bit 0 ist, ist es beim Mega162 an der Bitposition 1, wie uns ein Blick ins m162-Datenblatt, Seite 102, verrät! Du hast nicht den Overflow Interrupt eingeschaltet, sondern den Output Compare Interrupt für den Timer 0 (OCIE0). Und da du keinen Handler dafür hast, kommt der Default zum Zug, der .... den Prozessor resettet. Schreibst du as Einschalten des Interrupts so wie du das geschrieben hast, musst du dich darum kümmern, dass das TOIE0 Bit beim m162 an einer anderen Stelle sitzt, als beim m8. Schreibst du es auf die bessere Art mit Bitnamen, dann kümmert sich der Compiler darum. Und im Zweifelsfall ist es immer besser, wenn sich der Compiler um etwas kümmert. Denn der übersieht nichts und macht auch (zumindest in der Beziehung) keinen Fehler. Du musst nur den Prozessor umstellen und für den neuen Prozessor neu compilieren und schon wird auch das richtige Bit gesetzt.
Gast
#1783240
..ich sag ja, nicht 'registerkompatibel' :-) Für amoklaufende Interrupts gibts übrigens extra einen BADISR_vect. Zumindest während der Entwicklung kann es extrem praktisch sein wenn die Kiste nicht immer einen Reset macht (den man mglw. nicht mal richtig mitbekommt) sondern gleich anzeigt^H^H^H^H^Hblinkt 'unbehandelter Interrupt' :-) Geht aber übrigens auch noch schlimmer(tm) was die Bits angeht: Man kann diese nämlich zum Zwecke der Erschwerung des Protierens auch noch auf andere Register umverteilen, als besonderes Leckerli auch gleich noch auf mehrere verschiedene. Das kann dann auch der Compiler nicht mehr automatisch 'abfangen'. Beispielsweise liegt die Bits SM0..2 beim m8 im MCUCR, beim m162 dagegen sind die 3 Bits auf 3 Register verteilt: EMCUCR (SM0), MCUCR (SM1) und MCUCSR (SM2). Da kommt Freude auf beim µC-Wechsel ;-) Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
