State Machine mit While-Schleifen.bitte um Kommentare

[Dieter (Gast)]

Hallo,

mir kam gerde folgende Idee zur Umsetzung einer State Machine:

int main(void)

int Status = STATUS_A;

{

while (Status = STATUS_A)
{

if (irgendwas)
{
eine_funktion();
}
else
{
Status = STATUS_B;
}

}

while (Status = STATUS_B)
{

if (irgendwas_anderes)
{
eine_andere_funktion();
}
else
{
Status =  STATUS_A
}

}

Die Idee dahinter ist, die übliche Hauptschleife in mehrere Schleifen zu 
unterteilen, die je nach Zustand des Systems unterschiedlich auf 
Eingaben reagieren. Z.B. könnte STATUS_A das Hochfahren einer Mascheine 
sein, und STATUS_B dann der laufende Betrieb. Und einmal muss man z.B. 
auf die Temperatur einer Heizung warten (A), später wird stattdessen 
eine Fehlermeldung ausgegeben(B).

Was meint ihr? Taugt das Konzept was?

Gruß,
Dieter

[Dr. Sommer (Gast)]

Wenn ständig die Schleifen laufen, hast du immer 100% CPU-Last und eine 
hohe Leistungsaufnahme. Außerdem muss da "==" in die Schleifenbedingung.

[Einer K. (Gast)]

Dr. Sommer schrieb:
> Wenn ständig die Schleifen laufen, hast du immer 100% CPU-Last und eine
> hohe Leistungsaufnahme.

Häää....

Die üblichen µC laufen immer mit 100% Last, mit voller 
Leistungsaufnahme.
(wenn sie nicht gerade schlafen)



> Was meint ihr? Taugt das Konzept was?
Wenn es deine konkreten Anforderungen erfüllt, dann gut.

Aber universell ist das nicht.
Denn normalerweise tummeln sich etliche StateMachines auf einem µC zu 
einer Zeit. Diese würden sich bei dir gegenseitig blockieren.

[Dieter (Gast)]

Arduino Fanboy D. schrieb:

Danke für deine Antwort,

> Aber universell ist das nicht.
> Denn normalerweise tummeln sich etliche StateMachines auf einem µC zu
> einer Zeit. Diese würden sich bei dir gegenseitig blockieren.

könntest du das ein bisschen näher ausführen?

Gruß,
Dieter

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dieter schrieb:
> Was meint ihr? Taugt das Konzept was?
Nein.
Die Hauptschleife wird immer komplett und möglichst schnell durchlaufen. 
Und dann abhängig von irgendwelchen Zuständen irgendwelcher Automaten 
(und "Unterautomaten") irgendwelche Aktionen ausgelöst, von denen aber 
keine den Ablauf irgendwie blockiert.

Dieter schrieb:
> Und einmal muss man z.B. auf die Temperatur einer Heizung warten (A),
> später wird stattdessen eine Fehlermeldung ausgegeben(B).

int Status = STATUS_A;

int main(void)
{
   while (1) {
      if (Status == STATUS_A) {
         machwas();
      }

      if (Status == STATUS_B) {
         machwasanderes();
      }

      if (Status == FEHLER) {
         maschine_anhalten();
         fehlerlampe_anschalten();
         wunden_lecken();
      }

      if (irgendwas) {
         if (machirgendwas() == OK)  Status = STATUS_B;
         else                        Status = FEHLER;
      }

      if (Sonst_ein_Fehler_aufgetreten()) {
         Status = FEHLER;
      }
      
      if (Zeichen_auf_serieller_Schnitte_empfangen()) {
         Zeichen_auslesen();
      }
    
      if (sonstwas()) {
         if (tu_sonstwas() == NOK) Status = FEHLER;
      }
      :
      :
   }
}

[Einer K. (Gast)]

Dieter schrieb:
> könntest du das ein bisschen näher ausführen?

Warum?

OK...

Frage: Was machen die anderen Schleifen, solange eine aktiv läuft?
Antwort: Gar nichts!

[Falk B. (falk)]

Dieter schrieb:

> mir kam gerde folgende Idee zur Umsetzung einer State Machine:

Nach einer Sauftour?

> Die Idee dahinter ist, die übliche Hauptschleife in mehrere Schleifen zu
> unterteilen, die je nach Zustand des Systems unterschiedlich auf
> Eingaben reagieren.

Das ist dir aber maximal mißlungen.

> Z.B. könnte STATUS_A das Hochfahren einer Mascheine
> sein, und STATUS_B dann der laufende Betrieb.

Das machen die klassischen Konzepte DEUTLICH besser und übersichtlicher.

> Und einmal muss man z.B.
> auf die Temperatur einer Heizung warten (A), später wird stattdessen
> eine Fehlermeldung ausgegeben(B).
>
> Was meint ihr? Taugt das Konzept was?

Nö.

Denn der Witz einer Statemachine, besonders in Software ist es ja 
gerade, daß sie nur wenige Aufgaben, die im aktuellen Zustand zu prüfen 
und erledigen sind, prüft und erledigt und dann schnell wieder den 
Programmfluß für andwere Dinge, meist andere State machines freigibt. 
Deine hat "lebenslänglich", wenn sich der aktuelle Zustand nicht ändert, 
alos das totale Gegenteil! Optimal, um eine CPU zu 100% mit Nichtstun 
auszulasten ;-) Außerdem ist deine Schreibweise auch nicht 
übersichtlicher.
Und warum sollte man die jeweiligen Funktionen mehrfach ausführen. Das 
ist im allgemeinen nicht so.

Dein Ziel

"Die Idee dahinter ist, die übliche Hauptschleife in mehrere Schleifen 
zu
unterteilen, die je nach Zustand des Systems unterschiedlich auf
Eingaben reagieren. "

Erreicht man mit mehreren, klassischen State machines deutlich besser.
Denn die können und dürfen miteinander kommunizieren. Sei es, daß die 
Zustände der State machines global sichtbar sind oder daß sie spezielle 
Kommunikationsvariablen nutzen.

[Theor (Gast)]

Wozu soll das Konzept denn taugen, wenn Du fragst, ob es etwas taugt?
In dem Zusammenhang stellt sich auch die Frage, warum Du es nicht ganz 
"normal" nach Lehrbuch machst.

[Philipp K. (philipp_k59)]

Da sieht doch eher wie ein switch case fall aus..

main(){
switch (status)
case:0
blabla 
status=machwas0();
case:1
blabla;
status++;
default: status=0;
}

int machwas0(){
if(blabla){
status++;
}
}

[W.S. (Gast)]

Dieter schrieb:
> Was meint ihr?

Ich meine, du solltest bsser mit Events arbeiten.

also

immerzu:
if (EventAvailable())
{ event = GetEvent();
  switch (event)
  { case dieser: Erledige_dieses...; break;
    case jener: Erledige_jenes....; break;
    ...
und so weiter.

Sinn der Übung ist es, eben auf alles reagieren zu können, was denn da 
so an behandlungsbedürftigen Ereignissen herein kommen mag. Aber dazu 
darf man nirgendwo blockierend programmieren.

Es ginge in main sogar noch kürzer und damit sogar projektunabhängiger:

immerzu:
  if (EventAvailable()) 
  DispatchEvent(GetEvent());
goto immerzu;

Das wäre wohl die kürzeste main für sowas.

W.S.

[I am the Wunderer (Gast)]

Man kann ja mal etwas ausprobieren. Die anderen "Lehrbuchmethoden" hat 
sich auch irgendwann mal Irgendjemand ausgedacht -die sind nicht von 
einem Berg herab verkündet worden.

Ich habe hier auch schon die lustigsten Einfälle mit einem 
Experimentier-Bord auf Atmega32-Basis ausprobiert, das immer ma Rechner 
hängt. Viele davon nutze ich weiter, nachdem ich sie anständig 
dokumentiert habe. Aber: NIE würde ich auf die Idee kommen, die hier zu 
diskutieren. Dafür sind mir hier zu viele Lautsprecher und 
Riesenschnauzer unterwegs.

[Dr. Sommer (Gast)]

Arduino Fanboy D. schrieb:
> Häää....
>
> Die üblichen µC laufen immer mit 100% Last, mit voller
> Leistungsaufnahme.
> (wenn sie nicht gerade schlafen)

Ganz genau; wenn man eine Nicht-Blockierende Statemachine hat, kann man 
zwischendurch den Prozessor in den Sleep-Modus versetzen und bei 
Ereignissen per Interrupt aufwecken.

[spess53 (Gast)]

Hi

>Dafür sind mir hier zu viele Lautsprecher und
>Riesenschnauzer unterwegs.

Ist halt nichts für Zwergpinscher.

MfG Spess

[Vancouver (Gast)]

@TO

Bei Deiner Statemachine kommst Du von Zustand A nach Zustand B, aber nie 
wieder zurück, weil die Main-Funktion dann zu Ende ist. Um das zu 
erreichen, musst du das Ganze in eine While(1)-Schleife verpacken und 
bist dann doch wieder bei einer Hauptschleife.

[Theor (Gast)]

I am the Wunderer schrieb:
> Man kann ja mal etwas ausprobieren. Die anderen "Lehrbuchmethoden" hat
> sich auch irgendwann mal Irgendjemand ausgedacht -die sind nicht von
> einem Berg herab verkündet worden.
> [...]

Sicher. Man hat auch mal eine "Eingebung".
Aber es ist sinnlos , eine Eingebung oder einen Einfall einfach so in 
den Raum zu stellen, ohne vorher selbst darüber nachzudenken, ob der 
überhaupt zu irgend etwas taugt.

In diesem Fall ist der Einfall in einer Hinsicht trivial (nämlich durch 
die Lehrbuchmethoden schon abgedeckt) und in anderer Hinsicht 
unzweckmässig, weil er unnötig die CPU beschäftigt. Und das ist nicht 
etwa nur durch eine verwickelte Kette von Schlussfolgerungen zu 
erschliessen, bei der man sich als Fortgeschrittener mal irren kann, 
sondern zu einem gewissen Grad offensichtlich.

Die Lehrbuchmethoden sind entweder zur Erreichung eines bestimmten 
Zweckes erdacht worden, oder - darüber kann man nur spekulieren -, man 
hat einen Einfall im nachhinein als zweckmässig erkannt.

Aus diesen Gründen ist es absurd, ein Forum dazu zu verwenden, Einfälle 
ungefiltert, unreflektiert beurteilen zu lassen. Falls das Mode wird, 
würde das Forum von allen möglichen halbgebildeten Einfällen überflutet 
werden, die gar keinen Sinn haben, die aber nur mit Grundlagenwissen zu 
beurteilen sind, das dem TO einfach nur fehlt.

Die Frage nach dem möglichen Vorteil dieser Methode ist also in 
zweierlei Hinsicht sinnvoll: 1. Weil er schlicht nicht angegeben worden 
ist und 2. weil er den TO möglicherweise dazu bringt, mal über seinen 
Einfall nachzudenken und sich evtl. fehlendes Wissen anzueignen.

[F. F. (foldi)]

Falk B. schrieb:
>> mir kam gerde folgende Idee zur Umsetzung einer State Machine:
>
> Nach einer Sauftour?

Hahaha!

[F. F. (foldi)]

spess53 schrieb:
> Hi
>
>>Dafür sind mir hier zu viele Lautsprecher und
>>Riesenschnauzer unterwegs.
>
> Ist halt nichts für Zwergpinscher.
>
> MfG Spess

Ich muss doch noch Popcorn machen. Bier darf ich nicht ... obwohl, ist 
das nicht sogar gut bei Grippe.

Die State Machine ist immer eines der best diskutierten Themen hier.
Wird nur von C++ geschlagen.

[F. F. (foldi)]

Lothar M. schrieb:
> Dieter schrieb:
>> Und einmal muss man z.B. auf die Temperatur einer Heizung warten (A),

Die State Machine warte niemals auf irgend etwas, sondern reagiert auf 
Bedingungen und Veränderungen.
Und (!) die schläft auch nicht. Jedenfalls nicht, wenn sie eine 
relevante State Machine ist.

Wie Lothar schon richtig schreibt, sie muss so schnell wie möglich die 
Hauptschleife durchlaufen.

[Dr. Sommer (Gast)]

F. F. schrieb:
> Die State Machine ist immer eines der best diskutierten Themen hier.
> Wird nur von C++ geschlagen.

Das können wir doch kombinieren - in C++ kann man State Machines mit dem 
State Pattern umsetzen!

[F. F. (foldi)]

Dr. Sommer schrieb:
> in C++ kann man State Machines mit dem
> State Pattern umsetzen!

Dann brauche ich aber auch noch Taschentücher. Da reicht einfaches 
wegwischen der Tränen nicht mehr. Ach ja, und Schlaftabletten, denn vor 
lauter Lachen komme ich dann auch nicht mehr in den Schlaf.

[Einer K. (Gast)]

F. F. schrieb:
> Schlaf

Ich behaupte:
Jedes funktionierende Programm auf einem µC, ist, oder implementiert, 
eine oder mehrere, Zustandsautomaten.
Damit dürfte ich ca. 99,9% aller Programme erwischt haben.


Und das hat nichts damit zu tun, ob der jeweilige Programmierer, 
beabsichtigt hat, es zu implementieren, oder gar schon jemals von dem 
Pattern gehört hat.

[F. F. (foldi)]

Arduino Fanboy D. schrieb:
> Ich behaupte:

Stimme ich dir voll zu.

In gewisser Weise ist die Betrachtung auch schon immer meine gewesen.
Die Diskussion ist hier immer zu Abstrakt, sie bezieht sich nur auf den 
Code.
Was soll denn die State Machine machen?
Sie soll reale Zustände überwachen und dann meist an Übergängen in einen 
anderen Zustand ein Reaktion auslösen. Selbst die Fehlermeldung ist 
solche. Wenn z.B. der Temperatursensor nach 1000 Abfragen nicht einmal 
seinen Wert geändert hat.

Aber noch mal, sie schläft nie! Natürlich kann der µC schlafen und auf 
einen Trigger warten, doch während sie läuft, muss sie das und möglichst 
ohne Unterbrechungen.

[Dieter (Gast)]

Einige Anmerkungen dazu:

- Ja, da muss nochmal die Hauptschleife drum herum. Mein Fehler.
- Es müssen in jedem Zustand zyklisch Messwerte erfasst und Ports 
ausgelesen werden. Daher die while-Schleifen und die mehrfachgen 
Funktionsaufrufe.

Vielleicht macht das den Hintergrund zur Idee etwas klarer.

Gruß,
Dieter.

[Einer K. (Gast)]

Dieter schrieb:
> Vielleicht macht das den Hintergrund zur Idee etwas klarer.
Mir nicht....

Nicht, dass ich grundsätzlich was gegen Schleifen habe....
Ganz im Gegenteil.

[Dieter (Gast)]

Dr. Sommer schrieb:
> Wenn ständig die Schleifen laufen, hast du immer 100% CPU-Last und eine
> hohe Leistungsaufnahme. Außerdem muss da "==" in die Schleifenbedingung.

Ok, wenn die Schleifen jetzt nicht immer laufen, wie frage ich dann 
Messwerte vom AD-Wandler ab, überwache Ports. Ich kann ja nicht allem 
einen Interrupt zuordnen, zumindesst nicht auf dem AVR.

[F. F. (foldi)]

W.S. schrieb:
> alsoimmerzu:
> if (EventAvailable())
> { event = GetEvent();
>   switch (event)
>   { case dieser: Erledige_dieses...; break;
>     case jener: Erledige_jenes....; break;
>     ...
> und so weiter.

Wobei sich die Dringlichkeit der Ausführung immer noch stellt. Beim ABS 
sollte das Rad sofort wieder frei gegeben werden, wenn es blockiert.
Bei deiner Heizung? Wenn die Temperatur deiner Heizung um 0,3 Grad 
fällt, musst du dann in der State Machine nachregeln, oder kannst du das 
dann vielleicht nicht besser außerhalb machen?

[Einer K. (Gast)]

Dieter schrieb:
> Ok, wenn die Schleifen jetzt nicht immer laufen,

Nee...
Eine Endlosschleife, ist schon ok.
Und von mir aus auch, bei einem Multitaskingsystem, für jeder Task eine 
eigene Endlosschleife.


---
Es gibt sicherlich dutzende Möglichkeiten, endliche Automaten zu bauen. 
Aber Schleifen, welche andere Dinge blockieren, sind mit Vorsicht zu 
genießen.
Mal eben 3 Dinge in eine Schleife tun, kein Problem.
Aber im Kopf einer While() Schleife auf eine Zustandsänderung warten 
blockiert alles andere im System.

[Falk B. (falk)]

F. F. schrieb:
> Dann brauche ich aber auch noch Taschentücher. Da reicht einfaches
> wegwischen der Tränen nicht mehr. Ach ja, und Schlaftabletten, denn vor
> lauter Lachen komme ich dann auch nicht mehr in den Schlaf.

Und das ALLES ohne GEZ-Gebühren!!!

[Falk B. (falk)]

Arduino Fanboy D. schrieb:
> Ich behaupte:
> Jedes funktionierende Programm auf einem µC, ist, oder implementiert,
> eine oder mehrere, Zustandsautomaten.
> Damit dürfte ich ca. 99,9% aller Programme erwischt haben.
>
> Und das hat nichts damit zu tun, ob der jeweilige Programmierer,
> beabsichtigt hat, es zu implementieren, oder gar schon jemals von dem
> Pattern gehört hat.

Diese Aussage ist richtig aber nutzlos. Denn man kann problemlos jeden 
wirren Mist incl. Goto zusammenschustern. Und auch dieser Quark wird 
sich deterministisch verhalten, läuft ja auf einer deterministischen 
Hardware.

ABER!!!

Das ist weder sonderlich lesbar, wartbar, erweiterbar, testbar noch 
nachvollziehbar. Und ob der Code WIRKLICH das macht, was er machen SOLL, 
ist auch noch so eine Frage.

Ergo. Mit den bekannten, bewährten Konzepten fährt man zu 90% nicht nur 
sehr gut sondern auch deutlich besser.

[Falk B. (falk)]

@ Dieter (Gast)

>Ok, wenn die Schleifen jetzt nicht immer laufen,

Doch das tun sie, aber anders strukturiert.

> wie frage ich dann
>Messwerte vom AD-Wandler ab, überwache Ports. Ich kann ja nicht allem
>einen Interrupt zuordnen,

Muß man gar nicht.

> zumindesst nicht auf dem AVR.

Siehe Multitasking.

[Einer K. (Gast)]

Falk B. schrieb:
> Denn man kann problemlos jeden
> wirren Mist incl. Goto zusammenschustern.

Weiß gar nicht, was du gengen Goto hast...

Denn gerade beim Bau von endlichen Automaten ist es doch eine der vielen 
Optionen. Vielleicht nicht die schönste... aber immerhin, eine mögliche.

Zumindest eher, als eine blockierende while() Schleife, von der man 
nicht weiß, ob, oder wann sie endet.

[Falk B. (falk)]

Arduino Fanboy D. schrieb:
> Falk B. schrieb:
>> Denn man kann problemlos jeden
>> wirren Mist incl. Goto zusammenschustern.
>
> Weiß gar nicht, was du gengen Goto hast...

Goto braucht man in der Praxis sehr selten und sollte nur von Leuten 
genutzt werden, die wissen was sie WIRKLICH tun und wenn es WIRKLICH 
nicht sinnvoll anders geht.

> Denn gerade beim Bau von endlichen Automaten ist es doch eine der vielen
> Optionen. Vielleicht nicht die schönste... aber immerhin, eine mögliche.

Eine Suppe mit der Gabel essen ist auch eine Möglichkeit.
Vielleicht nicht die schönste... aber immerhin, eine mögliche.

> Zumindest eher, als eine blockierende while() Schleife, von der man
> nicht weiß, ob, oder wann sie endet.

Darum ging es gar nicht.

[Peter D. (peda)]

Die Statemachines müssen so geschrieben sein, daß sie zum Main zurück 
kehren, solange es nichts zu tun gibt.
Dann können mehrere Statemachines parallel ausgeführt werden.
Jede Statemachine sollte so klein wie möglich sein. Teilaufgaben macht 
man dann in einer separaten Statemachine.
Anbei mal ein Beispiel. Den Statemachines und States gibt man natürlich 
sinnvolle Namen.

[F. F. (foldi)]

Peter D. schrieb:
> Anbei mal ein Beispiel.

Genau so!

[Theor (Gast)]

Dieter schrieb:
> Dr. Sommer schrieb:
>> Wenn ständig die Schleifen laufen, hast du immer 100% CPU-Last und eine
>> hohe Leistungsaufnahme. Außerdem muss da "==" in die Schleifenbedingung.
>
> Ok, wenn die Schleifen jetzt nicht immer laufen, wie frage ich dann
> Messwerte vom AD-Wandler ab, überwache Ports. Ich kann ja nicht allem
> einen Interrupt zuordnen, zumindesst nicht auf dem AVR.

Du kannst den Portpins und dem AD-Wandler Interrupts zuordnen. Es gibt 
relativ viel, dem Du Interrupts zuordnen kannst.

Ganz abstrakt gehen auch die Timer-Interrupts um evtl. andere Ereignisse 
zu erkennen.

Es ist an sich schon richtig, dass ein uC nicht grundsätzlich direkt auf 
alle denkbaren asynchron stattfindenden Ereignisse reagieren kann.

Konkret aber sind dafür, - ich meine in den allermeisten Fällen -, 
gewisse Zeitvorgaben oder kausale Zusammenhänge vorhanden. Aus denen 
kann man ein entsprechendes Eingangssignal für die State-Machine 
generieren.

Ich will nicht strikt behaupten, dass das immer und immer ohne 
Kopfstände möglich ist, allerdings stelle ich doch mal in den Raum, dass 
es eher unwahrscheinlich ist, dass das nicht geht.

Es mag aber sein, dass Du einen konkreten Punkt nennen kannst. Dann tue 
das bitte.

---

Ich will einräumen, dass die Frage für den imaginären Fall eines 
Ereignisses auf den der uC nicht mit einem Interrupt reagieren kann, 
generell interessant ist.
Dennoch meine ich, es ist keine gute Idee, sich darauf zu verlassen, 
dass solch ein Ereignis genau dann noch erkannt werden kann, wenn der 
uC im Maximaltempo die Kriterien dafür auswertet.

In einem bestimmten Sinn ist das "unkontrolliertes" Verhalten. Ein wenig 
so, als wenn Du, falls Du gerade nichts anderes zu tun hast, immer 
wieder die Kühlschranktür aufmachst um zu sehen ob Du noch was einkaufen 
musst.
In vielen Fällen würdest Du die Tür aufmachen, nachsehen ob was fehlt, 
die Tür wieder zumachen und sie sofort wieder aufmachen und nachsehen.
Du verschwendest Deine Zeit damit immer wieder das selbe festzustellen.

Bei einem uC liegt die Sache etwas anders, denn da kann schon mal was 
ohne Dein Wissen aus dem Kühlschrank verschwinden.

ABER: im allgemeinen gilt, dass Ereignisse mit einer gewissen 
beschränkten Häufigkeit pro Zeiteinheit geschehen. Und das ist für einen 
uC, der ja auch in der Zeit agiert, das wesentliche Kriterium.

Falls also das Ereignis mit einer so hohen Rate geschieht, dass der uC 
gerade noch mit Deiner Methode mitkommt, so ist er eher 
unterdimensioniert, als das die Methode richtig ist.

"Sauber" und korrekt ist vielmehr, dass unter allen (notwendigen) 
Umständen, egal welche Abfolge von Zuständen durchlaufen wird, der uC 
dennoch rechtzeitig einen Punkt im Programm erreicht, an dem er das 
Kriterium auswerten kann. Aber nicht so schnell wie möglich.

Der Unterschied ist tatsächlich zum Teil philosophischer Natur als 
allein ein zwingend Technischer.
Das liegt daran, dass man in der Programmierung von gewissen Abfolgen 
und Häufigkeiten ausgeht, diese kalkuliert und ein Programm schreibt, 
dass diesen Abfolgen "aktiv" folgt.
Hingegen schreibt man ein Programm nicht so, dass es so schnell wie 
möglich auf alle "Eventualitäten" passiv reagieren kann. Das würde ja 
nur dann notwendig sein, falls man sich über gewisse Umstände nicht 
vollständig im klaren ist. So einen Zustand vermeidet man aber, wie der 
sprichwörtliche Teufel das Weihwasser.
Man bevorzugt und setzt viel Energie darein, eben genau und im Detail, 
zeitlich und logisch den Gesamtzusammenhang aller Umstände zu kennen.

Du wirst evtl. einwenden, dass Du ja nicht ausdrücklich darauf abzielst, 
auf irgendwelche Eventualitäten zu reagieren, die Du nicht einkalkuliert 
hast. Du magst einwenden, dass dies eben nur die textuell "einfachste" 
Methode ist, irgendwie so schnell wie möglich auf den "Rest" der 
Ereignisse zu reagieren.
Es ist aber egal, ob Du einfach nur in Kauf nimmst, dass Du keine 
Kontrolle hast oder ob Du absichtlich darauf verzichtest.
Der springende Punkt ist, dass das Du die Kontrolle aufgibst.

Ich hoffe das hilft Dir etwas weiter.

[Stefan F. (Gast)]

Manche Leute müsste man mal zur Windows 3.1 zurück schicken, damit sie 
lernen, mehrere Aufgaben quasi-parallel abzuarbeiten. Und zwar ohne ein 
Betriebssystem, dass die Threads automatisch verwaltet und ohne 
Interrupts.

[Apollo M. (Firma: @home) (majortom)]

Dieter schrieb:
> Was meint ihr? Taugt das Konzept was?

... habt ihr alle keinen friseur? häh!

das ist ein kein konzept und daher stellt sich die frage ob es was taugt 
auch nicht! tonne und muss weg!


mt

[W.S. (Gast)]

Stefanus F. schrieb:
> Manche Leute müsste man mal...

Ach, es würe ausreichen, denen einen anderen µC vorzusetzen als einen 
AVR ocer STM32, zum Beispiel einen FR30. Glaub's mir, das würde völlig 
ausreichen.

W.S.