borg

Protokoll 2.0 hat damit soweit erstmal nichts zu tun. Ich habe die Hoffnung, dass die neuen geschirmten Bricklet Kabel das Problem endgültig lösen. Falls diese nichts bringen, können wir da mit Hardware wohl nichts gegen unternehmen. Wir müssen dann wohl eine Firmware bauen mit der man zwischen den 100 und 400khz umstellen kann.

Prinzipiell geht das. Der Sensor gibt einen analogen Wert zurück und mit steigender Kabellänge fällt die Spannung und somit die Entfernungsmessung. Bei 50cm wirst du kaum einen Unterschied merken, bei 2m wird es sich bemerkbar machen.

Ja, also: bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); } vs bytes = read(sizeof(Header)); while(len(bytes) != (bytes[4] + sizeof(Header))) { bytes += read((bytes[4] + sizeof(Header)) - len(bytes)); }

I can't imagine a system where we ever return an answer for the same FID in a wrong sequence. I think we can safely add that to the spec. A Brick that returns responses to requests to two different Bricklets in a "wrong order" could however easily happen if we ever have a multicore Brick or add real threading to the Brick firmwares. However, the Bindings could implement the sequence number per FID and then the 4 bit would likely suffice again, even if we didn't guarantee the correct order for requests with the same FID. Implementing something like "Future Objects" as a general concept in all of our Bindings would be cool, but i really don't know if it is worth the effort. Especially if we consider that the first steps will get harder for someone that just starts to learn programing.

Da hast du natürlich recht. Dann würde ich vorschlagen wir machen aus dem einem Error Bit gleich zwei Error-Bits, dann können wir 4 Fehlerzustände zurückgeben: * 0 = OK * 1 = BAD_PARAMETERS (Index out of range or similar) * 2 = FUNCTION_NOT_SUPPORTED * 3 = TODO

Es mag den Fall geben, dass man ein "echtes" Paket mit einer nicht-existierenden Funktions ID bekommt. Ich denke aber dass es wahrscheinlicher ist, dass einfach irgendein Programm schrott auf den Port schreibt (absichtlich oder unabsichtlich). Da würde ich dann eigentlich nicht drauf antworten wollen. Zwischen Paketen mit falscher FID und "Schrottpaketen" kann ich aber nicht unterscheiden. Ich bin mir aber auch nicht zu 100% sicher was hier die beste Vorgehensweise wäre.

Die Idee bei den 4-20mA Sensoren ist ja gerade, dass man mitbekommen kann wenn der Sensor nicht angeschlossen oder defekt ist (da er dann 0mA zurück gibt). Also werden wir natürlich auch runter bis 0mA messen können, sonst hätten wir dieses Feature ja verschenkt. Ich denke die API wird (wie bei uns üblich) einfach wieder eine SI-Einheit zurückgeben. Vermutlich einfach den Messwert in µA.

Uns ist da gerade ein Implementierungsdetail aufgefallen, dass wir vorher noch nicht so genau bedacht hatten. Wenn wir das neue Protokoll durchziehen, so wie es bisher gedacht ist, ändert sich das verhalten beim add_device. Im Moment ist es ja so, dass ich mitbekommen wenn ein Brick/Bricklet nicht im System ist während ich add_device aufrufe. Nach der aktuellen Planung des neuen Protokolls wäre es so, dass add_device lediglich intern die UID speichert. D.h. ich würde dort erstmal nicht mitbekommen wenn ein Brick/Bricklet nicht da ist. Das hat aber noch mehr Konsequenzen: Im alten Protokoll wurde an der Stelle z.B. auch überprüft ob das hinzugefügte Bricklet überhaupt zum Objekt passt. Des weiteren wollten wir auf Dauer implementieren, dass dort die FW Version mit der Binding Version abgeglichen wird, um zu überprüfen ob Funktionen vorhanden sind oder nicht. Das würde natürlich alles wegfallen. Jetzt könnte man an der Stelle hergehen und wieder eine Funktion auf den Bricks implementieren die diese Informationen zurück gibt. Dann wäre an der Stelle wieder alles beim alten. Vorteil: * Überprüfung ob Brick/Bricklet vorhanden * Versionsüberprüfung Nachteil: * Wir haben wieder einen "Zustand" im System. Beispiele für den Nachteil: * Ich bekomme einen Fehler wenn ein Brick/Bricklet während des Hinzufügens kurzzeitig nicht erreichbar ist. * Wenn ich z.B. einen RS485 Slave Stack nehme und die Bricks/Bricklets in diesem aktualisiere und dann wieder an den RS485 Bus hänge, hat das Brick/Bricklet Objekt falsche Versionsnummern und neue Funktionalität ist im laufenden Programm nicht vorhanden. Was meint ihr dazu?

Mhh, ich weiß nicht. Du musst ja erstmal über den Socket die komplette length empfangen. An der Stelle muss ja eigentlich keine Konstante drauf. also ich denke an sowas wie (Pseudocode) bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); }

Arg! Werde doch mal ein bisschen präziser . Wie nah liegt es denn dran? Ist es nur 1-2° daneben oder weit daneben? Kannst du mal deine Kalibrierung anhängen?

Inwiefern passen sie nicht? Passt denn die Darstellung im Brick Viewer? Wenn nicht, sag mal ein Beispiel wo sie wie daneben liegt.

No. 2 meters will be the longest cable there too, at least available from us. For longer distances you just need a differential signal (like the RS485 Extension has).

Wie macht sich das denn bemerkbar? Hast du schonmal versucht das Magnetometer in deiner Umgebung zu kalibrieren?

Blog entry is ready: http://en.blog.tinkerforge.com/2012/11/5/introduction-of-industrial-bricklets

Damit sind wir im Prinzip wieder bei der Gehäusefrage. Wir brauchen auf Dauer einfach Gehäuse. Ich denke wenn wir Gehäuse anbieten, sollten diese auch für Ambient Light/Barometer/Humidity Bricklet benutzbar sein. Also im einfachsten Fall eine Art "Guckloch", wo man entweder ein Stück Glas oder ein Stück Schaumstoff o.ä. drauflegen kann?

I intend to write a longish intruduction blog entry regarding the Industrial Bricklets in our blog tomorrow morning (with availability dates).

Everything but the enumeration process should stay the same for someone that uses our bindings. It would (with the current and with the new protocol) be possible to implement Bindings that return a Future Object instead of the current blocking behavior. This would probably be quite hard to generate for some of the languages and it would likely be hard to understand for people that are just starting programming. If you want to try to implement something like that, your Bindings will need a queue for the Future Objects per function id. Answers to requests are guaranteed to come in the correct sequence. So you can add the data of the latest request to the current head of the queue and pop it. A newly generated Future Object will be put at the end of the queue, respectively. Does that make sense ?

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.

Die Rückantwort hat auch die Adresse des antwortenden. Jop.

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.

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 ! 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.

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. 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 .

Ö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 .

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.

Exakt richtig!