mikrocontroller mit mehr als einem Quadrature-Decoder Timer

[Sieghard Schicktanz]

Hallo Thorsten,

Du schriebst am Fri, 20 Sep 2019 07:25:33 +0200:

funktioniert Quadraturdekodierung nur, wenn man die Signale mit einem
festen Takt abtastet - dann stĂśrt auch prellen nicht wirklich - da
wackelt dann der

Naja, es geht auch einfacher, ohne den Prozessor ständig zu unterbrechen.

Sicher geht das bei einem "richtigen" Encoder so, da prellt auch nichts.
Es geht halt so nicht "so gut", wenn man das mit so einem Fingerdrehknopf
machen soll, der einfach ein paar mechanische Kontaktfederlen mit einer
Plastikscheibe auf- und zudrĂźckt. Also solche Dinger, wie sie inzwischen in
fast jedem neueren Meßgerät (Oszilloskop, z.B.) zum Einstellen der
Meßparameter sitzen.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Johannes Bauer]

On 21.09.19 20:52, Sieghard Schicktanz wrote:

Wieso heißt eine Funktion zum _De_kodieren eines Signal(paare)s bei diesen
Dingern eigentlich _En_coder? Hat da jemand was verwechselt?

"Rotary Decoder" ist vermutlich als Suchbegriff ungeeignet; jemand, der
nach der Funktionalität sucht, sucht wohl am ehesten nach Timer + Rotary
Encoder support.

Gruß,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Hans-Peter Diettrich]

Am 21.09.2019 um 20:57 schrieb Sieghard Schicktanz:

Es geht halt so nicht "so gut", wenn man das mit so einem Fingerdrehknopf
machen soll, der einfach ein paar mechanische Kontaktfederlen mit einer
Plastikscheibe auf- und zudrĂźckt.

Dann muß man eben von Hand entprellen, da sind Interrupts nur hinderlich.

Wie lange prellen denn die Kontakte?

DoDi

 

[Rainer Knaepper]

DrDiettrich1@aol.com (Hans-Peter Diettrich) am 22.09.19 um 04:08:

Am 21.09.2019 um 20:57 schrieb Sieghard Schicktanz:

Es geht halt so nicht "so gut", wenn man das mit so einem
Fingerdrehknopf machen soll, der einfach ein paar mechanische
Kontaktfederlen mit einer Plastikscheibe auf- und zudrückt.

Dann muß man eben von Hand entprellen, da sind Interrupts nur
hinderlich.

Ich imitiere das so, wie man das von einfachen SPS kennt: Zyklisch
abfragen und letzten und aktuellen Zustand vergleichen. Bei händisch
betätigten Drehgebern kein Problem. Bei "schnellen" Gebern ist das
latürnich problematisch, aber die sind ja eher nicht mechanisch und
prellen nicht.

Wobei ich vor Jahren mal eine Maus hatte, bei der das Mausrad
tatsächlich einen mechnischen Geber hatte. Mit zunehmendem Alter und
Verschleiß verhielt die sich schon sehr knuffig. Da hat der
Mausprogrammierer wohl auch beim Entprellen geschlampt ;-)

Rainer

--
Die Boulevardmedien haben genug damit zu tun, Fremdenhass
zu schüren und danach scheinheilig Nazis und anderes Gesocks
als Asylgegner zu verharmlosen. (Jörg Tewes in ct.ger)

 

[Marte Schwarz]

Hi Andreas,

Bei dem Youtube-Beispiel ging es wohl um den Knackpunkt, dass sie nur
einen Draht zur Verfßgung haben. Mit zwei Drähten hätten es
wahrscheinlich alle geschafft.

Nicht wirklich. ein 1,5V Block an eine NetzspannungsglĂźhbirne wird trotz
allem nix, selbst wenn es eine amerikanische GlĂźhbirne ist.

Marte

 

[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. Aber es
geht doch auch gar nicht darum, jetzt einen Fall zu konstruieren, der
trivial mit diesem oder jenem Ansatz lösbar ist. Es geht darum, zu
veranschaulichen, daß Multithreading und sonstige Nebenläufigkeiten
prinzipiell zu den schwierigeren Programmieraufgaben gehören. Denn sonst
wäre das nicht in einem von mir einigermaßen willkürlich gewählten Beispiel
danebengegangen und seit Jahren (wenn nicht Jahrzehnten) ohne Fix
geblieben.

Wer unter euch ohne Sünde ist, der werfe den ersten Stein!

Volker

 

[Gerhard Hoffmann]

Am 23.09.19 um 13:52 schrieb Volker Bartheld:

Wer unter euch ohne SĂźnde ist, der werfe den ersten Stein!

Comic in dem Berliner Stadtmagazin Zitty, so vor 30 Jahren:

RĂźdiger (Knollennase, doof): Kieselchen nehm - vorsichtig werf -

Publikum: Oh, die arme Sau! Nicht mal eine klitzekleine SĂźnde!..

 

[Johannes Bauer]

On 23.09.19 13:52, Volker Bartheld wrote:

Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
(oder was auch immer der native Datentyp ist) wegschreiben mĂźssen.

WĂźrde ich sogar noch einen Tick allgemeiner sehen: Auf Systemen, auf
denen Multiprozessor-Skalierbarkeit wichtig ist, gilt das ja nämlich
auch. Linux hat richtig hart gearbeitet, das BKL (Big Kernel Lock)
loszuwerden: https://de.wikipedia.org/wiki/Big_Kernel_Lock und es mit
Version 3.0 (oder 2.6.xx) dann endlich geschafft.

Gruß,
JOhannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[horst-d.winzler]

Am 23.09.19 um 13:52 schrieb Volker Bartheld:

Wer unter euch ohne SĂźnde ist, der werfe den ersten Stein!

Volker

Wer zuerst trifft, lebt länger.

--
---hdw---

 

[Hans-Peter Diettrich]

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? Die halte
ich aber für essentiell für so kleine Systeme wie hier genannt, die
einfach nur Encoder abfragen sollen. Wenn jemand für diese Aufgabe ein
OS und weiteren Pipapo benötigt, dann kann er das gerne in einem neuen
Thread diskutieren, unter "Mit Kanonen auf Spatzen schießen".

Aber es
geht doch auch gar nicht darum, jetzt einen Fall zu konstruieren, der
trivial mit diesem oder jenem Ansatz lösbar ist. Es geht darum, zu
veranschaulichen, daß Multithreading und sonstige Nebenläufigkeiten
prinzipiell zu den schwierigeren Programmieraufgaben gehören.

Unbestritten, aber solche Systeme betrachte ich nicht als
Mikrocontroller. Wenn ein Prozessor Multithreading etc. erlaubt, und
gleichzeitig Anspruch auf Echtzeitfähigkeit erhebt, dann hat der
gefälligst auch Befehle für atomare Zugriffe zu implementieren, sonst
ist das alles nur Marketinggeschwätz.

Ich weiß nicht ob es Intel war, die ein LOCK Prefix eingeführt haben.
Für die Tasksynchronisation etc. gibt es noch CMPXCHG und ähnlich
komfortable Befehle für Semaphore etc. Und wenn es die schon auf
ordinären Controllern gibt, die keinen Anspruch auf Echtzeitfähigkeit
erhebenn dann sieht man, wie weit dieses Thema vom Topic und der
hiesigen NG weg ist.

DoDi

 

[Michael Koch]

Irgendwie geht das mit jedem Controller (im
schnellen Timerinterrupt die zwei Pins einlesen und dekodieren), besonders
glĂźcklich bin ich dabei aber meist nicht - denn das ist zu langsam (der
Encoder verliert dann doch mal Impulse, weil man zu schnell dreht) und
belastet die CPU mit recht vielen und häufigen Interrupts, bzw. man darf dann
im Hauptprogramm tunlichst nie Interrupts sperren, damit der Encoder
fehlerfrei funktioniert.

Es gibt einen Trick wie du per Software ungefähr die doppelte Geschwindigkeit einlesen kannst. Das geht so: Im schnellen Timerinterrupt werden die A und B Signale eingelesen und in ein Byte geschoben. Dieses Byte enthält also nicht nur die aktuellen Signale, sondern auch die A und B Signale zu den vergangenen drei Zeitpunkten. Dieses Byte wird nun als Eingangssignal fßr eine Look-up-Table genutzt, und die Tabelle liefert eine Zahl im Bereich -2...+2, die angibt um wieviel sich der Drehwinkel geändert hat. In die Erstellung dieser Tabelle musst du ein Bisschen Gehirnschmalz reinstecken und kannst dabei die Tatsache nutzen, dass sich die Drehgeschwindigkeit nicht schlagartig ändert. Fehlende Zwischenschritte kÜnnen mit dieser Methode kompensiert werden.

Gruß
Michael

 

[Volker Bartheld]

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. Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
zeitgerecht reagieren. Also zerhackst Du die Datenstruktur und führst
einen Mutex, eine Critical Section oder sonst einen
Synchronisierungsansatz ein. Das blockt dann aber die Threads, die
möglicherweise auf den Ablageort der Datenstruktur zugreifen müssen. Ergo
erfindest Du Schattenkopien, ein Dirty-Bit, grübelst über Write-Through
und Write-Back, usw. Ich will damit sagen: Multithreading ist schwierig.

Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

Die halte ich aber für essentiell für so kleine Systeme wie hier genannt,
die einfach nur Encoder abfragen sollen. Wenn jemand für diese Aufgabe
ein OS und weiteren Pipapo benötigt, dann kann er das gerne in einem
neuen Thread diskutieren, unter "Mit Kanonen auf Spatzen schießen".

Das Usenet ist aber leider kein Wunschkonzert. Für den Task
"Quadrature-Encoder abfragen" würde ich - verzeih - {Quadrature, Encoder,
Arduino} in der Suchmaschine meines geringsten Mißtrauens eingeben und mir
anschauen, wie das - vermutlich - schon 1001x gelöst wurde. Als da wären:

https://github.com/PaulStoffregen/Encoder
http://www.hessmer.org/blog/2011/01/30/quadrature-encoder-too-fast-for-arduino-with-solution/
https://www.rs-online.com/designspark/quadrature-encoder-basics-part-1-theory
https://playground.arduino.cc/Main/RotaryEncoders/
https://howtomechatronics.com/tutorials/arduino/rotary-encoder-works-use-arduino/
https://cdn.sparkfun.com/datasheets/Robotics/How%20to%20use%20a%20quadrature%20encoder.pdf

Anstatt mir über potentiell geniale Eigenkreationen das Hirn zu zermartern.
Weil ich nicht am Not-Invented-Here-Syndrom leide.

Unbestritten, aber solche Systeme betrachte ich nicht als
Mikrocontroller. Wenn ein Prozessor Multithreading etc. erlaubt, und
gleichzeitig Anspruch auf Echtzeitfähigkeit erhebt, dann hat der
gefälligst auch Befehle für atomare Zugriffe zu implementieren, sonst
ist das alles nur Marketinggeschwätz.

Je nun. Ich baute mal einen Klon des Photoduino:
https://photoduino.com/documentation/hardware/photoduino-shield-3-0/
, fand heraus, daß das Display (präzise: die Hintergrundbeleuchtung) den
meisten Strom frißt. Was unpraktisch bei Langzeit-Zeitrafferaufnahmen an
der frischen Luft war. Ergo der naheliegendste Plan, einen Interrupt dafür
zu verwenden, die Hintergrundbeleuchtung nach einer gewissen Zeit
abzuschalten und bei Tastendruck oder sonstigen nennenswerten Ereignissen
wieder an.

Irgendwann ist mir aufgefallen, daß in einem anderen Anwendungsfall -
nämlich der Hochgeschwindigkeitsfotografie - ein gewisser Jitter vorhanden
ist, der das Timing zwischen Triggerevent und Auslösung des Blitzes
versaut. Der ADC vielleicht? Irgendwas in der Auslöselogik? Die
Verschlußsteuerung der Kamera selbst? Fragen über Fragen. Schließlich war
es von allem ein bißchen und natürlich auch der
Hintergrundbeleuchtungsinterrupt, wo eigentlich nur andere Interrupte
deaktiviert und ein simples Bit an den PWM-Ausgang des Arduino geschrieben
wurde.

Blöd gelaufen.

Volker

 

[Johannes Bauer]

On 24.09.19 10:43, Volker Bartheld wrote:

Ich will damit sagen: Multithreading ist schwierig.

Aber vermutlich Ăźberkopfe ich das auch nur und es gibt eine ganz einfache
LĂśsung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

Nicht verkopft, sondern den Nagel voll und ganz auf den Kopf getroffen.

Der unschlagbare Vorteil vom Sperren von Interrupts ist, dass es die
aller, allereinfachste Synchronisationsprimitive ist, die man verwenden
kann. Funktioniert absolut sicher. Die Nachteile sind aber eben genauso
gravierend und erfordern dann (wie in deinen Beispielen geschildert)
eventuell entsprechende Gegenmaßnahmen, die dann die Komplexität extrem
aufblasen kĂśnnen.

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Hanno Foest]

On 24.09.19 10:43, Volker Bartheld wrote:

Du schaltest also den Interrupt ab. Und serialisierst eine etwas größere
Datenstruktur. Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
zeitgerecht reagieren.

Kommt auf die Anforderungen an. "Echtzeit" heißt ja nur, daß man eine
garantierte Antwortzeit hat, aber nicht, welche das ist. Wenn der
kurzzeitig abgeschaltete Interrupt innerhalb einer klar definierten (und
nicht zu großen) Zeit wieder da ist, und hardwaretechnisch gewährleistet
ist, daß keine Interrupts verloren gehen, kann das schon mit geringem
Aufwand zielfĂźhrend sein.

Mit verschiedenen und Ăźberlappenden Interrupts wird es dann wieder
schwierig. Allerdings in jedem Fall.

Hanno

 

[Hans-Peter Diettrich]

Am 24.09.2019 um 10:43 schrieb Volker Bartheld:

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.

Ja.

> Und serialisierst eine etwas größere Datenstruktur.

Nein. Interrupts ändern immer nur kleine Dateneinheiten, alles andere
wäre Murks. Deine Einwände deuten offensichtlich in diese Richtung...

DoDi

 

[Gerhard Hoffmann]

Am 24.09.19 um 10:43 schrieb Volker Bartheld:

On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:

Aber vermutlich Ăźberkopfe ich das auch nur und es gibt eine ganz einfache
LĂśsung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

Die Welt braucht mehr CPUs. Jede nur fĂźr einen Ăźberschaubaren Zweck.

Im BeagleBoneBlack hat das fĂźr mich sehr schĂśn funktioniert.
Ein GHz-ARM fĂźr Linux und 2 PRUs fĂźr die Drecksarbeit. Die PRUs sind
andere RISCs ohne Pipeline, die man stallen kĂśnnte. DafĂźr nur 200 MHz,
aber man kann im 5 ns-Raster Flanken erzeugen. Alles geht taktgenau.
Jede PRU hat 32-Bit-Register mit denen man fast direttissima auf
einige Pins und Devices zugreifen kann. Interrupts gibt's nicht
wirklich fĂźr die PRUs, aber dual port buffers zum ARM.

Mit einem popeligen Coolrunner2-IF kann ich 3 LTC2500-32 ADCs mit
jeweils 100 MHz-SPI auslesen, ohne dass was verloren geht.

Irgendwann ist mir aufgefallen, daß in einem anderen Anwendungsfall -
nämlich der Hochgeschwindigkeitsfotografie - ein gewisser Jitter vorhanden
ist, der das Timing zwischen Triggerevent und AuslĂśsung des Blitzes
versaut. Der ADC vielleicht? Irgendwas in der AuslĂśselogik? Die
Verschlußsteuerung der Kamera selbst? Fragen über Fragen. Schließlich war
es von allem ein bißchen und natürlich auch der
Hintergrundbeleuchtungsinterrupt, wo eigentlich nur andere Interrupte
deaktiviert und ein simples Bit an den PWM-Ausgang des Arduino geschrieben
wurde.

BlĂśd gelaufen.

Passiert auch den Besten.
Tektronix hatte mal ein ultraschnelles sampling scope, wo der
Aperturjitter im Takte einer nicht sehr wichtigen Warn-LED
um ein paar ps herumgetanzt ist.

Gruß, Gerhard

 

[Matthias Weingart]

Michael Koch <astroelectronic@t-online.de>:

Irgendwie geht das mit jedem Controller (im
schnellen Timerinterrupt die zwei Pins einlesen und dekodieren),
besonder
s
glĂźcklich bin ich dabei aber meist nicht - denn das ist zu langsam (
der
Encoder verliert dann doch mal Impulse, weil man zu schnell dreht) und
belastet die CPU mit recht vielen und häufigen Interrupts, bzw. man
darf dann
im Hauptprogramm tunlichst nie Interrupts sperren, damit der Encoder
fehlerfrei funktioniert.

Es gibt einen Trick wie du per Software ungefähr die doppelte
Geschwindigkeit einlesen kannst. Das geht so: Im schnellen
Timerinterrupt werden die A und B Signale eingelesen und in ein Byte
geschoben. Dieses Byte enthält also nicht nur die aktuellen Signale,
sondern auch die A und B Signale zu den vergangenen drei Zeitpunkten.
Dieses Byte wird nun als Eingangssignal fĂźr eine Look-up-Table genutzt,
und die Tabelle liefert eine Zahl im Bereich -2...+2, die angibt um
wieviel sich der Drehwinkel geändert hat. In die Erstellung dieser
Tabelle musst du ein Bisschen Gehirnschmalz reinstecken und kannst dabei
die Tatsache nutzen, dass sich die Drehgeschwindigkeit nicht schlagartig
ändert. Fehlende Zwischenschritte kÜnnen mit dieser Methode
kompensiert werden.

Jo danke, genau so mache ich es schon.

M.
--

 

[Rainer Knaepper]

news2019@bartheld.net (Volker Bartheld) am 24.09.19 um 10:43:

Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
einfache Lösung, wie man die Echtzeitanforderung bei abgeschalteten
Interrupts sonst abbildet.

Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
"zwischen jedem einzelnen Professortakt reaktionsfähig", sondern nur
"stets mit vorhersagbarer maximaler Reaktionszeit".

Wenn eine Uralt-SPS einen eine ms langen oder gar noch langsameren
Zyklus schafft, diesen aber /garantiert/, dann ist das halt "Echtzeit"
mit einer ms Auflösung.

Wer mit einem 8-bit-AVR nun unbedingt 48-bittig rechnen will, der kann
halt keine "Echtzeit" zwischen jedem Registerzugriff bei einer
Plutimikation garantieren, sondern eben nur alle 384 (Hausnummer!)
Prozessortakte. Wenn der Zwerg halt fertig ist mit der
Bitumherschieberei. Gerät der Kleine ins Stottern, muß man was
dickeres nehmen und/oder schlauer programmieren.

Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
wundert, daß es da immer noch Verständnisprobleme gibt.

Rainer

--
Muss man denn wirklich, um den Geschmack von Milch zu kritisieren,
selber Kuh sein? (Tom! Striewisch in de.rec.fotografie)

 

[Hans-Peter Diettrich]

Am 24.09.2019 um 19:01 schrieb Rainer Knaepper:

news2019@bartheld.net (Volker Bartheld) am 24.09.19 um 10:43:

Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
einfache Lösung, wie man die Echtzeitanforderung bei abgeschalteten
Interrupts sonst abbildet.

Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
"zwischen jedem einzelnen Professortakt reaktionsfähig", sondern nur
"stets mit vorhersagbarer maximaler Reaktionszeit".

Letzteres gefällt mir noch nicht so richtig, denn man kann jedes System
mit zu vielen häufigen Interrupts überlasten. Tatsächlich kann nur
vorgegeben werden, wie lange die Bearbeitung eines Interrupts maximal
dauern darf. Für länger dauernde Operationen muß die Priorität des
Handlers heruntergesetzt werden, oder noch besser die lange Verarbeitung
in eine normale Task ausgelagert werden, damit der Handler keine
Probleme mit Reentrancy bekommt.

Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
wundert, daß es da immer noch Verständnisprobleme gibt.

Immer wieder gern ;-)

DoDi

 

[Rainer Knaepper]

DrDiettrich1@aol.com (Hans-Peter Diettrich) am 24.09.19:

Am 24.09.2019 um 19:01 schrieb Rainer Knaepper:
news2019@bartheld.net (Volker Bartheld) am 24.09.19 um 10:43:

Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
einfache Lösung, wie man die Echtzeitanforderung bei
abgeschalteten Interrupts sonst abbildet.

Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
"zwischen jedem einzelnen Professortakt reaktionsfähig", sondern
nur "stets mit vorhersagbarer maximaler Reaktionszeit".

Letzteres gefällt mir noch nicht so richtig, denn man kann jedes
System mit zu vielen häufigen Interrupts überlasten. Tatsächlich
kann nur vorgegeben werden, wie lange die Bearbeitung eines
Interrupts maximal dauern darf. Für länger dauernde Operationen muß
die Priorität des Handlers heruntergesetzt werden, oder noch besser
die lange Verarbeitung in eine normale Task ausgelagert werden,
damit der Handler keine Probleme mit Reentrancy bekommt.

Genau in so eine Falle bin ich ja mal in einem früheren Leben
hineingerannt. Das ganze System basierte auf einem Taktgeber aus einer
RTC und interruptete halt mit 64 Hz. Die komplette Ablaufsteuerung
steckte in der ISR.

Funktionierte auch gut, aber dann kam $Chefänderungswunsch1,
$Kundenerweiterungswunsch2 und "können wir nicht jene Funktion noch
hinzupacken" sowie "$GanzAnderesGerät können wir doch auch auf der
Basis steuern" - und schwupps reichten die 16ms nicht mehr zur
Abarbeitung.

Was dann einen großzügigen Umbau des gesamten Konzepts erforderte

Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
wundert, daß es da immer noch Verständnisprobleme gibt.

Immer wieder gern ;-)

Ich schaue halt aus Elektrikerperspektive auf die Thematik, nicht
informationstheoretisch.

Rainer

--
Man sollte überhaupt keine Tests mehr lesen...
(Stefan Krah in de.comp.hardware.kuehlung+laermdaemmung)