Hallo,

 

ich möchte gerade nochmal versuchen die Dinge zusammenzutragen die derzeit nicht dokumentiert sind.

 

Auf der Seite der TCP/IP-Doku wären das:

• Die Disconnect-Probes der Bindings
  
• Die "forced-ACK" Pakete der WLAN-Extension
  

 

Was meiner Meinung nach bisher auch komisch läuft sind "spezielle" UIDs. In der Beschreibung zu enumerate (FID 254) schreibt ihr, dass die UID 0 für broadcast steht:

the UID in the packet header has to be set to 0 (broadcast).

 

Allerdings wird auch die disconnect-Probe an Adresse 0 verschickt. Das würde für mich bedeuten, dass das Paket jeden Teilnehmer im Stack erreichen und dieser es selbst ignorieren muss. Ich meine mich zu erinnern, dass das nicht so ist. Das führt aber dazu, dass UID 0 eben keine broadcast-adresse ist, sondern einfach nur die Function-ID 254 was besonderes wäre.

 

Ich fände es übrigens cool, wenn es eine echte Broadcast-Adresse gäbe und halt eine "wegwerf"-Adresse für Dinge wie Pings.

Allerdings wird auch die disconnect-Probe an Adresse 0 verschickt. Das würde für mich bedeuten, dass das Paket jeden Teilnehmer im Stack erreichen und dieser es selbst ignorieren muss.

 

Richtig, exakt so läuft das. Denn nur so ist das kompatible zu älteren Firmwares.

 

Die beiden genannten Dinge sind jetzt dokumentiert.

Ah okay, dachte der Master droppt das Paket sofort...

 

Eine Anmerkung hätte ich noch 

 

Genaugenommen betrifft die Disconnect-Probe alle Verbindungsarten, also nicht nur WiFi, weil sie auch bei der Verbindung zu einem Remote-Brickd sinnvoll ist. (Nicht jeder connected zu localhost)

 

Viele Grüße

Jan

Ich habe zwei weitere Dinge entdeckt (weil ich gerade selbst die Brick-Seite implementiere):

 

1. Es wird nicht klar dokumentiert, dass alle Callbacks die SequenceNumber 0 haben müssen. Es gibt einen Beispiel-Callback in der TCP-Doku, mir war aber erst durch lesen des Quellcode klar, dass Callbacks zwingend Sequence-Number 0 haben müssen. Der Zweck dessen ist mir ebenfalls nicht klar.

 

2. Wenn bei einem Setter ResponseExpected auf 1 gesetzt wird, was wird dann als Antwort erwartet? Eine exakte Kopie des Paketes? Oder nur der gleiche Paketheader mit leerem Payload?

Zu 1: Das ist dokumentiert im Packet Layout Abschnitt:

 

For callbacks the sequence number is always 0 and this value is not allowed for other packets. Non-callback packets can only use 1 - 15 as sequence number. This allows to distinguish callback packets from other packets.

 

Zu 2: Es reicht als Antwort ein Header.

 

Schreibst du einen Brick-Emulator auf TCP/IP Protokolllevel?

 

JavaLaurence hat einen Emulator auf dem Java-API-Level (begonnen?).

Zu 1: Das ist dokumentiert im Packet Layout Abschnitt

 

Verdammt. Das habe ich übersehen, sorry. Sogar mit Begründung

 

Schreibst du einen Brick-Emulator auf TCP/IP Protokolllevel?

 

Ganz genau. Ist eigentlich nur Spielerei, aber ich habe gerade Spaß daran gefunden Ich werde nochmal mehr dazu schreiben, wenn ich glaube, dass es für jemanden nützlich sein könnte.

 

Dass JavaLaurence was macht habe ich noch nciht mitbekommen, da muss ich glatt mal ins englische Forum wandern ^^

 

Vielen Dank

Jan

Ich bin mir fast sicher das schonmal gelesen zu haben, finde es aber in der einschlägigen Tabelle gerade nicht:

http://www.tinkerforge.com/de/doc/Software/Bricklets/Temperature_Bricklet_TCPIP.html#Temperature.set_temperature_callback_threshold

 

Beim Reached-Callback und den Optionen Inside und Outside:

 

Muss ich das als min < x < max oder als min <= x <= max lesen?

 

ich werde vermutlich gleich noch den Source-Code eines Bricklet dazu bemühen, aber es sollte auch dokumentiert sein (Falls ich nicht einfach nur blind bin).

Es ist min < x < max:

 

if(((BC->threshold_option[i] == 'o') &&
((value < BC->threshold_min[i]) ||
 (value > BC->threshold_max[i]))) ||
   ((BC->threshold_option[i] == 'i') &&
((value > BC->threshold_min[i]) &&
 (value < BC->threshold_max[i])))) {