borg Geschrieben October 30, 2012 at 14:09 Geschrieben October 30, 2012 at 14:09 So, die Beschreibung des neuen Protokolls ist online: http://www.tinkerforge.com/doc/Protocol_20.html Produktive Kritik ist erwünscht . Zitieren
Nic Geschrieben October 30, 2012 at 16:19 Geschrieben October 30, 2012 at 16:19 Ich würde Dezember um Weihnachten und Sylvester eher empfehlen, dann haben wir ev. mehr Zeit für die eine oder andere Anpassung/FW-Upgrades etc. Was bedeudeten die Funktionen brick_is_configured? Ist das eine Implementation von uns oder eine aus der neuen API ? Topologie und connctedUID Was beduetet das für die Extensions ? Bleiben die davon unbeteiligt ? deviceIdentifier Beschreibt eindeutig den Typ des Bricks oder Bricklets ? Zitieren
ArcaneDraconum Geschrieben October 30, 2012 at 16:33 Geschrieben October 30, 2012 at 16:33 Also wenn ich das richtig verstanden habe, sind alle Extensions im Moment inkompatibel by design. Das wäre schon ein Problem... solange dies nicht gelöst ist wird die neue Firmware schlecht ankommen. Vor allem Bricks eine eigene UID zu geben finde ich klasse, in einem größeren Verbund muss ich immer genau hinschauen, wer wohin gehört. Zitieren
AuronX Geschrieben October 30, 2012 at 16:48 Geschrieben October 30, 2012 at 16:48 Sieht schonmal sehr cool aus. Verstehe ich es richtig, dass: - Die maximale Paketgröße weiterhin nach oben hin begrenzt ist? (512 Bit Payload + 64 Bit Extensions) Ist das das technische Maximum oder nur pessimistisch gewählt? - Ich nicht erkennen kann auf welchem Weg ein Master-Brick mit Extension zur Stack-Wurzel verbunden ist? siehe ASCII-Art unten: Hat Master2 jetzt als Elternelement die 1, den Master1 oder gar die Chibi-Ext1 (die im bisherigen Protokoll keine eigene UID hätte) PC <--- USB ---> Master1 --- Chibi-Ext1 <--- Funk ---> Chibi-Ext2 --- Master2 Ich fände es erstrebenswert, wenn die Extensions eine eigene UID bekämen. Sofern ich das im Moment richtig verstehe bietet ja das Master-Brick eine fette API an (für alle Extensions) und die Extensions laufen einfach unter der UID des Masters. Es wäre cool, wenn die Extension sich direkt per UID ansprechen ließe und somit auch das (sichtbare) Interface des Masters schrumpfen könnte. Zitieren
borg Geschrieben October 30, 2012 at 16:50 Autor Geschrieben October 30, 2012 at 16:50 Was bedeudeten die Funktionen brick_is_configured? Ist das eine Implementation von uns oder eine aus der neuen API ? Von euch. Wir machen dann natürlich noch ein echtes Beispiel dafür. Topologie und connctedUID Was beduetet das für die Extensions ? Bleiben die davon unbeteiligt ? WIFI und Ethernet sind davon nicht betroffen. Bei Chibi und RS485 steht in der connctedUID die UID des Master Bricks im Master Chibi/RS485 stack. Damit kann man dann natürlich auch die Extension-Topologie herausfinden! deviceIdentifier Beschreibt eindeutig den Typ des Bricks oder Bricklets ? Einfach eine Zahl die den Brick/Bricklet identifiziert. Also z.B. Master Brick = 1001 Servo Brick = 1002 Stepper Brick = 1003 ... Ambient Light Bricklet = 2001 Temperature Bricklet = 2002 ... Also wenn ich das richtig verstanden habe, sind alle Extensions im Moment inkompatibel by design. Das wäre schon ein Problem... solange dies nicht gelöst ist wird die neue Firmware schlecht ankommen. Was meinst du mit "inkompatibel by design"? Du wirst einen 1.x.y RS485 stack nicht zusammen mit einem 2.x.y RS485 stack verwenden können. Wie soll das gehen? Die alte Hardware kann natürlich weiterverwendet werden. Zitieren
AuronX Geschrieben October 30, 2012 at 17:00 Geschrieben October 30, 2012 at 17:00 Okay, nochmal gelesen... ein per Extension verbundenes Masterbrick (oben Master2) erkenne ich daran, dass es als Elternelement ein Master-Brick hat und gleichzeitig die Stack-Position 0, richtig? Weil wäre es nicht auf Position 0, dann wäre es direkt (Stacking) verbunden. Und es geht ja nicht, dass ein per Extension verbundenes Master-Brick auf einer anderen Position als 0 liegt, richtig? Zitieren
ArcaneDraconum Geschrieben October 30, 2012 at 17:01 Geschrieben October 30, 2012 at 17:01 Nun ja, wenn ich den Text richtig verstanden habe wird die StackID zur Kommunikation zwischen Master und Extension benutzt, aber die StackID gibt es nimmer. Ich verstehe es so, dass demnach das interne Stackprotokoll geändert werden muss. Aber wie soll ich die Firmware einer Extension flashen? Natürlich kann ich es auch falsch verstanden haben, darum soll es ja auch als Frage verstanden werden. Dass alle Komponenten eines Stapels auf die neue Firmware müssen sehe ich als logisch an. Zitieren
borg Geschrieben October 30, 2012 at 17:03 Autor Geschrieben October 30, 2012 at 17:03 - Die maximale Paketgröße weiterhin nach oben hin begrenzt ist? (512 Bit Payload + 64 Bit Extensions) Ist das das technische Maximum oder nur pessimistisch gewählt? Die Bricks haben einige interne Buffer in Größe der maximalen Paketgröße (für unterschiedlichste Dinge). Das Paket war damals insgesamt maximal 64 Byte groß (4 Byte header, 60 Byte Payload). Wir haben jetzt im neuen Format das Payload auf maximal 64 Byte erhöht und das drumherum ist in Summe maximal 16 Byte groß. D.h. die Buffer wachsen alle um 16 Byte. Das ist noch verträglich. Eine Messagegröße von 128 Byte (doppelter RAM-Verbrauch) wäre z.B. definitiv zuviel des guten! - Ich nicht erkennen kann auf welchem Weg ein Master-Brick mit Extension zur Stack-Wurzel verbunden ist? siehe ASCII-Art unten: Hat Master2 jetzt als Elternelement die 1, den Master1 oder gar die Chibi-Ext1 (die im bisherigen Protokoll keine eigene UID hätte) PC <--- USB ---> Master1 --- Chibi-Ext1 <--- Funk ---> Chibi-Ext2 --- Master2 Master1: uid=a, connctedUID=1 Master2: uid=b, connctedUID=a Ich fände es erstrebenswert, wenn die Extensions eine eigene UID bekämen. Sofern ich das im Moment richtig verstehe bietet ja das Master-Brick eine fette API an (für alle Extensions) und die Extensions laufen einfach unter der UID des Masters. Es wäre cool, wenn die Extension sich direkt per UID ansprechen ließe und somit auch das (sichtbare) Interface des Masters schrumpfen könnte. Eine eigene UID für die Extensions würde das ganze nur verkomplizieren. Die Idee das man Bindings für die Extensions hat gefällt mir aber trotzdem. Ich stelle mir sowas vor: master = Master(UID_MASTER) # Make Master Brick object try { wifi = WIFIExtension(master) # Make WIFI Extension object for master } except(ExtensionNotAvailableException e) { ... } wifi.set_configuration(...) Das hat jetzt nichts mit dem Protokoll zu tun, müsste man den Generatoren halt beibringen. Ist natürlich ein bisschen Arbeit, aber jetzt wäre auf jeden Fall der richtige Zeitpunkt dafür. Zitieren
borg Geschrieben October 30, 2012 at 17:04 Autor Geschrieben October 30, 2012 at 17:04 Okay, nochmal gelesen... ein per Extension verbundenes Masterbrick (oben Master2) erkenne ich daran, dass es als Elternelement ein Master-Brick hat und gleichzeitig die Stack-Position 0, richtig? Weil wäre es nicht auf Position 0, dann wäre es direkt (Stacking) verbunden. Und es geht ja nicht, dass ein per Extension verbundenes Master-Brick auf einer anderen Position als 0 liegt, richtig? Exakt richtig! Zitieren
borg Geschrieben October 30, 2012 at 17:07 Autor Geschrieben October 30, 2012 at 17:07 Nun ja, wenn ich den Text richtig verstanden habe wird die StackID zur Kommunikation zwischen Master und Extension benutzt, aber die StackID gibt es nimmer. Ich verstehe es so, dass demnach das interne Stackprotokoll geändert werden muss. Aber wie soll ich die Firmware einer Extension flashen? Die Firmware für die Extensions ist mit auf den Master Bricks. In dem EEPROM einer Extension werden nur die Konfigurationen gehalten. Wir hatten damals geplant die Firmware der Extensions auch mit auf das EEPROM zu packen, leider passt das aber nicht annäherend. Für die Ethernet Extension hab ich z.B. gerade ein DHCP Client implementiert, diese Implementierung alleine ist schon größer als der Flash. Hinzu kommt, dass die Extensions sich Code teilen. Zum Beispiel gibt es eine brickd Implementierung auf dem Master Brick, die von WIFI Extension und Ethernet Extension gleichzeitig genutzt wird. Edit: Nur um das nochmal klarer zu schreiben: Die WIFI Extension hat einen Prozessor mit drauf (vergleichbar mit dem Raspberry PI), die Firmware für diesen Prozessor ist natürlich _nicht_ auf dem Master Brick. Aber diese Firmware spricht einfach TCP/IP und das Protokoll was wir darauf sprechen ist im Master Brick implementiert und natürlich an das neue Protokoll anpassbar. Ich hoffe das ist verständlich. Zitieren
AuronX Geschrieben October 30, 2012 at 17:14 Geschrieben October 30, 2012 at 17:14 Die Idee das man Bindings für die Extensions hat gefällt mir aber trotzdem. Ich stelle mir sowas vor Sehr gut! Eigentlich war das auch das einzige was ich am Ende des Tages haben wollte Ist auch richtig, dass man deswegen nicht die arme Firmware aufblähen muss. Ich dachte nur es wäre passend, weil es ja bei den Bricklets im wesentlichen genauso funktioniert oder? Da "denkt" ja auch das Master-Brick und das Bricklet ist dumm. Ich bin wirklich total begeistert und freue mich schon auf das neue Protokoll ^^ Zitieren
ArcaneDraconum Geschrieben October 30, 2012 at 17:20 Geschrieben October 30, 2012 at 17:20 @borg: OK, dann bin ich beruhigt. Für mich ist es wichtig, dass ich alles weiter verwenden kann. Ansonsten sehe ich das Gänze sehr positiv. Es eröffnet auch wieder viele Stunden Bastelei und Anpasserei. Zitieren
Loetkolben Geschrieben October 30, 2012 at 17:56 Geschrieben October 30, 2012 at 17:56 Meine Anmerkungen/Fragen dazu vom dem was ich bisher verstanden habe. Wenn ein Bricklet im Stack getauscht wird muss dann wirklich die Software angepasst werden? 3 Mal tauschen bedeutet 6 mal patchen? Kann man die neuen Funktionsaufrufe gruppieren, wobei auch "Loecher" sein duerfen? Siehe "get_usb_voltage" 00-0f Spannungen 10-1f Wifi 20-2f RS485 30-3f Onboard LED Sind OO [Other Options] (2 bit) nicht ein wenig zu klein gedacht? Oder habe ich es nicht verstanden? So und nun mein groesstes anliegen. Kann man nicht anstelle der Bitfummelei einfach Bytes nehmen? Ja, als Hardware naher Mensch liebe ich es auch mit Bits auf die Beinchen vom Chip zu gehen, aber wenn man mit Software hantiert, dann muss man aus 5 true/false Werten erstmal umstaendlich ein Byte basteln. Spaetestens bei der Shell tut das weh! Mit einem "if true then x=\01 else x=\00" geht es viel leichter und es waere doch sicher vielen geholfen. Die 10 Byte mehr pro Paket sollten doch niemand stoeren. Ich muesstet dann nur so parsen: Entweder\00 = Funktion nicht gesetzt (0) und \01 = Funktion gesetzt (1) Rest wird ignoriet oder\00 = Funktion nicht gesetzt (0) und \01 bis \ff = Funktion gesetzt (1) Der Loetkolben Zitieren
borg Geschrieben October 30, 2012 at 18:36 Autor Geschrieben October 30, 2012 at 18:36 Meine Anmerkungen/Fragen dazu vom dem was ich bisher verstanden habe. Wenn ein Bricklet im Stack getauscht wird muss dann wirklich die Software angepasst werden? 3 Mal tauschen bedeutet 6 mal patchen? Kann man die neuen Funktionsaufrufe gruppieren, wobei auch "Loecher" sein duerfen? Siehe "get_usb_voltage" 00-0f Spannungen 10-1f Wifi 20-2f RS485 30-3f Onboard LED Sind OO [Other Options] (2 bit) nicht ein wenig zu klein gedacht? Oder habe ich es nicht verstanden? So und nun mein groesstes anliegen. Kann man nicht anstelle der Bitfummelei einfach Bytes nehmen? Ja, als Hardware naher Mensch liebe ich es auch mit Bits auf die Beinchen vom Chip zu gehen, aber wenn man mit Software hantiert, dann muss man aus 5 true/false Werten erstmal umstaendlich ein Byte basteln. Spaetestens bei der Shell tut das weh! Mit einem "if true then x=\01 else x=\00" geht es viel leichter und es waere doch sicher vielen geholfen. Die 10 Byte mehr pro Paket sollten doch niemand stoeren. Ich muesstet dann nur so parsen: Entweder\00 = Funktion nicht gesetzt (0) und \01 = Funktion gesetzt (1) Rest wird ignoriet oder\00 = Funktion nicht gesetzt (0) und \01 bis \ff = Funktion gesetzt (1) Der Loetkolben Öh, ich antworte mal nicht zu jeder Frage einzeln, du hast da irgendwas falsch verstanden . Die Bindings nach außen hin werden exakt so bleiben sie momentan sind. Im Hintergrund fällt ein bisschen Gefummel weg, weil die Stack ID wegfällt. Die einzelnen Bits der Optionen setzt du natürlich nicht selber, da gibt es API für. Die IPConnection wird sowas haben wie (Pseudocode): ipcon.setAuthenticationKey(byte[96] key) ipcon.enableBlockingSetter() ipcon.disableBlockingSetter() Dazu dann evtl. den Vorschlag von AuronX, ansonsten könnt ihr euren Source Code weiterverwenden. Die Alten 64bit UIDs können auch weiterverwendet werden, die rechnen wir in der IPConnection einfach um. Das einzige was sich wirklich ändert ist der Enumerate Callback. Da gab es ja schon reichlich Beschwerden und Verbesserungsvorschläge, die wir eigentlich mit dem neuen Enumerate Callback alle umgesetzt haben sollten . Edit: Zu den Other Options: Die 7 "future use" bits können natürlich auch für Optionen genutzt werden. Desweiteren kann man natürlich mit einem bit auch noch weitere Optionen aktivieren, die dann unten beim Optional Data mit drinstehen. Da sind schon noch reichlich Bits frei . Zitieren
Loetkolben Geschrieben October 30, 2012 at 20:18 Geschrieben October 30, 2012 at 20:18 Hmm, entweder ich bin auf dem Holzweg oder wir reden aneinander vorbei. :gruebel: Sieh hier: TCP/IP Wenn ich mein IP Paket packe muss ich da doch sehrwohl die Bits vorher zusammenrechnen? Wie bitte soll ich dann den Stack ansprechen wenn es keine StackID mehr gibt? Da muss wohl nun die UID dran glauben. Das mit den UID und den verschiendenen Darstellungs-formen/-formaten war mir immer schon ein Graus! Was ist zu tun wenn ich die Bricklets mal tausche? Helft mir doch mal auch die Spruenge. Der Loetkolben Zitieren
borg Geschrieben October 30, 2012 at 21:30 Autor Geschrieben October 30, 2012 at 21:30 Hmm, entweder ich bin auf dem Holzweg oder wir reden aneinander vorbei. :gruebel: Sieh hier: TCP/IP Wenn ich mein IP Paket packe muss ich da doch sehrwohl die Bits vorher zusammenrechnen? Wie bitte soll ich dann den Stack ansprechen wenn es keine StackID mehr gibt? Da muss wohl nun die UID dran glauben. Das mit den UID und den verschiendenen Darstellungs-formen/-formaten war mir immer schon ein Graus! Was ist zu tun wenn ich die Bricklets mal tausche? Helft mir doch mal auch die Spruenge. Der Loetkolben Wenn du ein Brick/Bricklet tauscht, musst du im Code natürlich die UID tauschen, wie beim alten Protokoll. Alternativ basiert dein Code komplett auf den Antworten vom Enumerate Callback, dann muss nichts getauscht werden. Wenn du selber TCP/IP Pakete baust musst du natürlich auch selber "die Bits zusammenrechnen". Damit du das nicht machen musst bieten wir ja schließlich die ganzen Bindings . Das zusammenbauen der Option und Flags Bytes ist absolut trivial verglichen mit dem "Resolve UID to Stack ID" Prozess (der jetzt wegfällt). D.h. meiner Meinung nach wird es mit dem neuen Protokoll leichter selbst TCP/IP Bindings zu bauen. options = (sequenz << 0) | (return_expected << 4) | (authentication << 5) Fertig. Die 10 Byte mehr pro Paket sollten doch niemand stoeren. Ich muesstet dann nur so parsen Das Durchschnittliche Paket bei uns im System hat einen Payload der größe 3 Byte. D.h. die Nachricht war im Alten Protokoll 7 Byte groß, im neuen ist sie 11 Byte groß. 10 Byte mehr würde den Durchsatz halbieren, nur damit man sich den oben geschriebenen Code sparen kann wenn man selber das Protokoll auf TCP/IP Ebene implementiert ? Edit: Die nächsten Bindings die wir veröffentlichen werden übrigens Shell Bindings sein, das sollte für dich interessant sein! Das wird in etwas so aussehen: user@pc:~$ tfcall -u abc -f getTemperature 25.41 user@pc:~$ tfcall -u Nq41f -f setServoPosition -p 1,180 Oder allgemein: tfcall -u UID -f function [-p parameters] [-o options] Dadurch das man mit dem neuen Protokoll einfach Daten ins System schicken kann, ohne vorher eine Verbindung aufzubauen, ist das super einfach zu generieren . Zitieren
AuronX Geschrieben October 30, 2012 at 21:58 Geschrieben October 30, 2012 at 21:58 Naja, die TCP-Doku ist halt die Doku des Transport-formates. Transportformate sind auch in heutiger Zeit noch immer auf Effizienz und Bitschubserei ausgelegt, bequem wird es erst im High-Level-Bereich. Vergleiche hierzu TCP: Syn, Ack, Fin usw sind dort auch nur einzelne Bits. Kurzum: Die TCP-Variante soll nicht bequem sein, sondern nur gut. Worüber man natürlich diskutieren kann ist es, dass man gutes Tooling bereitstellt um dennoch bequem über die Kommandozeile (bash, cmd was auch immer) mit Bricks zu kommunizieren. Und jetzt das allerbeste: Nachdem ich diesem langen Absatz dort oben geschrieben habe, habe ich die letzte Antwort von borg gelesen! Geil! RAUS AUS MEINEM KOPF! Ich lass das jetzt einfach so stehen und sende es trotzdem ab. Zitieren
Loetkolben Geschrieben October 31, 2012 at 01:37 Geschrieben October 31, 2012 at 01:37 Wenn du ein Brick/Bricklet tauscht, musst du im Code natürlich die UID tauschen, wie beim alten Protokoll. Alternativ basiert dein Code komplett auf den Antworten vom Enumerate Callback, dann muss nichts getauscht werden. Ich habe im IP Paket immer nur die Stack ID angegeben. Wenn ich das Bricklet getauscht habe (gleicher Typ) musste nichts geaendert werden! Das Tool zum ermitteln der Stack ID war aber wirklich eine Plackerei. Da nimmt man besser den Brickviewer. Warum kann ich nicht (alternativ) die Brickletport direct/gezielt ansprechen? D.h. meiner Meinung nach wird es mit dem neuen Protokoll leichter selbst TCP/IP Bindings zu bauen. Bindings? Tools will ich schreiben und keine Binding bauen. Was ist gegen so einen schlanken Code einzuwenden? Alles rein OS basiert. TEMP1=`echo -n -e "\x02\x01\x04\x00" | nc -w3 192.168.10.10 4223 | od -w54 -A n -t x2 | tr -d " " | cut -b 9- | tr "[:lower:]" "[:upper:]"` TEMP2=`echo "scale=2 ; ibase=16; $TEMP1 / 64" | bc` echo -e "\nDie Temperatur betraegt: $TEMP2 Grad.\n" Wobei der eigentliche Kern "echo -n -e "\x02\x01\x04\x00" | nc -w3 192.168.10.10 4223" alles sagt. Wenn man da jetzt noch Bits zusammenbauen und auseinanderpfuecken soll wird man bekloppt in der Birne! Das Durchschnittliche Paket bei uns im System hat einen Payload der größe 3 Byte. D.h. die Nachricht war im Alten Protokoll 7 Byte groß, im neuen ist sie 11 Byte groß. 10 Byte mehr würde den Durchsatz halbieren, nur damit man sich den oben geschriebenen Code sparen kann wenn man selber das Protokoll auf TCP/IP Ebene implementiert Ja genau! Das mag sein und stimmen, aber bitte wo ist der Falschenhals, dass man so sparen muss? Ich glaube nicht, dass der Stack soviel Daten liefern kann, dass er ein 100MBit (oder 10MBit) LAN dicht machen kann. Allein der IP Overhaed ist doch einiges mehr. Erklaert es mir bitte mal. BTW: Wenn denn so viele Paket pro Sekunde kommen ist dann ein 4 Bit Sequence Number Zaehler ausreichend? Was ist wenn so ein Stack mal fuer "einen Moment" nicht da ist und der Zaehler mal wieder ueberlaeuft oder geht das nicht? Die nächsten Bindings die wir veröffentlichen werden übrigens Shell Bindings sein Spielverderber Ich hoffe als Shellscript und ohne Installationsgedusel. Ich finde die Idee des neuen Protokolls gut, aber ich moechte mit meinen Anregungen vermeiden, dass man in die naechste Falle laeuft und in einem Jahr V 3 disktiert wird. Weiterhin gutes Gelingen! Der Loetkolben Zitieren
borg Geschrieben October 31, 2012 at 09:01 Autor Geschrieben October 31, 2012 at 09:01 Ja genau! Das mag sein und stimmen, aber bitte wo ist der Falschenhals, dass man so sparen muss? Ich glaube nicht, dass der Stack soviel Daten liefern kann, dass er ein 100MBit (oder 10MBit) LAN dicht machen kann. Allein der IP Overhaed ist doch einiges mehr. Erklaert es mir bitte mal. Der Flaschenhals ist natürlich nicht das USB Protokoll oder Ethernet. Der Flaschenhals sind die Buffer auf den Microcontrollern, die Zeit die wir benötigen um per SPI die Buffer der WIFI Extension auszulesen, um bei der Authentication auf dem Microcontroller den Hash zu bestimmen usw usw... Guck dir den Master Brick an: Dort werden einmal pro ms die Bricklet Plugins ausgeführt, die haben je 150us Zeit. Also sind schonmal 600us weg. D.h. wir haben noch 400us Zeit um im Zweifelsfall zwei Extensions , den Stack, USB und die Authentifizierung zu bearbeiten. Dort ist alles abhängig von der Paketgröße ! BTW: Wenn denn so viele Paket pro Sekunde kommen ist dann ein 4 Bit Sequence Number Zaehler ausreichend? Was ist wenn so ein Stack mal fuer "einen Moment" nicht da ist und der Zaehler mal wieder ueberlaeuft oder geht das nicht? Das ist nicht weiter schlimm. Grundsätzlich Antworten Bricks im Moment ja immer in der richtigen Reihenfolge, d.h. die Sequenz Nummer ist im Moment gar nicht nötig. Wenn wir in Zukunft irgendwann einen Brick haben der echtes Multitasking kann, wird er kaum mehr als 16 Nachrichten gleichzeitig bearbeiten können. Zitieren
AuronX Geschrieben October 31, 2012 at 09:39 Geschrieben October 31, 2012 at 09:39 Verstehe ich es richtig, dass die Sequence-Number zunächst gar nicht genutzt wird und eher als "future use" gedacht ist? Wenn dem so ist würde ich villt die Reihenfolge im Protokoll so tauschen: Length Function-ID R A OO E Seq-# Future-Use Dann könnt ihr euch die exakte Breite der Seq-# noch freihalten bis ihr das erste mal auf "future use" zurückgreifen müsst. Genaugenommen könnte dann auch der gesamte Block "future use" werden, also seq# + FU Zitieren
borg Geschrieben October 31, 2012 at 09:51 Autor Geschrieben October 31, 2012 at 09:51 Die Sequenz-Number würde schon genutzt werden von den Bindings und auch für das Routing (d.h. eine Antwort auf eine Anfrage mit einer gewissen Sequenz-Number muss wieder die gleiche Sequenz-Number haben). Dies sollte im Moment nicht notwendig sein, gibt aber natürlich nochmal zusätzliche Robustheit. Ansonsten ist es schon so gedacht, dass alles was in dem Byte steht wo die Sequenz-Number mit drin steht, bei Antworten gleich ist wie bei Anfragen. D.h. das ganze Byte kann fürs Routing verwendet werden. Daher die Unterscheidung zwischen "Options" (Bei einer Antwort auf eine Anfrage bleiben diese gleich) und "Flags" (können bei einer Antwort gesetzt werden, z.B. Errors). Wenn du so möchtest ist die Sequenz-Number etwas das optional von den Bindings genutzt werden kann. Die Bricks kümmern sich nicht um die Sequenz-Number und geben sie bei Antworten einfach wieder zurück. Zitieren
AuronX Geschrieben October 31, 2012 at 10:00 Geschrieben October 31, 2012 at 10:00 Ah clever! Das bringt mcih auf neue Fragen: 1. Wie werden eigentlich die Rückantworten addressiert? Ist der Empfänger dort die "1"? (geraten aufgrund connectedUID des Master) 2. Das heißt auch bei der Antwort auf eine Nachricht ist R gesetzt, richtig? Zitieren
borg Geschrieben October 31, 2012 at 10:05 Autor Geschrieben October 31, 2012 at 10:05 1. Wie werden eigentlich die Rückantworten addressiert? Ist der Empfänger dort die "1"? (geraten aufgrund connectedUID des Master) Die Rückantwort hat auch die Adresse des antwortenden. 2. Das heißt auch bei der Antwort auf eine Nachricht ist R gesetzt, richtig? Jop. Zitieren
AuronX Geschrieben October 31, 2012 at 10:18 Geschrieben October 31, 2012 at 10:18 Wenn das nicht zu weit geht: Wie funktioniert das? Also woher weiß ein weiterleitendes Brick in welche Richtung es das Paket schicken soll? (entweder in Richtung UID oder in Richtung "Wurzel") Zitieren
borg Geschrieben October 31, 2012 at 10:46 Autor Geschrieben October 31, 2012 at 10:46 Wenn das nicht zu weit geht: Wie funktioniert das? Also woher weiß ein weiterleitendes Brick in welche Richtung es das Paket schicken soll? (entweder in Richtung UID oder in Richtung "Wurzel") Das ist ganz einfach: Alles was vom USB, Ethernet, WIFI, RS485 Master, Chibi Master und SPI Master Interface kommt geht in Richtung UID. Alles was von SPI Slave, RS485 Slave, Chibi Slave und Bricklet Interface kommt geht Richtung Wurzel. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.