Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
Rasenmaehroboter fuer schwierige und grosse Gaerten im Test

 
(Betriebsystem für Bascom-Anwendung)
Zeile 14: Zeile 14:
 
'''Die Aufgabe''':  
 
'''Die Aufgabe''':  
  
*sagen wir, Unit-1 soll irgendwas 400 mal machen,  
+
*sagen wir, Unit-1 soll irgendwas 400-mal machen,  
*Unit-2 soll auch was tun, aber 500 mal  
+
*Unit-2 soll auch was tun, aber 500-mal  
  
 
Sagen wir auch, das "Unit 1 ist grad dran.  
 
Sagen wir auch, das "Unit 1 ist grad dran.  
  
*Es setzt Warteschlangen Aufruf auf sich selbst ab
+
*Es setzt einen Warteschlangen Aufruf auf sich selbst ab
 
  Call msg_enqueue(0, tag , CMD_FOR , 400 )
 
  Call msg_enqueue(0, tag , CMD_FOR , 400 )
 
  --exit sub--
 
  --exit sub--
  
 
Jetzt kommt die andere Unit dran.  
 
Jetzt kommt die andere Unit dran.  
*Es setzt Warteschlangen Aufruf auf sich selbst ab
+
*Es setzt ebenfalls eine solchen Aufruf ab, aber mit einem anderen Parameter
 
  Call msg_enqueue(0, tag , CMD_FOR , 500 )
 
  Call msg_enqueue(0, tag , CMD_FOR , 500 )
 
  --exit sub--
 
  --exit sub--
Zeile 32: Zeile 32:
 
  Unit-2  ( unit-1-Tag  , CMD_FOR  , 500)
 
  Unit-2  ( unit-1-Tag  , CMD_FOR  , 500)
  
Und beide machen im "Select case CMD_FOR:"-Zweig erstmal das, was sie eben zu tun haben, und dann beide:
+
Und beide machen im "Select case CMD_FOR:"-Zweig erstmal das, was sie eben zu tun haben.<br>
 +
Dann wird aber gezählt:
 
<pre>
 
<pre>
 
   tempw = Param  (Param ist ja 400 bzw. 500, je nach Unit)
 
   tempw = Param  (Param ist ja 400 bzw. 500, je nach Unit)
Zeile 44: Zeile 45:
 
  Unit-2  ( unit-1-Tag  , CMD_FOR  , 499)
 
  Unit-2  ( unit-1-Tag  , CMD_FOR  , 499)
  
Man kann sich vorstellen, wie das weitergeht. Bei Null hören die Units auf, sich selbst aufzurufen und sind fertig.
+
Man kann sich vorstellen, wie das weitergeht. Bei Null hören die Units auf, sich selbst aufzurufen und sind fertig. Die eine nach 400, die andere nach 500 Durchläufen.
  
'''Der Effekt''': Ohne weiters Zutun machen die beiden Units abwechselnd jeweils eine "FOR"-Schritt, und der Anschein der Gleichzeitigkeit ist gegeben, abgesehen davon, daß auch Anfang und Ende der Schleifen sich beliebig überlappen können. Und weiter Units können genauso beliebig da einsteigen.
+
'''Der Effekt''': Ohne weiters Zutun machen die beiden Units abwechselnd jeweils eine "FOR"-Schritt, und der Anschein der Gleichzeitigkeit ist gegeben, abgesehen davon, daß auch Anfang und Ende der Schleifen sich beliebig überlappen können. Und weiter Units können genauso beliebig da irgendwann einsteigen.  
 
+
'''Anmerkung''': Natürlich geschehen keine Wunder, insgesamt wird im Beispiel ja in Summe bis 900 gezählt, und solange dauert das Ganze eben auch. Aber vom Programmieren her ist es bei größeren Projekten sehr angenehm, wenn nicht in der einen Schleife auch immer irgendwie eine andere berücksichtigt werden muß.  
+
  
 +
'''Anmerkung''': Natürlich geschehen keine Wunder, insgesamt wird im Beispiel ja in Summe bis 900 gezählt, und solange dauert das Ganze eben auch. Aber vom Programmieren her ist es bei größeren Projekten sehr angenehm, wenn nicht in der einen Schleife auch immer irgendwie eine andere berücksichtigt werden muß.
  
 
==Autor==
 
==Autor==

Version vom 9. März 2006, 20:33 Uhr

Betriebsystem für Bascom-Anwendung

In Betriebsystem für Bascom wurde ein Unit-Konzept und das "message-queueing" vorgestellt. Nun, wann bringt das jetzt eigentlich was, außer daß es ein 'rumgefummel ist ?

Parallele FOR-Schleifen

Angenommen, es sollen zwei verschiedene FOR-Schleifen "gleichzeitig" abgearbeitet werden. "Gleichzeitig" in Anführungs-Strichen, denn wie jeder gemerkt hat, geht das nicht ganz so einfach. Wir können mit dem Bascom-System aber diese beider Schleifen recht einfach nebeneinander/verschachtelt arbeiten lassen, ohne daß die Schleifen irgendwie voneinander was wissen müssen.

Beispiel:

  • Wir haben zwei Units,
Sub UNIT_1 (byval Tag As Word , Byval Cmd As Byte , Byval Param As Word)
Sub UNIT_2 (byval Tag As Word , Byval Cmd As Byte , Byval Param As Word)
  • es gibt ein Command "CMD_FOR"

Die Aufgabe:

  • sagen wir, Unit-1 soll irgendwas 400-mal machen,
  • Unit-2 soll auch was tun, aber 500-mal

Sagen wir auch, das "Unit 1 ist grad dran.

  • Es setzt einen Warteschlangen Aufruf auf sich selbst ab
Call msg_enqueue(0, tag , CMD_FOR , 400 )
--exit sub--

Jetzt kommt die andere Unit dran.

  • Es setzt ebenfalls eine solchen Aufruf ab, aber mit einem anderen Parameter
Call msg_enqueue(0, tag , CMD_FOR , 500 )
--exit sub--

DIe Units werden nun durch "msg_dequeue()" nacheinander aufgerufen

Unit-1  ( unit-1-Tag  , CMD_FOR  , 400)
Unit-2  ( unit-1-Tag  , CMD_FOR  , 500)

Und beide machen im "Select case CMD_FOR:"-Zweig erstmal das, was sie eben zu tun haben.
Dann wird aber gezählt:

  tempw = Param   (Param ist ja 400 bzw. 500, je nach Unit)
  decr tempw 
  if tempw > 0 then 
       Call msg_enqueue(0, tag , CMD_FOR , tempw )
  end if

d.h. beim nächsten mal heissen dann schon die Aufrunfe

Unit-1  ( unit-1-Tag  , CMD_FOR  , 399)
Unit-2  ( unit-1-Tag  , CMD_FOR  , 499)

Man kann sich vorstellen, wie das weitergeht. Bei Null hören die Units auf, sich selbst aufzurufen und sind fertig. Die eine nach 400, die andere nach 500 Durchläufen.

Der Effekt: Ohne weiters Zutun machen die beiden Units abwechselnd jeweils eine "FOR"-Schritt, und der Anschein der Gleichzeitigkeit ist gegeben, abgesehen davon, daß auch Anfang und Ende der Schleifen sich beliebig überlappen können. Und weiter Units können genauso beliebig da irgendwann einsteigen.

Anmerkung: Natürlich geschehen keine Wunder, insgesamt wird im Beispiel ja in Summe bis 900 gezählt, und solange dauert das Ganze eben auch. Aber vom Programmieren her ist es bei größeren Projekten sehr angenehm, wenn nicht in der einen Schleife auch immer irgendwie eine andere berücksichtigt werden muß.

Autor

Siehe auch


LiFePO4 Speicher Test