Auf Befehl warten ohne Blockierung des AVR

Andreas S. schrieb:

> Nun ist es natürlich so, dass erst wieder tuDies() und tuDas() gemacht
> wird, wenn ein Kommando über den UART gekommen ist. Kommt keins, wird
> solange nichts getan, bis ein Kommando kam. Ich hätte es aber gerne so,
> dass alles andere ausgeführt wird und nur wenn ein Kommando angekommen
> ist, wird die entsprechende Aktion ausgeführt. Wie bewerkstellige ich
> dies ?

Pseudocode

1

int main()

2

{

3

  ....

4

5

  while( 1 )

6

  {

7

8

    if( Es gibt ein Zeichen an der UART )

9

    {

10

      Zeichen holen

11

12

      if( Zeichen ist Kommando-Endekennung )

13

      {

14

        Führe Kommando aus

15

        Lösche Kommando-String

16

      }

17

18

      else if( Zeichen ist Kommando-Startkennung )

19

        Lösche Kommando-String

20

21

      else

22

        Hänge das Zeichen an den Kommando String an

23

    }

24

25

    Tu dies();

26

    Tu das();

27

  }

28

}

Also eigentlich so wie immer, wenn man ein Programm schreibt, welches 
mehrere Dinge 'quasi' gleichzeitig machen soll:
Man fasst alles als mögliches Ereignis auf, prüft in der Hauptschleife 
reihum alle möglichen Ereignisse darauf hin ab, ob sie vorliegen und 
wenn sie das tun, dann löst man die zugehörige Aktion aus.

In deinem Fall ist dann eben das 'mögliche Ereignis' nicht, dass ein 
Kommando fertig ist, sondern dass ein Zeichen an der UART eingetrudelt 
ist. Und dafür muss man sich dann eben überlegen, was man damit machen 
will.
In deinem Fall hat man mit einem einzelnen Zeichen noch nichts 
angefangen, also muss man viele derartige 'mögliche Ereignisse' sammeln 
(den Kommandostring aufbauen), bis dann eben irgendwann alles vorhanden 
ist, so dass man mit der Abarbeitung beginnen kann.

PS: ein bischen Aufwand wirst du noch in den Teil stecken müssen, der 
einfach das Zeichen anhängt. Denn das Zeichen sollte nur dann angehängt 
werden, wenn vorher eine Startkennung gesichtet wurde. Aber mit einem 
Flag ist das ja kein Problem.

Das wäre die Variante ohne Interrupt. Die ist übersichtlich und 
funktioniert auch gut.

Allerdings nur, wenn die Hauptschleife so schnell durchlaufen wird, dass 
zwischen den Durchläufen nicht mehr als ein Zeichen an der Schnittstelle 
ankommen kann. Sprich, die Baudrate und die Abarbeitungsgeschwindigkeit 
der Hauptschleife müssen zusammenpassen.

Wir wissen ja nicht, was in der Hauptschleife passiert. Vielleicht steht 
da irgendwo ein längeres _delay_ms(), weil eine LED blinken soll oder 
ähnliches. Jetzt mal unabhängig davon, ob das guter Stil ist, man sieht 
es oft bei Anfängern, die hier Fragen stellen.

In einem solchen Fall bietet sich an, den Receive-Interrupt des USART 
abzufangen und den Kommandostring dort zusammenzusetzen. Wenn ein 
vollständiges Zeichen empfangen ist, kopiert man den String um und setzt 
ein Flag für die Hauptschleife.

Wenn es nicht zu viele verschiedene Kommandos gibt und diese keine 
Parameter enthalten, kann man auch für jedes mögliche Kommando ein 
eigenes Flag vorsehen.

Oliver Döring schrieb:
> Das wäre die Variante ohne Interrupt. Die ist übersichtlich und
> funktioniert auch gut.
>
> Allerdings nur, wenn die Hauptschleife so schnell durchlaufen wird, dass
> zwischen den Durchläufen nicht mehr als ein Zeichen an der Schnittstelle
> ankommen kann. Sprich, die Baudrate und die Abarbeitungsgeschwindigkeit
> der Hauptschleife müssen zusammenpassen.


Er benutzt
http://homepage.hispeed.ch/peterfleury/avr-software.html

und von der weiß ich zufällig, dass sie Interruptgesteuert ist und über 
einen kleinen Ringbuffer verfügt, der sich genau um diese 
Problemstellung kümmert.

Siehe Multitasking.