Counter in ISR unwirksam?

https://de.wikipedia.org/wiki/Volatile_(Informatik)

Alfred schrieb:
> @ MaWin :
> "nicht atomisch"?

Der Interrupt kann (theoretisch) zwischen der Hauptschleifen-Abfrage des 
Flags und dem Hauptschleifen-Rücksetzen des Flags ausgeführt werden. 
Damit würde ein Setzen des Flags im Interrupt verloren gehen.
Allerdings wird das bei dir hier in diesem speziellen Fall aufgrund des 
langsamen Timings nicht passieren.

Alfred schrieb:
> Nein, die LED ist immer an! Sowohl wenn ich Bit0 vor while(1) oder auch
> innerhalb while(1) schreibe... wie kann das sein?

Ich würde einmal sagen du hast ein elektrisches Problem, oder dein 
Controller muss noch besonders konfiguriert werden zur Verwendung dieses 
Pins.

Tausche doch einmal Bit 0 und 6 in Hauptschleife und Interrupt.

Ach und:
Ist BIT0 und BIT6 überhaupt eine Bitmaske? Oder ist es eine Bitnummer?

Wenn es eine Bitnummer ist, dann musst du so schreiben:

xxx ^= 1 << BIT0
xxx ^= 1 << BIT6

MaWin O. schrieb:
> Ach und:
> Ist BIT0 und BIT6 überhaupt eine Bitmaske?

Ja, denn das ist ein MSP430.

> Oder ist es eine Bitnummer?

Nö.

Alfred schrieb:
> Nein, die LED ist immer an! Sowohl wenn ich Bit0 vor while(1) oder auch
> innerhalb while(1) schreibe... wie kann das sein?
>
> Grüße,

Hat die LED jemals gblinkt? Ist die wirklich richtig angeschlossen? Dein 
Code sieht OK aus, auch volatile ist drin, passt.
Lass mal die LED ohne ISR blinken, einfach mit old school delay.

Alfred schrieb:
> nochmal danke für Deine schnelle Reaktion!
>
> Ich konnte das Problem lösen, indem ich das LPM0_bits nicht mehr
> schreibe (Zeile 22), jetzt geht alles wie gewünscht, hat was mit dem
> LowPower-Mode zu tun - muss ich nachher mal genauer nachlesen... (habs
> nur durch ausprobieren rausbekommen).

Das ist eine Besonderheit beim MSP430. Der kann in einem der LPMs 
arbeiten, eine ISR ausführen und bei deren Verlassen den automatisch 
wieder einschalten, sodaß die Hauptschleife NIE ausgeführt wird! Will 
man das nicht, muss man in der ISR die LPM-Bits ausschalten. Frag mich 
jetzt aber nicht wie das genau geht, hab ich vor 15 Jahren das letzte 
Mal gemacht 8-0

>> Der Interrupt kann (theoretisch) zwischen der Hauptschleifen-Abfrage des
>> Flags und dem Hauptschleifen-Rücksetzen des Flags ausgeführt werden.

Auch praktisch.

>> Damit würde ein Setzen des Flags im Interrupt verloren gehen.

Nö. Denn das Löschen erfolgt NUR bei vorher erkanntem Flag!

>> Allerdings wird das bei dir hier in diesem speziellen Fall aufgrund des
>> langsamen Timings nicht passieren.

> Das ist ein interessanter Aspekt!

Nö, es ist ein Irrtum.

> Hättest Du spontan ein Beispiel für
> mich, wie diesen Effekt umgehen kann? (Ich möchte ja ein längeres
> Programm schreiben, als nur eine LED blinken zu lassen ;-))

Man kann das Löschen das Flags am Ende der Abarbeitung von Funktionen 
nutzen, ob das Timing schnell genug ist.

https://www.mikrocontroller.net/articles/Multitasking#Verbesserter_Ansatz_mit_Timer

Falk B. schrieb:
> Nö. Denn das Löschen erfolgt NUR bei vorher erkanntem Flag!
>
>>> Allerdings wird das bei dir hier in diesem speziellen Fall aufgrund des
>>> langsamen Timings nicht passieren.
>
>> Das ist ein interessanter Aspekt!
>
> Nö, es ist ein Irrtum.

Ach komm Falk.
Rede keinen Unsinn.
Es könnte ein Flagsetzen verloren gehen. Das wird in diesem Konkreten 
Fall nur verhindert, weil das Setzen eine sehr langsame Periode hat und 
in dieser Zeit die Hauptschleife den kritischen Bereich sicher verlassen 
wird.

Alfred schrieb:
> Hättest Du spontan ein Beispiel für
> mich, wie diesen Effekt umgehen kann?

Deaktivieren der Interrupts vor Abfrage und Re-aktivierung der 
Interrupts nach Abfrage + Rücksetzen des Flags.

MaWin O. schrieb:
>> Nö, es ist ein Irrtum.
>
> Ach komm Falk.
> Rede keinen Unsinn.

Eben. Das tue ich nicht ;-)

> Es könnte ein Flagsetzen verloren gehen.

Ach sooo, jetzt verstehe ich. Ja, könnte. Ist aber wie bei JEDEM 
Interrupt! Wenn die Beantwortung zu lange dauert, werden diese 
verschluckt.

> Das wird in diesem Konkreten
> Fall nur verhindert, weil das Setzen eine sehr langsame Periode hat und
> in dieser Zeit die Hauptschleife den kritischen Bereich sicher verlassen
> wird.

Stimmt.

> Deaktivieren der Interrupts vor Abfrage und Re-aktivierung der
> Interrupts nach Abfrage + Rücksetzen des Flags.

Das löst das Problem nicht wirklich. Denn auch hier kann eine zu lange 
Bearbeitungszeit dazu führen, daß eben die Periodendauer des Timers 
überschritten wird. Und dann verhindert man mit der ISR-Sperre die 
Ausführung der ISR. OK, EINMAL funktioniert der Trick, aber wenn die 
Zeit NOCH länger wird, schon nicht mehr.

Alles in allem MUSS man durch Simulation oder Messung sicher stellen, 
daß die Funktionen zwischen Erkennen des ISR-Flags und dem Löschen 
SICHER kleiner als die Timerperiode ist. Man kann das Flag auch gleich 
nach dem Erkennen löschen. Aber auch dann muss die Bearbeitung von 
wasauchimmer() so kurz sein, daß die nächste Abfrage des Flag das erneut 
gesetzte Flag erkennt und nicht mehrere Timerdurchläufe überspringt! 
Steht alles seit Ewigkeiten im Artikel Interrupt.

https://www.mikrocontroller.net/articles/Interrupt#Zusammenfassung

Falk B. schrieb:
> Denn auch hier kann eine zu lange
> Bearbeitungszeit dazu führen

Völlig richtig. Ich wollte hier lediglich in einem Nebensatz auf ein 
Problem hinweisen und nicht das Problem vollumfänglich lösen. (Man 
könnte zum Beispiel zählen statt Flag setzen).