Reset nach Input-Abfrage bei PCF8574AP

[Jacob2]

Okay, ich habe das Problem jetzt soweit eingrenzen können, dass der µC anscheinend nach der Interrupt-Funktion ISR(PCINT2_vect) ein Reset macht... Die I2C-Kommunikation scheint zu funktionieren, ich kann mir sogar den empfangenen Port-Status vom PCF8574 auf dem LCD anzeigen lassen, nur, danach ist immer ein Reset  !

Aber warum macht "er" dann ein Reset? In main() befindet sich der Controller in einer while(1); Schleife, in der er ja auch nach dem Interrupt noch sein müsste, richtig?

Ich habe auch schon versuchsweise cli() und sei() auskommentiert, an denen liegt's wohl aber auch nicht...

[Richard]

Ist es möglich das es zu einem Stack Überlauf kommt und Dein Programm im "Nirwana" endet?

Gruß Richard

[Jacob2]

@Richard Ich weiß nicht, wodurch könnte es denn zu einem Stack Überlauf kommen?
Sind z.B. cli() und sei() überhaupt sinnvoll im ISR? Kann das Tastenprellen vielleicht einen Überlauf verursachen?
Der µC hängt sich nicht auf, er startet definitiv neu, denn am Anfang von main() lasse ich eine Meldung ausgeben: lcd_puts("Starten..."); und die wird nach dem Interrupt angezeigt.
@oberallgeier Ich verstehe nicht ganz, was Du meinst - ich habe ja nur eine ISR... D.h. ich weiß, dass diese ISR bzw., das was danach geschieht, den Reset auslöst. Das Problem ist, dass ich nicht genau weiß, was nach der ISR passiert - bisher war ich davon ausgegangen, dass in die while(1)-Schleife zurückgesprungen wird...

[oberallgeier]

... verstehe nicht ganz, was Du meinst - ich habe ja nur eine ISR ...

Ok, bevor wir die Geheimnisse der Interrupt-Vektortabelle diskutieren: Wie wärs, wenn Du SICHERSTELLST, dass nach dem lcd_puts("Vorher...") ein Reset im m48 erfolgt? Versuch doch mal zwischen lcd_clrscr(); und dem lcd_puts("Vorher...") ein Delay-1000 einzufügen - dann wäre nach einem Reset immer wieder für eine Sekunde ein gelöschtes LCD zu sehen. DANN sind wir sicher, dass ein Reset stattfindet und nicht "nur" ein Hängenbleiben des Controllers . . . . Dann könnte man weitersehen.

[Richard]

@Richard Ich weiß nicht, wodurch könnte es denn zu einem Stack Überlauf kommen?

Mit C habe ich leider Probleme und kann Deinen Code nicht wirklich nachvollziehen.   Aber solche "Neustarts" sind typisch wenn z.B. eine Rücksprung Adresse fehlt oder überschrieben wurde. Zum Testen mal den Sack Bereich vergrößern könnte helfen. Auch wenn das Programm selber "ins leere" Endet oder eine Variable zu "klein" ist( buffer overlow), (kann) das zum Neustart führen.

Gruß Richard

[Searcher]

Hallo,
ich verstehe C auch kaum, aber ein anderer Gedanke:

Der PCF8574 zieht INT nach LOW, wenn ein Taster gedrückt wird.
Das verursacht ein PCINT am ATMega und der springt in die ISR und der PCF wird ausgelesen.
Nach Datenblatt des PCF8574 wird dessen INT Leitung resettet, wenn Daten von seinem Datenport gelesen werden.
Das bedeutet, das am PCINT Pin der Pegel wechselt und ein neuer PCINT ansteht.
Sobald aus der ISR zurückgekehrt wird muß µC da sofort wieder rein.

Das Ganze ist davon abhängig, ob der µC das PCI Flag zu Beginn der ISR oder bei Rücksprung löscht. Das weis ich leider nicht.

SEI und CLI in der ISR macht für mich keinen Sinn, da die sowieso während der ISR geblockt sind. Statt dessen eher Verhindern von PCINTs (im Maskenregister) und vor Rücksprung sicherheitshalber Löschen des PCI Flags und Wiederzulassen von PCINTs.

Entprellung von Tasten?

Gruß
Searcher

[oberallgeier]

... danach ist immer ein Reset ! Aber warum macht "er" dann ein Reset? ...

Bei Problemen mit undefiniertem Reset hatte ich mir mal eine extrem kurze LED-Signalroutine geschrieben, die von einer ISR angestossen wurde - z.B. drei mal kurz Blinken. Die Signalroutine wird von der ISR angestossen - sie wird nicht in der ISR ausgeführt. Dann hatte ich diese ISR Vektor für Vektor den verschiedenen Interruptvektoren zugewiesen. Irgendwann bekam ich den Auslöser identifiziert . . . .