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.

[RoboHolIC]

Vielleicht kannst du die konkurrierenden nicht-atomaren Zugriffe auf die Mehrbyte-Variablen in Schattenvariablen puffern und den Austausch mit den "heissen" Variablen in einen kürzest-möglichen Programmabschnitt zusammenlegen. Die ISR setzt bei jedem Durchlauf ein Freigabeflag ("ISR was here"), auf das in der Hauptprogrammschleife gewartet wird. Man könnte dann sozusagen im zeitlichen Windschatten der ISR den Datenaustausch flink vollziehen, sobald die wieder einmal durch ist und für eine bestimmte minimale Zeitdauer garantiert nicht in die Quere kommen kann. Vor dem nächsten kritischen Zugriff wird das Flag vom Hauptprogramm gelöscht und wieder darauf gepollt, bis dieses "von Geisterhand" gesetzt wird ...
Erweiterungsmöglichkeit: Die ISR akzeptiert ihr eigenes "ISR was here"-Flag als Zugriffsverbot und überspringt ggf. den kritischen Abschnitt. Das entspräche in etwa einem acknowledge oder hand shake.

Gruß
Christian.

[Ritchie]

Hi,
generelle scheint mir Deine Idee ein gangbarer Weg zu sein, da nur hier die volle Kontrolle der Daten vorhanden ist. Schalte ich den Interrupt up, weiss ich nicht, welche Daten ich verliere, da auch die Messwertverarbeitung via Interrupt arbeitet.
Dies entspricht auch mehr der Vorgehensweise eines "Semaphore-Lock".
Gruss R.

[sternst]

Schalte ich den Interrupt up, weiss ich nicht, welche Daten ich verliere, da auch die Messwertverarbeitung via Interrupt arbeitet.

Wieso glaubst du überhaupt, irgendetwas zu verlieren, wenn du Interrupts kurz ausschaltest? Welcher Interrupt soll es denn sein, der da während einer Handvoll Takte gleich mehrmals kommen soll?