Wie warte ich "richtig" auf Daten?

Jens Plappert schrieb:

> Nun mal aber die Frage: Wie macht man es denn Richtig?

Das System sieht eigentlich oft immer gleich aus:

1

int main()

2

{

3

  ....

4

5

  while( 1 ) {

6

7

    if( Ereignis )

8

       ....

9

10

11

    if( anderes Ereignis )

12

       .....

13

14

    etc. etc.

15

  }

16

}

d.h. in der Hauptschleife werden nacheinander alle möglichen 
Ereignisauslöser geprüft und wenn eines davon vorliegt, wird es 
bearbeitet.

> Beispiel: Ich habe eine Steuerung, die über eine Schnittstelle einen
> Befehl sendet und dann auf die Antwort wartet, um diese auszuwerten.

Auch das geht nach dem gleichen Schema.
Denn das eintreffen eines Zeichens ist auch nichts anderes als ein 
Ereignis. Das Zeichen hängt man zb an einen String an, in dem die 
bisherig empfangenen Zeichen gesammelt wurden und prüft vielleicht noch, 
ob damit die Antwort vollständig ist. Wenn ja, dann setzt man zb 
seinerseits ein Ereignis. Denn: niemand sagt, dass ein 'Ereignis' etwas 
ist, dass nur von externer Hardware ausgelöst werden kann. Ein 
'Ereignis', das kann genausogut eine Variable sein, die einen bestimmten 
Wert annimmt und welches später bei der Ereignisprüfung auf genau diesen 
Wert geprüft wird.

Eine Statemachine ist eine andere Variante, die in eine ähnliche 
Richtung geht. Zudem sagt ja auch niemand, dass ein Programm nur aus 
einer einzigen Statemaschine bestehen darf. Da drfen ja ruhig auch 
mehrere derartige Mechanismen gleichzeitig (hintereinander) am Werk 
sein.

Im konkreten Beispiel der UART bietet sich dann auch noch eine UART für 
die ISR an, die das Zeichen sammeln übernimmt.

Aber wie auch immer man es macht. Der kleinste gemeinsame Nenner besteht 
immer darin, dass es nur eine einzige Schleife gibt, die ständig läuft 
und das ist die Hauptschleife in main

1

int main()

2

{

3

   ...

4

5

   while( 1 ) {

6

7

     ...

8

   }

9

}

natürlich kann es vorkommen, dass zwischendurch mal kurz eine Schleife 
etwas mehr Zeit verbrutzelt, wenn sicher gestellt ist, dass es bei 
dieser kurzen Zeit bleibt. Aber sobald das nicht mehr erfüllt ist, 
wandelt man seine Aufgabe um in eine Abfolge von Ereignissen und die 
Hauptschleife fungiert wie ein Schrittschalter, der durch diese 
Ereigniskette durcharbeitet und so auch anderen Programmteilen die 
Gelegenheit gibt, ihr Ding zu machen.

> Würd mich einfach mal interessieren, was man da so empfiehlt, da ich es
> bisher halt immer ungefähr so gemacht habe.

Jedes Programm ist anders. Genau das ist es ja, was Programmierung so 
interessant macht. Wie gut eine bestimmte Technik funktioniert, hängt 
von der Aufgabenstellung und von den Nebenbedingungen ab. Das kann auch 
bedeuten, dass man sich ab und an mal etwas Neues einfallen lassen muss. 
Aber so im Großen und Ganzen funktioniert Ereignisbasiertes Arbeiten 
bzw. Statemaschines in den meisten Fällen sehr gut. Zumindest als 
Ausgangspunkt ist das immer gut geeignet.

Wenn es nix anderes zu tun gibt, kann man ruhig warten. Der Funktion 
einen "TimeOut" Parameter zu spendieren kann nützlich sein, aber nur 
wenn du dann was damit anfangen kannst. In diesem Konkretem Beispiel 
wäre vermutlich ein Watchdog eine Möglichkeit, falls ein Reset in 
Ordnung ist, oder alternativ den WD Interrupt nutzen um den User vorher 
nochmal darüber zu informieren, dass ein Timeout auftrat oder ein 
Schleife via Flag zu unterbrechen.

Stefan schrieb:
> Blockierende Warteschleifen sind völlig Ok, wenn der Mikrocontroller in
> dieser Zeit nicht anderes zu tun hat.

Sehe ich gar nicht so! Man sollte von Anfang an "richtig" (siehe Karl 
Heinz) programmieren. Genau das ist der Gedankenfehler, den man oft 
macht.
Man bekommt ein Stück bestehende Firmware und jemand sagt "Bau doch noch 
mal ganz schnell XYZ ein, der Rest funktioniert".

Und dann läuft es auf ein Re-design hinaus, weil der ursprüngliche 
Programmierer eben genau so gedacht hat.

oldmax schrieb:
> Damit verlierst du kein einziges Zeichen, egal welche Baudrate.
> Gruß oldmax

Naja ;-) Außer, wenn die Daten (über längere Zeit) schneller 
hereinkommen als sie verarbeitet werden.

Ein Ringpuffer ist aber auch nicht die Eierlegende WoMiSau. Ich habe in 
ein anderes Projekt vor kurzem eine XMODEM Implementierung eingebaut und 
mich u.A. deswegen gegen einen Ringpuffer entschieden, weil ich den 
Datenpuffer direkt an die datenverarbeitende Applikation übergeben kann 
ohne (erneut) zu kopieren.
Zumal die Blockgröße fix ist und nach dem Empfang eines Blocks sowieso 
genug Zeit zur Verarbeitung ist (also dort keine weiteren Zeichen mehr 
eintreffen).

Jens Plappert schrieb:
> mir gehts eigentlich nur um die Prinzipfrage an
> sich.

Es gibt keine Prinzipfrage an sich.
Es gibt unterschiedliche Probleme und unterschiedliche Lösungen. Es gibt 
keine einheitlich 'beste' Lösung aka Eierlegende Wollmilchsau am besten 
aber vegetarisch.

Was 'good practices' betrifft stimme ich dem zu was Karl Heinz, Oldmax 
und Simon gesagt haben.

Es gibt dafür sogar einen mathematischen Beweis.
Ich habe darüber einmal in einem Seminar referiert.
Es gibt keine allgemeinoptimalen Algorithmen!

"Ob ISR oder nicht" hat nicht so viel mit dem blockierenden 
Programmieren zu tun wie man zunächst meint. Was das einfach oder nicht 
betrifft:

Die ISR läßt sich auch in der UART_READ() verbergen. Ich kann also 
genauso einfach und/oder blockierend mit ISR programmieren. Es sieht nur 
intern anders aus.

Man muß aber im Hinterkopf behalten, daß die Codeausführung jederzeit 
unterbrochen werden kann, sobald man irgendwo Interrupts zuläßt. Dabei 
ist es irrelevant ob der aktuelle Code-Abschnitt selbst ISR verwendet. 
Umgekehrt kann ich damit fremden Code der für eine interruptfreihe 
Umgebung entwickelt wurde, auch wenn ich ihn nicht anrühre, durch 
Hinzufügen von Interrupts in meinem Code verhackstücken. Meine ISR 
unterbrechen dann den ansonsten fehlerfreien fremden Code bei der 
Ausführung und erzegen so sporadische kaum auffindbare Fehler zur 
Laufzeit, natürlich im Einsatz und nicht im der Entwicklungsabteilung. 
Sollte das ein Problem darstellen, so gibt es auch dafür Mittel und 
Wege. Aber das wäre ein anderes Thema.

Blockierend oder nicht ist eine Frage des Designs/der Planung.
ISR sind "nur" ein mächtiges Werkzeug, das man richtig oder falsch 
benutzen kann.

Das Thema ist zu komplex um es in einem Beitrag zu erklären. Selbst wenn 
man es aus einen Vorlesungsscript herauskopiert, so ist damit nicht viel 
gewonnen. Um es zu verstehen und sinnvoll einzusetzen ist der Stoff der 
gesamten Vorlesung nötig. Konkrete Fragen daraufhin sind in Beiträgen zu 
lösbar.

Erste Stichpunkte wäre in einem Script zu Betriebssystemen:
asynchron, atomar, Mutex, Monitore, Semaphore ...

Sicher kann man auch ISR ohne das verwenden. Lustig wird dann aber die 
Fehlersuche wenn einmal eine ISR genau da reinhaut, wo etwas eigentlich 
keine Unterbrechug verträgt. Das sind dann schwer reproduzierbare Fehler 
die mitunter extrem schwer zu finden sind.

Gruß

Carsten

Der Anfänger schreibt gerne:

1

void task1()

2

{

3

  while( nix_zu_tun )

4

    ;                  // drehe Däumchen

5

  tue_was();

6

}

Damit ist klar, das nichts anderes mehr zum Zuge kommt.

Der Trick ist nun, immer abweisend zu warten:

1

void task1()

2

{

3

  if( nix_zu_tun )

4

    return;            // gibt die Wartezeit zurück zur Main-Loop

5

  tue_was();

6

}