H
Hans-Peter Diettrich
Guest
Am 24.09.2019 um 10:43 schrieb Volker Bartheld:
Ein Bekannter hat dafür noch eine Lösung aus BASIC Zeiten: verwendet
wird ein Ringpuffer, in dem immer nur unterschiedliche Einträge gelesen
und geschrieben werden. Das geht auch mit einem Wechselpuffer, wenn der
Consumer via Flag den gerade beschriebenen Puffer auf read-only
schaltet, und der Producer in den anderen - jetzt write-only - Puffer
schreibt.
Es muß ja nur derjenige Interrupt blockiert werden, der (s)einen Teil
der Daten ändert. Das kann nicht zum Verlust von Interrupts führen, denn
was könnte ein Interrupt-Handler in der Zeit erledigen, die der
Hauptthread für das Kopieren von ein paar Bytes in Register braucht?
Es kann doch keinen großen Unterschied ausmachen, ob jetzt ein Interrupt
von einer Kopieraktion oder einem anderen Interrupt vorübergehend
blockiert wird? So viel Zeit muß in einem ausreichend schnellen
Echtzeitsystem übrig sein.
DoDi
On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:
Am 23.09.2019 um 13:52 schrieb Volker Bartheld:
On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
weiterzuarbeiten?
Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
(oder was auch immer der native Datentyp ist) wegschreiben müssen.
... und anscheinend über keine Interrupt-Abschaltung verfügen?
Du schaltest also den Interrupt ab. Und serialisierst eine etwas größere
Datenstruktur.
Ein Bekannter hat dafür noch eine Lösung aus BASIC Zeiten: verwendet
wird ein Ringpuffer, in dem immer nur unterschiedliche Einträge gelesen
und geschrieben werden. Das geht auch mit einem Wechselpuffer, wenn der
Consumer via Flag den gerade beschriebenen Puffer auf read-only
schaltet, und der Producer in den anderen - jetzt write-only - Puffer
schreibt.
Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
zeitgerecht reagieren.
Es muß ja nur derjenige Interrupt blockiert werden, der (s)einen Teil
der Daten ändert. Das kann nicht zum Verlust von Interrupts führen, denn
was könnte ein Interrupt-Handler in der Zeit erledigen, die der
Hauptthread für das Kopieren von ein paar Bytes in Register braucht?
Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
sonst abbildet.
Es kann doch keinen großen Unterschied ausmachen, ob jetzt ein Interrupt
von einer Kopieraktion oder einem anderen Interrupt vorübergehend
blockiert wird? So viel Zeit muß in einem ausreichend schnellen
Echtzeitsystem übrig sein.
DoDi