Wie macht ihr ein Menü Timeout? Möglichkeiten?

Wolfsente schrieb:
> Ich hätte nun vor eine Statemaschine für das Menü zu machen das alle
> 100mS ausgeführt wird.

Das ist zu einstrassig gedacht. Du brauchst eine Timeoutfunktion, also 
einen Timer, der z.B. alle 10 ms einen Time-Interrupt auslöst. In der 
Interruptroutine zählst du einen Zähler hoch, und vielleicht noch 
hundert andere Dinge, die zeitabhängig ablaufen sollen, da fällt einem 
immer noch was ein.

Die Main Loop mit dem Menü kann ganz unabhängig davon ablaufen und 
braucht sich auch um die Zeit nicht zu kümmern. Sie schaut bloss in 
jedem Umlauf mal nach, ob der Zähler > x ist, wenn ja springt die 
Statemachine zurück ins Hauptmenü. Und bei jedem Tastendruck wird der 
Zähler auf Null gesetzt.

So ist die main Loop von der Laufzeit unabhängig, auch bei Änderungen 
und Erweiterungen, und While-Schleifen braucht man weder da noch in der 
Interruptroutine (da sind sie verboten).

Georg

Den Ansatz find ich gut!
Der passt auch gut auf mein Projekt.
Danke!

Wolfsente schrieb:
> Daher wollt ich mir von euch ein paar Ideen holen die sowas
> schon öfter gemacht haben.

Kommt drauf an, ob du diese Ideen auch wirklich hören willst.

Also:
Ich baue mir in den meisten Fällen (mal ganz kleine µC ausgenommen) zu 
allererst eine Systemuhr in die Firmware, die mit 1 oder 10 ms 
Intervallen läuft und eben die Zeit in einer 32 Bit Variable hochzählt.

Als nächstes arbeite ich mit Events, also ereignisgesteuert.

So, nun hab ich es so eingerichtet, daß die Systemuhr etwas kann, das 
ich salopp "verzögerte Events" nenne: Die Systemuhr hat eine kleine 
Liste, wo man mit einer ihrer Methoden (etwa so: AddDelayedEvent(aEvent, 
aDelay);) ein Ereignis hineinschreiben kann. Mit jedem Uhr-Tick gucht 
die Systemuhr in diese Liste und wenn sie dort ein Ereignis findet, 
dessen Zeit abgelaufen ist, dann holt sie sieses Ereignis aus der Liste 
und schmeißt es in die Liste der grad anstehenden Ereignisse. Von dort 
holt die Grundschleife in main das Ereignis heraus und bringt es zur 
Abarbeitung.

Länglicher Text, hoffentlich trotzdem verständlich. Willst du einen 
Timeout haben, dann sagst du das der Systemuhr und programmierst deine 
Menübedienung ereignisgesteuert und eben nicht blockierend.

W.S.

Dein erster Ansatz ist schon sehr, sehr gut. Wenn Du genügend Rechenzeit 
hast, die 100ms immer einzuhalten.

Falls nein, dann den "System-Ticker" einführen. Eine ISR im 1ms oder 
10ms-Takt, die den SysTicker hochzählt. Soweit ist Konsens in den 
Antworten.

Ab da gibt es mehrere Fallstricke und Ideologien

a) Beim Vergleichen von aktueller Zeit und Endzeit immer erst die 
Differenz bilden: if((SysTicker-Startzeit)>300) ...
Niemals: if(SysTicker>Startzeit+300) ...
--> Am Ende funktionieren es trotzdem nicht. Wenn es eben geht, würde 
ich bei einem ms-Ticker alle 20 Tage einen Geräte-Reset erzwingen. Die 
allermeisten "und nach Drei Wochen (6Wochen/42Tage) gehen auf einmal 
...."-Fehler gehen auf durchgegangene Überläufe 32-Bit-ms.

b) Events vs. brotlose Timer
Ich kann immer nur brotlose Timer empfehlen, die ein Satz (optionaler) 
Informationen kapseln und zur Laufzeit der Statemaschine abgefragt 
werden:
- Endzeit (oder Startzeit
- Reload-Zeit
- ein paar Flags (ob gestartet, ob retriggerbar, ggf. eine Funktion, 
...)

Brotlos genannt werden die Timer, da sie kein Brot fressen (keine 
Laufzeit kosten), wenn sie 3 Tage nicht aufgerufen werden. Auch brauche 
sie abgesehen vom Sys-Ticker keine zentralen Resourcen, können auch 
static in einem Unter-Unter-Unterblock existieren oder gar auf dem 
Stack.






a) ein oder mehrer Ticker:
Ich nutze immer nur einen SysTicker und vergleiche Manche zählen mehrere 
Timer in der ISR rauf (oder runter).
Bei einem einzigen SysTicker errechnet man ei:

[c]
   /* Timer setzen */
   int

Achim S. schrieb:
> würde
> ich bei einem ms-Ticker alle 20 Tage einen Geräte-Reset erzwingen

Wo du recht hast: Überlauf ist ein Problem. Dafür gibt es nach meinem 
obigen Konzept 2 Lösungen:

1. Man zählt nicht weiter, wenn der Timer die gewünschte Zahl (Zeit) 
erreicht hat. Ist fehleranfällig, wenn man die Zeit ändern will, die 
Verwendung von definierten Konstanten ist obligatorisch.

2. Bei jedem Tastendruck wird der Timer auf die gewünschte Zahl gesetzt 
und man zählt abwärts bis 0, das ist der Wert bei dem ins Hauptmenü 
zurückgesprungen wird. Man muss aber auch hier dafür sorgen, dass bei 0 
nicht weiter dekrementiert wird.

Achtung: ich habe KEINEN Systemtick vorgeschlagen, sondern eine 
Zählvariable extra und ausschliesslich für diesen Zweck. In der 
Timerroutine kann man durchaus einige solche Zähler bearbeiten, falls 
man anderweitig noch Timeouts braucht. Damit entfällt auch jede 
Timetick-Arithmetik. Ich brauche nie mehr als 5 solche Timeoutvariablen.

Georg

Peter D. schrieb:
> Wenn man das Konzept der Differenzbildung einmal verstanden hat

ich habe das (wie Du lesen kannst) verstanden und beschrieben.

Trotzdem wirst Du bei größeren Projekten immer ein paar faule Stellen 
haben. Entweder weil mehrere Leute daran arbeiten (nicht nur Du und ich) 
oder weil es nicht so offensichtlich ist.

Die meisten Fehler sind so selten, dass sie trotzdem nicht 
reproduzierbar auftreten. Schlimm ist es, wenn nach einiger Zeit Türen 
nicht mehr zu gehen oder dergleichen.

Und die wenigsten Geräte müssen durchlaufen. Reset heisst ja nicht, dass 
man Uhrzeit oder Parameter verliert. Oftmals gibt es mehrere Phasen pro 
Tag, an denen ein kurzer Reset problemlos möglich wäre. Ab Tag 10 nutzt 
man dann halt eine davon.

Marc V. schrieb:
>  da wird einfach eine Variable dekrementiert.
>  Wenn ich einen Timeout brauche, dann wird die Variable auf diesen
>  Wert gesetzt, ein Flag auch und in der ISR wird geprüft, ob der
>  Flag gesetzt ist, falls ja, wird die Variable um 1 dekrementiert.
>  Wenn Variable==0, wird der Überlaufflag für entspr. Timeout gesetzt
>  und das wars dann.

Der Weg ist zwar Überlauf-sauber, hat aber folgende Nachteile:
- feste Rechenzeiten je Tick und Timer notwendig (was andere Probleme 
nach sich zieht)
- Eingriff in die ISR (relativ tiefer Eingriff in untere Schichten)
- asynchrone Schreibzugriffe (also Locks erforderlich)

Je nach Aufgabe, Menge der Zeitüberwachungen und SW-Architektur ist 
dieser Ansatz problematisch (und wäre es bei uns, aus jedem der 3 
Gründe).

Zur Info: Beim free running SysTicker-Ansatz muss nur das einmalige 
Lesen atomar erfolgen. Dies ist bei den meisten µC für bis zu 
32Bit-Variablen problemlos möglich ohne weitere Lock-Mechanismen..

Das meinte ich mit (offensichtlich zu Recht) mit
> Ab da gibt es mehrere Fallstricke und Ideologien

Achim S. schrieb:
> Entweder weil mehrere Leute daran arbeiten

Willst du damit sagen, daß der TO, der seine erste Menuesteuerung 
realisieren will, eine multiple Persönlichkeit ist?

MfG Klaus

Moin Leute,

vielen Dank für die Anregungen!

Also von allen Antworten picke ich mir mal raus, wie ich das nun 
umsetzen würde:

In der Timer ISR (10mS) wird ein Counter immer um 1 dekrementiert und 
wenn (counter < 1) ist, wird nicht mehr dekrementiert.
In meiner Statemaschine (bei den Konfigurationssachen) prüf ich ob 
(counter < 1), wenn das zutrifft spring ich in den State "Hauptmenü".
Der Counter wird immer auf 3000 gesetzt, wenn eine Taste gedrückt wird.
Würde hier also kein Flag für dieses Timeout verwenden.
Ich würde bei den counter int16_t verwenden, falls irgendwo doch nochmal 
eine 0 dekrementiert wird. (Sollte aber nicht passieren (aber vorsicht 
lieber als nachsicht :D))

Die Timer ISR würde ich dann noch für mehrere Counter Sachen verwenden.
Brauche z.B. noch ein Event für alle 3,5 Sekunden. Dafür würde ich aber 
dann doch ein Flag setzen :D

Und ich würde die Statemaschine nicht alle 10mS durchlaufen lassen, 
sondern ständig in der Mainloop .

Ich hoffe das wäre so gut umgesetzt und habe es richtig verstanden.

Das mit den addieren/subtrahieren der Systemticker ist MIR zu 
gefährlich wegen den genannten Überlauf Problem was ihr ja diskutiert 
(habt).


Hat jemand noch Tipp zur Display Aktualisierung?
Soll ich in der Statemaschine immer ein Flag setzen das eine Display 
Aktualisierung fällig ist und wenn es aktualisiert worden ist das Flag 
rücksetzen? Oder geht das auch eleganter?

Btw.:
Klaus schrieb:
> Willst du damit sagen, daß der TO, der seine erste Menuesteuerung
> realisieren will, eine multiple Persönlichkeit ist?

Noch bin ich übrigens nicht schizophren :D

Achim S. schrieb:
> - asynchrone Schreibzugriffe (also Locks erforderlich)

Dass hält genauerem Nachdenken nicht stand. Z.B. kann die ISR ja nicht 
vom Hauptprogramm unterbrochen werden, also ist da Read-Modify-Write 
safe.

Und im Hauptprogramm gibt es kein Read-Modify-Write, sondern nur Lesen 
oder nur Schreiben, und das sind bei 8 oder 16 bit Variablen fast immer 
atomare Zugriffe, da kann auch nichts passieren. Notfalls könnte man ja 
Enable/Disable Interrupt verwenden, aber auch das ist nur in seltenen 
Sonderfällen notwendig. Aber toll wenn man den Chef mit Buzz-Wörtern wie 
"notwendige Locks" beeindrucken kann.

Dass feste Rechenzeiten notwendig wären ist sowieso nur totaler 
Blödsinn.

Aber von deinem Standpunkt hast du schon recht, wenn du die Software so 
kompliziert machst, dass sie ausser dir keiner versteht, sicherst du 
deinen Arbeitsplatz - zumindest wenn dein Chef keine Ahnung von der 
Sache hat. Ich arbeite seit Jahrzehnten bei Timeouts mit weniger als 10% 
deiner Software, bei absolut zuverlässiger Funktion, aber ich habe ja 
auch keinen Chef.

Georg

Georg schrieb:
> Dass hält genauerem Nachdenken nicht stand. Z.B. kann die ISR ja nicht
> vom Hauptprogramm unterbrochen werden, also ist da Read-Modify-Write
> safe.

Du wirst bei der Implementierung in ISR entweder den neuen Timerwert 
und/oder das Kontrollflag in der Main-Routine UND im ISR setzen. Bsp: 
Timerwert in Main auf 300 setzen, in jeder ISR dekrementieren. Es gibt 
dabei zuweilen atomare Möglichkeiten, aber nicht immer und nicht immer 
denkt jeder daran.

> Dass feste Rechenzeiten notwendig wären ist sowieso nur totaler
> Blödsinn.
Wenn Du 100 Zeitüberwachungen hast (Steuerungstechnik, parallele 
Module/Prozesse), dann müssen diese alle und in jedem ISR-Durchlauf 
geprüft und ggf. decrementiert werden. Bei zwei oder 5 spielt es *keine 
Rolle* (!).

> Ich arbeite seit Jahrzehnten bei Timeouts mit weniger als 10%
> deiner Software, bei absolut zuverlässiger Funktion, aber ich habe ja
> auch keinen Chef.

Bei größeren Projekten sind brotlose Timer eleganter und effizienter. 
Habe ich auch nicht geglaubt, bis ich entsprechende Software gesehen 
habe. Der Aufwand in Code insgesamt ist vergleichbar (falls Du das 
meintest). Aber brotlose Timer bleiben im Modul gekapselt, die ISR weiss 
davon nichts und muss es auch nicht.

Aber wie gesagt, bei 5 Timern ist jede Diskussion überflüssig. Dein 
Ansatz hat kein Überlaufproblem und ist damit robust!

Marc V. schrieb:
> Wolfsente schrieb:
>> Hat jemand noch Tipp zur Display Aktualisierung?
>> Soll ich in der Statemaschine immer ein Flag setzen das eine Display
>> Aktualisierung fällig ist und wenn es aktualisiert worden ist das Flag
>> rücksetzen? Oder geht das auch eleganter?
>
>  Nein, das ist so weder elegant noch clever.
>
>  Es setzt voraus, dass du deinen kompleten Displayinhalt im RAM
>  aufbewahrst.
>  Das mag bei einem 2x16 LCD noch nicht so schlimm sein, aber bei 8x40
>  oder gar 16x40 macht das schon keinen Sinn mehr - ausser viel mehr
>  benötigtem RAM wird die Geschwindigkeit auch zu einem Problem.
>
>  Und ob du einen Flag für DisplayRefresh setzst oder gleich die
>  Routine zum Refreshen aufrufst ist vom Standpunkt der zeitlichen
>  Ausführung absolut egal
>  Ob du aber nur 4 Digits für einen Wert neu schreiben musst oder gleich
>  320 oder 640 Zeichen weil dein ganzes Display neu gezeichnet werden
>  muss - das kann niemals egal sein.
>

Also einfach gleich den neuen Wert nur an der entsprechenden Stelle 
aktualisieren?


>  Ja, kommt mir irgendwie bekannt vor...
>   Kommt mir auch sehr bekannt vor...
>  Ja kommt mir auch sehr bekannt vor...
>
Vllt liegts daran das auch vieles von dir kommt. Lag vllt daran das mir 
das am besten gefallen hat und sauber klang.
Kommt so rüber als denkst du ich hätte mir das aus den Fingern gesogen, 
aber wollte doch nur mitteilen wie ich das nur vorhabe...

>> Der Counter wird immer auf 3000 gesetzt, wenn eine Taste gedrückt wird.
>> Würde hier also kein Flag für dieses Timeout verwenden.
>
>  Und damit hast du schon alle Vorteile die mein Vorschlag bietet aus
>  dem Fenster geworfen...
>
Siehe:
Wolfsente schrieb:
> Ich hoffe das wäre so gut umgesetzt und habe es richtig verstanden.

Dann hab ich ja doch nicht alles so richtig verstanden :D

Was habe ich denn für ein Vorteil das ich ein Flag in der Main prüfe 
anstatt den Counter selbst? Hat doch jeder sein eigenen Counter.

Wenn ich das richtig verstanden habe setzt du denn Counter ja auch bei 
jedem Tastendruck.

Würde die Abfrage in der ISR so machen:
if(!(counter<0))
{
 counter--;
}
Wofür die Flags?
Btw. die counter würden verständliche Namen kriegen.

Darfst dich gerne selber Zitieren wenn du das genau beschrieben hast 
warum das besser ist. Ich finde es nicht :(

>> Und ich würde die Statemaschine nicht alle 10mS durchlaufen lassen,
>> sondern ständig in der Mainloop .
>
>  Die Statemachine wird sowieso in einer while schleife durchlaufen...
Hatte aber vor mit einem Flag sie nur alle 10mS auszuführen. Was ich 
nicht mehr machen werde.


>  P.S.
>  Nur aus Neugierde:
>  Was hast du denn aus anderen Antworten genau übernommen ?
Ich habe nicht auf die Namen der Antworten geachtet.
Wenn das meiste von dir kommt ist doch schön, das ich am meisten auf 
dich gehört habe! :D
Aber anscheinend nicht alle Vorteile entdeckt habe.

Marc V. schrieb:
> Achim S. schrieb:
>> meintest). Aber brotlose Timer bleiben im Modul gekapselt, die ISR weiss
>> davon nichts und muss es auch nicht.
>
>  Auch diese Timer befinden sich in der ISR, werden nur durch entsprechend
>  gesetzte Flags gestartet, angehalten, aktualisiert oder abgefragt, die
>  ISR weiss also sehr wohl davon

Du verwechselst da etwas. Ich war einer derjenigen mit ausschließlich 
einem SysTicker++ in der ISR.
Und der mit mehreren Timern da größere (Industrie-)Software. Kein 
Arduino in einem Nachtlicht oder so.

Achim S. schrieb:
> - feste Rechenzeiten je Tick und Timer notwendig (was andere Probleme
> nach sich zieht)

Achim S. schrieb:
> Wenn Du 100 Zeitüberwachungen hast

Mal abgesehen davon, dass das in der Praxis ziemlich selten vorkommt, 
redest du an deiner eigenen Forderung vorbei. Es ist klar, dass in einer 
ISR alles so schnell wie möglich abgearbeitet werden muss, das ist 
Anfängerwissen. Du hast aber feste Rechenzeiten verlangt, dafür gibt es 
nicht den geringsten Grund, weder in der ISR noch im Hauptprogramm.

Georg

Marc V. schrieb:
> Wolfsente schrieb:
>> Kommt so rüber als denkst du ich hätte mir das aus den Fingern gesogen,
>> aber wollte doch nur mitteilen wie ich das nur vorhabe...
>
>  LOL.
>  Nein, Georg hat auch so etwas ähnliches vorgeschlagen, deswegen.

Sehr gut, dann hatte ich mich doch nicht ungünstig formuliert :D

Marc V. schrieb:
>> Würde die Abfrage in der ISR so machen:
>> if(!(counter<0))
>> {
>>  counter--;
>> }
>
>  Wirklich ?

Sorry meinte counter<1
Ohne Flags zu setzen wäre das doch in Ordnung gewesen.

Marc V. schrieb:
>> Wofür die Flags?
>
>  a) Weil es übersichtlicher ist.
Wo ich jetzt über den Punkt richtig nachgedacht habe (mit deinem Punkt 
c) zusammen) finde ich, hast du da recht.

Fand aber vorher aber nämlich..

(menueTimeOut<1)
übersichtlicher als
(CHK_BIT(MyFlag, tstOn))

>  b) Weil es sicherer und schneller ist einen Byte zu prüfen als z.B.
>  einen 32bit Zähler.

Mh... ok... Da die ISR ja nur alle 10mS aufgerufen wird um zu 
vergleichen, macht das Sinn.

>  c) Wenn sich alle Flags (bits) in einer Variable befinden, dann sagt
>  dir ein einfacher Test auf Null ob du überhaupt etwas laufen hast ;-)
>
Nagut hast mich ja überzeugt :D

Vielen Dank für deine Erklärungen!
Ich werde versuchen diesen "Stil" dann zu übernehmen.

Marc V. schrieb:

> Achim S. schrieb:
>> Und die wenigsten Geräte müssen durchlaufen. Reset heisst
>> ja nicht, dass man Uhrzeit oder Parameter verliert.
>
>  Reset heisst, dass der Anfangszustand unbekannt ist.

Das heisst es wohl beim Mikrocontroller. Bei der SPS - die
je offenbar nach (hier) herrschender Meinung hoffnungslos
veraltet und dem Mikrocontroller hoffnungslos unterlegen
ist - heisst es das nicht.

> Das schliesst alle Parameter die sich im RAM befinden,
> ein.

Mal was von gestuetztem RAM gehoert?

>  Sich darauf zu verlassen, dass irgendwelche Parameter
> beim Reset nicht verlorengegangen sind, wäre ein bisschen
> leichtsinnig, oder ?

Wieso sollte man sich denn NICHT darauf verlassen, dass
remanente Merker nach dem RESET noch da sind? Deswegen
heissen sie ja "remanent".

Marc V. schrieb:

> Achim S. schrieb:
>>> Dass feste Rechenzeiten notwendig wären ist sowieso nur
>>> totaler Blödsinn.
>> Wenn Du 100 Zeitüberwachungen hast (Steuerungstechnik,
>> parallele Module/Prozesse), dann müssen diese alle und
>> in jedem ISR-Durchlauf
>
> Wenn du 100 Zeitüberwachungen hast, stimmt meistens etwas
> nicht.

Hier kann man exemplarisch studieren, was passiert, wenn
"total veraltete und unmoderne" SPS-Leute mit "modernen,
leistungsfaehigen, zukunftstraechtigen" µC-Leuten aneinander
vorbei reden.

In einer auch nur mittelgroszen Maschinensteuerung kommen
leicht dutzende bis hunderte "Zeitueberwachungen" vor.
Und eine SPS hat damit keine nennenswerten Probleme; das
schafft die in Echtzeit (=Laufzeitgarantie).

Die "Zeitueberwachungen" heissen im SPS-Slang uebrigens
"Timer" :)

> Und wenn man das alles auch noch in einer einzigen ISR
> abarbeiten will - von welcher Steuerungstechnik redest
> du, wem willst du so etwas andrehen ?

Das wiederum ist richtig. Eine klassische SPS macht fast
nichts im Interrupt - schon gar nicht das Pruefen der
Timeouts. Das wird in der Hauptschleife gemacht.

Marc V. schrieb:

> Possetitjel schrieb:
>>>  Reset heisst, dass der Anfangszustand unbekannt ist.
>>
>> Das heisst es wohl beim Mikrocontroller. Bei der SPS - die
>> je offenbar nach (hier) herrschender Meinung hoffnungslos
>> veraltet und dem Mikrocontroller hoffnungslos unterlegen
>> ist - heisst es das nicht.
>
>   Hier ist aber nicht von PLC die Rede.

Gewoehne Dir diesen Kasernenhof-Ton ab.
Du bestimmst nicht, wovon hier die Rede ist.

>> Wieso sollte man sich denn NICHT darauf verlassen, dass
>> remanente Merker nach dem RESET noch da sind? Deswegen
>> heissen sie ja "remanent".
>
>  Ich habe 5 Mal diese Seite mit Suchfunktion nach "SPS",
>  "PLC", "remanent" und "Marker" durchsucht.
>  Ausser in deinem Beitrag ist auf dieser Seite nichts davon
>  zu finden.
>
>  Was wolltest du eigentlich sagen ?

Das war ein Test. Ich habe Deine Faehigkeit zu mentalen
Transfer-Leistungen getestet.

Leider bist Du durchgefallen.

Denn Du hast weder erkannt, dass Achim offensichtlich einen
SPS-Hintergrund hat (was sich auch in seiner Wortwahl
niederschlaegt), noch, dass ich Dich subtil auf diese Tatsache
hinweisen wollte.

Marc V. schrieb:
> Ich habe 5 Mal diese Seite mit Suchfunktion nach "SPS", "PLC",
>  "remanent" und "Marker" durchsucht.
>  Ausser in deinem Beitrag ist auf dieser Seite nichts davon zu finden.
>
>  Was wolltest du eigentlich sagen ?

Er wollte sagen, dass die Methoden jeder SPS auch ihre Entsprechung und 
µC-Programmen haben und dort genauso gewinnbringend genutzt werden 
können, wenn es um echte Steuerungen und nichttriviale Aufgaben geht.

a) remanent = non volatile RAM (das beim erstmaligen Start eines 
Programmes genullt wird, aber nicht bei jedem Reset. Ja, auch das geht 
in C, **kopfschüttel**)

b) PLC: loop control, auch in µC-SW eine erfolgreiche Alternative zu 
vielen Task-Konstrukten. In autosar "basic Task" genannt.

btw.: wer sich an "festen Rechenzeiten" störte: Hier ist der (konstante) 
Aufwand für jeden einzelnen Timer-Decrement (oder Flag-Abfrage) in der 
ISR gemeint. Dieser Aufwand ist bei 5 Timern (wie schon häufig gesagt) 
vernachlässigbar. Schön ist die Vermischung von Modulen und ISR trotzdem 
nicht.

Georg schrieb:

> Achim S. schrieb:
>> - asynchrone Schreibzugriffe (also Locks erforderlich)
>
> Dass hält genauerem Nachdenken nicht stand. Z.B. kann die
> ISR ja nicht vom Hauptprogramm unterbrochen werden, also
> ist da Read-Modify-Write safe.

In meinem Universum gibt es sowohl unterschiedliche
Interruptprioritaeten als auch nichtmaskierbare Interrupts.
In Deinem auch?

> Notfalls könnte man ja Enable/Disable Interrupt verwenden,
> aber auch das ist nur in seltenen Sonderfällen notwendig.

Das waere dann genau der "notwendige Lock", von dem Achim
geredet hat.

> Aber toll wenn man den Chef mit Buzz-Wörtern wie
> "notwendige Locks" beeindrucken kann.

Geht's auch etwas weniger abschaetzig? Besonders dann, wenn
Du (ungewollt) genau das bestaetigst, was Achim vor Dir
geschrieben hat?

> Dass feste Rechenzeiten notwendig wären ist sowieso nur
> totaler Blödsinn.

Vielleicht TUST Du in Zukunft wenigstens mal so, als ob Du
VERSUCHEN wuerdest zu verstehen, was Dein Gegenueber gemeint
hat!?

Achim hat KRITISIERT, dass bei Deinem Vorschlag (je ein
Countdown-Zaehler pro Timeout) fuer jeden laufenden Countdown
Rechenzeit in der ISR verbraten wird.

Das ist bei der von ihm vorgeschlagenen Zeitstempel-Methode
nicht der Fall.

> Aber von deinem Standpunkt hast du schon recht, wenn du die
> Software so kompliziert machst, dass sie ausser dir keiner
> versteht, [...]

Einfach mal die Baelle flachhalten.

Es hat schon jeder gemerkt, dass Du Achim nicht verstehst; das
musst Du nicht noch besonders betonen.
Aber was Du nicht verstehst, muss deswegen noch lange nicht
falsch sein.