Semaphoren Lock für Variablenzugriff

[Ritchie]

Hallo Zusammen,

mein Programm greift via Interrupt auf interne Variable des Atmel atMega32 zu. Hierbei handelt es sich um die Datentypen, byte, word, long und float.

Problemlos ist eigentlich nur die Bytevariable, da diese im Schreibzugriff nicht unterbrochen werden kann.

Gibt es eine einfach Methode einen sicheren Zugriff auf Variablen innerhalb einer Interrupt-Routine sicherzustellen.

Generell habe ich alle Variablen, welche in der Interruptroutine abfrage, als "volatile" deklariert.

Nur was passiert, wenn das Hauptprogramm gerade das erste Byte Long einer Variable geschrieben hat,
und dann ein Interrupt eintritt.

Unter Linux kann ich hierbei auf Semaphoren zugreifen, gibt es sowas auf für atmega32 ?

Gruss R.

[markusj]

Du musst bei Zugriffen, die atomar erfolgen sollen, Interrupts kurz ausschalten. Die avr-libc bringt bereits in util/atomic.h entsprechendes Werkzeug mit.

Codebeispiel:

#include <util/atomic.h>

ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
    // Tu was atomar
}

mfG
Markus

PS: Du kannst natürlich auch einfach selbst vor dem zu schützenden Bereich mit cli() Interrupts deaktivieren und danach mit sei() wieder Anschalten.
PPS: Beide Varianten müssen im Normalfall nur im Hauptprogramm eingesetzt werden, ISRs sind ohne eigenes Zutun nicht unterbrechbar und benötigen damit einen solchen Schutz nicht.

[Klebwax]

PS: Du kannst natürlich auch einfach selbst vor dem zu schützenden Bereich mit cli() Interrupts deaktivieren und danach mit sei() wieder Anschalten.

Besser ist es, sich den Interruptstatus zu merken, dann ihn zu deaktivieren und am Ende den alten Zustand wiederherzustellen. Das kann dann gefahrlos auch verwendet werden, wenn mal aus anderen Gründen der Interrupt gesperrt ist.

Ich kenne jetzt die avr-libc nicht, aber der Name "ATOMIC_RESTORESTATE" klingt, alsob es da so gemacht wird.

MfG Klebwax

[Ritchie]

Hi,
hat jemand schon mal eine Funktion geschrieben, welche einen Variablenwert "Atomic" ändert ?

Hier würde ich dann auch das ab/an Schalten des Interrupts einfügen. Wild cli() / sei() setzen ist nicht mein Ding.

[markusj]

Besser ist es, sich den Interruptstatus zu merken, dann ihn zu deaktivieren und am Ende den alten Zustand wiederherzustellen. Das kann dann gefahrlos auch verwendet werden, wenn mal aus anderen Gründen der Interrupt gesperrt ist.

Das erfordert mehr Aufwand, den man in manchen Situationen nicht bereit ist zu leisten.

Ich kenne jetzt die avr-libc nicht, aber der Name "ATOMIC_RESTORESTATE" klingt, alsob es da so gemacht wird.

Genau so ist es.

@Ritchie: Warum? Dafür braucht es keine Funktion.

// tu was und berechne foo
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
  bar = foo; // atomare Zuweisung
}

[Klebwax]

Das erfordert mehr Aufwand, den man in manchen Situationen nicht bereit ist zu leisten.

Naja, so aus der Erinnerung : Das Register mit dem Globalen Enable mit PUSH auf den Stack, disable Interrupt, .... POP Register ( drei Zeilen statt zwei) und schon hat man Stunden beim Debuggen gespart.

MfG Klebwax

[Ritchie]

Hi,
das sieht ja doch ganz gut aus.

Ich habe jetzt nur evtl. ein Problem mit meiner Impulsmessung der Encoder. Dieser werden auch per Interrupt eingelesen. Schalte ich hier die Interrupts entsprechend ab, laufe ich Gefahr, das ich Impuls verliere (was ich noch testen müsste).

Wozu ich die ganze Sache benötige?
Ich habe einen Hauptrechner, welcher Parameter an die Motorsteuerung sendet. Dies sind z.b. aktuelle Position in der Karte, Zielposition, Ausrichtung, Geschwindigkeit, etc...

Gleichzeitig werden Werte aus der Motorsteuerung zurück an den Hauptrechner gemeldet, wie aktuelle Position, aktuelle Ausrichtung, Status, etc...

Positionen sind im Integer Format (2Byte) und Winkel in float (4byte) abgelegt.

Wenn die Motorsteuerung einen Wert aktualisiert, kann es sein, das gleichzeitig, das Hauptprogramm den gleichen Wert abfragt.
Ich habe zeitweise -30491 als Wert im Logfile, statt 2277, obwohl ich diese Abfrage im Standby mache (also Stillstand!).

Ich dachte bin jetzt immer, das hier ein Übertragungsfehler vorliegt, dieser wird aber nicht vom Hauptprogramm gemeldet.
Der falsche Wert muss also auch im Kontroller so vorhanden sein.
Wenn dies zu einem falschen Zeitpunkt passiert (Übernahme von Parameter), kommt das garnicht gut.

Gruss R.