Loetkolben Geschrieben April 16, 2013 at 17:22 Share Geschrieben April 16, 2013 at 17:22 Hallo zusammen, ich habe hier zwei Temperaturbricklets. Einmal ueber USB Master einmal ueber WLAN Master angesprochen: Antwort vom USB Master2.0 FW 2.0.6 mit 10 Byte. OK. Send: "bQL" \x74\x8e\x00\x00\x08\x01\x18\x00 Receive: hexdump -C paket.USB.temp0 00000000 74 8e 00 00 0a 01 18 00 40 09 |t.......@.| 0000000a Antwort vom WLAN Master1.0 FW 2.0.6 mit 146 Byte. :'( Send: "aJY" \x00\x80\x00\x00\x08\x01\x18\x00 Receive: hexdump -C paket.WLAN.temp0 00000000 32 21 75 c4 22 fd 08 00 36 32 66 56 37 33 00 00 |2!u."...62fV73..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 61 4a 59 00 00 00 |......"...aJY...| 00000030 00 00 36 32 66 56 37 33 00 00 61 01 01 00 02 00 |..62fV73..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 61 75 53 00 |.....|.."...auS.| 00000050 00 00 00 00 36 32 66 56 37 33 00 00 62 01 01 00 |....62fV73..b...| 00000060 02 00 00 15 00 01 8e 83 00 00 22 fd 08 00 62 31 |.........."...b1| 00000070 45 00 00 00 00 00 36 32 66 56 37 33 00 00 63 01 |E.....62fV73..c.| 00000080 01 00 02 00 00 1b 00 01 00 80 00 00 0a 01 18 00 |................| <-- 10 Byte Daten hier 00000090 53 0a |S.| Kann mir das einer erklaeren? Im Brickviewer 2.0.4 ist alles ok. Wo habe ich den Fehler gemacht, bzw. warum reagieren die beiden Stacktypen unterschiedlich? Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 16, 2013 at 17:36 Autor Share Geschrieben April 16, 2013 at 17:36 Im Moment kommt dieser "Kaese" raus. Im obigen Beispiel waren die letzten 10 Byte die Nutzdaten, hier sind sie mitten im Paket. :'( cat paket.WLAN.temp0 | hexdump -C 00000000 32 21 75 c4 22 fd 08 00 36 32 66 56 37 33 00 00 |2!u."...62fV73..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 61 4a 59 00 00 00 |......"...aJY...| 00000030 00 00 36 32 66 56 37 33 00 00 61 01 01 00 02 00 |..62fV73..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 61 75 53 00 |.....|.."...auS.| 00000050 00 00 00 00 36 32 66 56 37 33 00 00 62 01 01 00 |....62fV73..b...| 00000060 02 00 00 15 00 01 00 80 00 00 0a 01 18 00 47 0a |..............G.| <-- 10 Byte Daten hier 00000070 8e 83 00 00 22 fd 08 00 62 31 45 00 00 00 00 00 |...."...b1E.....| 00000080 36 32 66 56 37 33 00 00 63 01 01 00 02 00 00 1b |62fV73..c.......| 00000090 00 01 |..| 00000092 Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 16, 2013 at 17:37 Share Geschrieben April 16, 2013 at 17:37 In deiner Antwort scheinen schonmal mehrere Pakete zu stecken. Das fünfte Byte deines dump hat als Wert 2216 = 3410. Das bedeutet das erste Paket ist 34 Byte lang. Die Function-ID der ersten Antwort ist 253, da konnte ich auf die Schnelle nicht finden was das ist. Aber offenbar nicht die Antwort auf das von dir verschickte Paket. Denke das ist wieder ein Fall für den Doku-Doktor. edit: Tatsächlich stellte sich heraus, dass das Verhalten wie dokumentiert war (siehe unten). Vermutlich sollte es für deinen Anwendungsfall aber auch so etwas wie Shell-Bindings geben. Binding ist da natürlich nicht das richtige Wort, aber am Ende ein Tool das ich irgendwie so (oder so ähnlich) nutzen kann: > tinker bricklet-temperature myU1D temperature 21.34 edit: Dieser Post bezieht sich auf deinen ersten Dump Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 16, 2013 at 17:55 Share Geschrieben April 16, 2013 at 17:55 Könntest du die jeweiligen Dumps nochmal als binärdatei (dateiendung ist mir egal ^^) anhängen? Würde die gerne mal durch ein Tool von mir jagen, um den Paketinhalt selbst lesen zu können ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 16, 2013 at 17:56 Autor Share Geschrieben April 16, 2013 at 17:56 Hallo AuronX, danke fuer die schnelle Antwort! Ich baue mir gerade wieder selbst die Shellscripte. Nachdem die Huerde von base58 genommen wurde dachte ich eigentlich ich waere "durch". Ich koennte eigentlich damit leben wenn sich USB und WLAN nicht unterscheiden wuerden. Mal sehen was die Erfinder von Protokoll v2 sagen. :grpf: Edit: @AuronX: Habe ich gemacht. Wie beschrieben kommt das WLAN Paket sogar in 2 Versionen an. Mal so, mal so. Die 10 Bytes "00 80 00 00 0a 01 18 00 47 0a" verstecken dann an unterschiedlichen Stellen innerhalb der 146 Bytes. (Leider nicht im Forumcode markierbar) Der Loetkolbentempv2.tar Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 16, 2013 at 18:11 Share Geschrieben April 16, 2013 at 18:11 Habe grad den ersten Dump geparsed: Packet("62fV73" fn: 253 seq: 0 resp: True err: 0)[34] Packet("SpzBW" fn: 8 seq: 0 resp: False err: 1)[253] der zweite sieht genauso aus... Was du hier siehst ist aber nur der Inhalt der Paket-Header, die Payloads werte ich nicht aus. Kannst du die beiden UIDs deinen Bricks/Bricklets zuordnen? Das zweite Paket scheint jeweils ein sehr langes Fehlerpaket zu sein... Der Error-Code 1 beim zweiten Paket sagt laut Doku "Invalid Parameter" Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 16, 2013 at 18:24 Autor Share Geschrieben April 16, 2013 at 18:24 Hallo AuronX, das "zweite" Paket muss aus mehreren Paket bestehen, denn man kann eindeutig die 10 Bytes erkennen die erwartet wurden! "00 80 00 00 0a 01 18 00 47 0a" "47 0a" sind die Temperaturwerte und somit "schwankend" Wenn man sich mal optisch den ASCII Dump ansieht so kommt oefters die Masterbrick ID "62fV73" vor. Ich denke das es 8 Pakete sind?! Ausserdem sind alle IDs der Bricklets vorhanden. Kann es sein, dass es sich um einen Enumerationsrespond handelt? [size=8pt]cat paket.WLAN.temp0 | hexdump -C 00000000 32 21 75 c4 22 fd 08 00 [color=red]36 32 66 56 37 33 [/color]00 00 |2!u."...[color=red]62fV73[/color]..| 00000010 30 00 00 00 00 00 00 00 30 01 00 00 02 00 06 0d |0.......0.......| 00000020 00 01 00 80 00 00 22 fd 08 00 [color=green]61 4a 59[/color] 00 00 00 |......"...[color=green]aJY[/color]...| 00000030 00 00 [color=red]36 32 66 56 37 33[/color] 00 00 61 01 01 00 02 00 |..[color=red]62fV73[/color]..a.....| 00000040 01 d8 00 01 ce 7c 00 00 22 fd 08 00 [color=green]61 75 53[/color] 00 |.....|.."...[color=green]auS[/color].| 00000050 00 00 00 00 [color=red]36 32 66 56 37 33[/color] 00 00 62 01 01 00 |....[color=red]62fV73[/color]..b...| 00000060 02 00 00 15 00 01 [color=blue]00 80 00 00 0a 01 18 00 47 0a[/color] |..............G.| 00000070 8e 83 00 00 22 fd 08 00 [color=green]62 31 45[/color] 00 00 00 00 00 |...."...[color=green]b1E[/color].....| 00000080 [color=red]36 32 66 56 37 33[/color] 00 00 63 01 01 00 02 00 00 1b |[color=red]62fV73[/color]..c.......| 00000090 00 01 |..| 00000092[/size] Blau = Das erwartete Paket. Anbei die Stack IDs per Screenshot aus dem Brickviewer. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 16, 2013 at 18:30 Share Geschrieben April 16, 2013 at 18:30 Oh, dummer Fehler von mir ^^ Hatte nen off-by-one-Fehler in meinem kleinen Programm. Das (korrekte) Ergebnis vom zweiten deiner Dumps: Packet("62fV73" fn: 253 seq: 0 resp: True err: 0)[34] Packet("aJY" fn: 253 seq: 0 resp: True err: 0)[34] Packet("auS" fn: 253 seq: 0 resp: True err: 0)[34] Packet("aJY" fn: 1 seq: 1 resp: True err: 0)[10] Packet("b1E" fn: 253 seq: 0 resp: True err: 0)[34] Deine Vermutung mit der Enumeration scheint also korrekt zu sein Ich wusste nur nicht, dass der Callback auch ohne Aufforderung versendet wird. (edit:) Aber tatsächlich ist genau dieses Verhalten dokumentiert... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 16, 2013 at 18:36 Autor Share Geschrieben April 16, 2013 at 18:36 Hallo AuronX, danke fuer die Antwort. Das sieht ja richtig "Zivil" aus. Kann mir aber einer sagen was ich damit machen soll? Ich habe keine Enumeration bestellt. Wenn jetzt das erwartete Anwortpaket immer an der gleichen Stelle stehen wuerde koennte man es mit Shellbefehlen einfach ausschneiden. Bei diesem Bytesalat, wo auch die Paketreihenfolge zufaelligt ist, muss vielleicht doch Dr. Tinkerforge ran. Vielleicht hat er ja was von Tinkerpharm. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 16, 2013 at 18:48 Share Geschrieben April 16, 2013 at 18:48 Jop... du müsstest jetzt alle Pakete einzeln parsen, bis du das Paket mit der richtigen Function-ID findest. Oder Onkel TF ganz lieb um hübsche Shell-Bindings bitten Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 16, 2013 at 18:57 Autor Share Geschrieben April 16, 2013 at 18:57 Oder Onkel TF ganz lieb um hübsche Shell-Bindings bitten Ich hab auch meinen Stolz! Nachdem ich nun alles hinbekommen habe moechte ich es auch einsetzen. Ich versuche es mal so: Hallo Onkel TF. :wink: Koenntest du dem WLAN Stack bitte sagen, dass er sich wie ein USB Stack verhalten soll und generell spontane Callbacks nicht mehr zulassen. Danke. :winkewinke: Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben April 17, 2013 at 07:43 Share Geschrieben April 17, 2013 at 07:43 Was du da im WIFI Fall siehst sind Enumerate Callbacks mit ENUMERATION_TYPE_CONNECTED. Diese sendet der Stack von sich aus wenn eine neu Verbindung aufgebaut wurde. Dies erlaubt es neustartende Stacks zu erkennen. Im Fall von USB siehst du diese nicht, da die USB Verbindung zwischen brickd und Stack schon längst besteht und auch durchgehend besteht. Bei WIFI stellst du direkt die Verbindung her und siehst daher die Enumerate Callbacks. Soll heißen, du kannst dich nicht darauf verlassen, dass die Daten die nach Absenden eines Request auch direkt die Antwort darauf sind. Auch kann es sein, dass du mehrere unserer Pakete in einem TCP/IP Paket bekommst. "Shell Bindings" stehen schon eine Weile auf der TODO Liste. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 17, 2013 at 09:44 Autor Share Geschrieben April 17, 2013 at 09:44 Was du da im WIFI Fall siehst sind Enumerate Callbacks mit ENUMERATION_TYPE_CONNECTED. Diese sendet der Stack von sich aus wenn eine neu Verbindung aufgebaut wurde. Dies erlaubt es neustartende Stacks zu erkennen. Hmm, zum einen habe ich aber keine "Enumerate Callbacks" bestellt und zum anderen kommen die ungeordnet. Das erwartete Paket ist dann mitten im "Enumerate Callback" Salat Wo kann ich diese "Enumerate Callbacks" abstellen? Wie soll ich damit erkennen, dass der Stack neu gestartet hat. Irgendwie kommen diese "Enumerate Callbacks" immer! Soll heißen, du kannst dich nicht darauf verlassen, dass die Daten die nach Absenden eines Request auch direkt die Antwort darauf sind. Auch kann es sein, dass du mehrere unserer Pakete in einem TCP/IP Paket bekommst. Ohhhhh, solche Aussagen wie "nicht darauf verlassen" finde ich in der IT Welt hoechst bedenklich. Dann schaltet doch diese Antworten aus. Mir reicht es, dass ich entweder eine Antwort bekomme oder nicht. Dann weiss ich wenigstens dass der Stack nicht erreichbar ist. Ob er rebootet hat oder neu gestartet ist kann ich doch auch per "Get" abfragen. Ich bin der Meinung, dass hier eine Loesung gefunden werden muss, damit der Stack nicht irgendwann irgenwas zurueckschickt womit keiner rechnet! Das ist dann mehr eine Daten-Lotterie als eine Programmierung. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 17, 2013 at 09:57 Share Geschrieben April 17, 2013 at 09:57 Im Fall der Sortierung muss ich TF in Schutz nehmen. Wir reden hier vom Low-Level-Protokoll. Wenn dort spezifiziert ist, dass die Daten ungeordnet ankommen können, dann ist das okay und durchaus üblich (auch in der IT-Welt; siehe UDP und warum es überhaupt TCP gibt). Der "Sonderfall" bei dir ist ja, dass du immer die Verbindung aufbaust um genau eine Frage zu stellen und dann die Verbindung wieder abbaust. Üblicherweise bestehen Verbindungen länger, zumindest ist das Protokoll darauf ausgelegt und optimiert. Ob es nun wirklich nötig ist den connected-callback bei Verbindung per WLAN loszuschicken weiß ich nicht. Konsequenterweise sollte zumindest der brickd dann das gleiche tun (von mir aus durch caching) wenn ich mich zu ihm verbinde oder niemand sollte es tun. Auf jeden Fall denke ich sollte sich das Verhalten zwischen USB und WiFi nicht unterscheiden. @Loeti: Eine Notlösung falls es nicht auf enorme geschwindigkeit ankommt: Verbindung aufbauen, abwarten bis nix mehr kommt*, Anfrage schicken, Antwort lesen. * "bis nichts mehr kommt" ist abhängig von der Stackgröße und Konfiguration, aber ich denke 2 Sekunden sollten halbwegs sicher sein @TF: Unter Umständen wäre beim Low-Level-Protokoll eine RFC-artige schreibweise besser geeignet. Also insbesondere sollte überall die Unterscheidung zwischen MUST, SHOULD, MUST NOT usw. getroffen werden. Das setzt natürlich eine vollständige Spezifikation vorraus, an diese müssten sich dann auch eure Bricks penibel halten. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 17, 2013 at 10:11 Autor Share Geschrieben April 17, 2013 at 10:11 Hallo AuronX. Der "Sonderfall" bei dir ist ja, dass du immer die Verbindung aufbaust um genau eine Frage zu stellen und dann die Verbindung wieder abbaust. Üblicherweise bestehen Verbindungen länger, zumindest ist das Protokoll darauf ausgelegt und optimiert. Hier spricht die Wetterstationsabteilung, die Stacks quer durchs Land verteilt hat. Dies ist kein Sonderfall, sondern der Normalfall. Alle 10 Minuten Verbindung aufbauen, Daten holen und abbauen. Fertig. Weiss der Geier was auf 1000 km und bei 20 Carriern alles sonst dazwischen kommen kann. Ob es nun wirklich nötig ist den connected-callback bei Verbindung per WLAN loszuschicken weiß ich nicht. [...] Auf jeden Fall denke ich sollte sich das Verhalten zwischen USB und WLAN nicht unterscheiden. Von mir aus kann man so ein Verhalten in den WiFi Setting aktivieren. Auf jeden Fall sollten sich die Stacks (USB oder WLAN) NICHT unterscheiden!!! @Loeti: Eine Notlösung falls es nicht auf enorme geschwindigkeit ankommt: Verbindung aufbauen, abwarten bis nix mehr kommt*, Anfrage schicken, Antwort lesen. Ob das mit dem "nc" Befehl geht weiss ich nicht. Der handelt den Auf- und Abbau automatisch. Das ist richtig praktisch. Eine alternative waere anstelle eines WLAN Stacks ein Raspberry PI mit WLAN zu nehmen. Kostet genauso viel, hat mehr Moeglichkeiten, aber sieht nicht so huebsch aus. Ich wuerde mich freuen wenn Tinkerforge sich nochmals hinhocken und ueber eine Loesung nachdenken wuerden die allen Gerecht wuerde. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben April 17, 2013 at 10:17 Share Geschrieben April 17, 2013 at 10:17 Von mir aus kann man so ein Verhalten in den WiFi Setting aktivieren. Auf jeden Fall sollten sich die Stacks (USB oder WLAN) NICHT unterscheiden!!! Sie verhalten sich gleich. Starte einen Brick Daemon, verbinde dich darauf und steck dann das Brick per USB an -> Du bekommst ein Enumerate. Das gleiche passiert bei der WIFI Extension: Wenn du dich mit der WIFI Extension das erste mal verbindest ist das äquivalent zum einstecken per USB. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 17, 2013 at 10:23 Share Geschrieben April 17, 2013 at 10:23 Borg da kann ich dir nicht recht geben. Das Einstecken per USB führt zum Starten des Stacks. Der war vorher stromlos und jetzt ist er da. Bei WLAN kann der Stack seit Jahren laufen und trotzdem kriege ich immer einen Callback als wäre er jetzt gestartet und einsatzbereit. Das ist nicht das gleiche, auch wenn man gleichheit immer anders definieren kann. Wenn du sagst es ist absolut notwendig, dass die WLAN-Extension immer den enumerate-callback auslöst, dann sollte dieser Luxus auch jedem vergönnt sein der sich zu einem brickd verbindet. Ansonsten macht das euer Plug & Play Konzept kaputt! Die Behauptung stand ja im Raum, dass ich nicht wissen muss ob ich mich zu einem brickd verbinde oder zu einer WLAN-Extension, das sollte transparent sein. De facto ist es aber nicht transparent, weil ich beim einen das enumerate auslösen muss und beim anderen nicht. und das obwohl beide Stacks schon seit Stunden am Strom hängen. Ich denke aber die Lösung für Loeti sind weiterhin einfach Shell-Bindings. Wenn ich das richtig sehe, bist du ja darauf aus ein simples "high-level" Konzept zur Verfügung zu haben. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben April 17, 2013 at 10:25 Share Geschrieben April 17, 2013 at 10:25 Da kann ich dir nicht zustimmen . Der Source Code ist ja an der Stelle für beide gleich. Eine Enumeration wird losgeschickt wenn das erste mal eine Verbindung zum PC aufgebaut wird. Da wird nicht zwischen Wi-Fi und USB unterschieden. Das in einem Fall der Stapel schon bestromt ist und im anderen nicht hat damit gar nichts zu tun. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 17, 2013 at 10:29 Autor Share Geschrieben April 17, 2013 at 10:29 Hallo borg. Sie verhalten sich gleich. Und wieso bekomme ich dann mit dem identischen Programm unterschiedlich Antworten? :denknach: So identisch koennen sie dann nicht sein. Du beschreibst Sonderfaelle. Da mag das identisch sein. Wer verbindet sich schon zu einem USB Brickd und steckt dann den Stack an? Der Normalfall sollte doch so sein, dass man eine Verbindung aufbaut, Daten abholt und wieder abbaut. In diesem Fall gibt es eben die Unterschiede. Beim USB Stack wird ein "Enumerate Callback" gesendet wenn der Stack per USB angeschlossen wird. Beim WLAN Stack wird ein "Enumerate Callback" gesendet wenn der Brickd angesprochen wird. Was ist daran identisch? Ich verstehe es nicht. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben April 17, 2013 at 10:31 Share Geschrieben April 17, 2013 at 10:31 Beim USB Stack wird ein "Enumerate Callback" gesendet wenn der Stack per USB angeschlossen wird. Beim WLAN Stack wird ein "Enumerate Callback" gesendet wenn der Brickd angesprochen wird. Was ist daran identisch? Ich verstehe es nicht. Eine Enumeration wird gesendet wenn das erste mal eine Verbindung zum PC aufgebaut wird. Unabhängig vom verwendeten Interface. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 17, 2013 at 10:33 Share Geschrieben April 17, 2013 at 10:33 Du weißt ja, dass ich jeweils nur aus Sicht der Bindings blicke. Das ist für mich der relevante Teil des Protokolls. Die Bindings bauen eine TCP-Verbindung zu einer unbekannten Gegenstelle auf. Bei Einführung der WLAN-Extension hieß es sogar man müsse existierenden Source nicht anpassen, alles bleibt gleich, nur die IP wird anders. Nun stellt es sich aus Sicht der Bindings (= TCP-Client) so dar: Falls die Gegenstelle ein Software-Brickd ist, dann passiert nichts Falls die Gegenstelle eine WLAN-Extension ist, dann kommt ein enumerate Natürlich kann ich einfach immer nach enum fragen, aber das Verhalten stellt sich mir anders dar. Ich denke der Punkt auf den du hinauswillst ist der: In der Brick-Firmware ist beides das gleiche Ereignis, weil die Firmware das nicht unterscheiden kann. Aus Protokollsicht (und mit Protokoll meine ich den TCP-Transport) hat ein Verbindungsaufbau nichts mit dem Einstecken von Kabeln zu tun. Am Ende sitzt ihr (TF) auf der Entscheidungsseite. Aber bitte versteht, dass das nicht unbedingt intuitives Verhalten ist, wenn man niemals Kontakt zur Firmware-Seite hat. Ich für meinen Teil halte es noch immer für richtiger das Verhalten auf dem Transport-Protokoll konsistent zu halten. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 17, 2013 at 10:33 Autor Share Geschrieben April 17, 2013 at 10:33 Eine Enumeration wird losgeschickt wenn das erste mal eine Verbindung zum PC aufgebaut wird. Da wird nicht zwischen Wi-Fi und USB unterschieden. Ich baue doch die Verbindung beim USB Stack jedes mal wieder ab, aber bekomme das Paket nicht immer wieder. Wer ist hier "der PC". Auch wenn nicht unterschieden wird, kommt was unterschiedliches raus. Der Loetkolben Edit: Macht es einstellbar und alle sind gluecklich. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben April 17, 2013 at 10:40 Share Geschrieben April 17, 2013 at 10:40 Ich baue doch die Verbindung beim USB Stack jedes mal wieder ab, aber bekomme das Paket nicht immer wieder. Wer ist hier "der PC". Naja der PC ist Brickd in dem Fall. Wir können in der Firmware nicht feststellen wenn du dich bei Brickd abmeldest und neu verbindest, dort bekommen wir das nicht mit. Die einzige Möglichkeit das konsistent zu machen wäre gar kein Enumeration rauszuschicken. Das würde allerdings das Routing erheblich erschweren. Beispiel: Du verbindest ganz viele Bricks per USB an den PC und sendest dann ganz viele Setter um auf den Bricks irgendwas zu setzen. Wenn wir kein initiales Enumerate schicken würden, könnte der Brickd nicht wissen wo die Setter hin müssen und er müsste Broadcasten. Dann hätte man "transparenteres" verhalten, aber unterschiedliche Performance je nachdem wie das kontrollierende Programm aussieht... Ich befürchte das Protokoll und das Enumeration Verhalten machen an dieser Stelle so wie sie sind am meisten Sinn. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben April 17, 2013 at 10:48 Share Geschrieben April 17, 2013 at 10:48 Zwei Ansätze: 1. Der brickd bittet beim Anstecken des Kabels selbst um ein enumerate 2. Der brickd "merkt" sich die Devices und schickt bei jeder TCP-Verbindung ein Fake-enum raus. Mir geht es im Moment auch weniger darum euch davon zu überzeugen, dass ihr (TF) die eine oder die andere Lösung wählen sollt. Wichtig ist mir nur, dass klar nachvollziehbar ist wie das zu erwartende Verhalten an der Schnittstelle zu eurer Hardware ist. Nach allen bisher gängigen APIs die ihr habt ist diese Schnittstelle nunmal das TCP-Protokoll. Das heißt hier muss es dokumentiert werden. Wenn ihr am Ende feststellt, dass es sich unterschiedlich verhalten muss, dann sollte das wenigstens deutlich dokumentiert sein. Ist halt alles nicht so einfach wenn Menschen aufeinander treffen. Für euch ist die logische Schnittstelle der Stecker des Bricks. Für die meisten hier liegt die Schnittstelle aber erst am TCP-Socket. Viele Grüße Jan Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben April 17, 2013 at 12:12 Autor Share Geschrieben April 17, 2013 at 12:12 Wir können in der Firmware nicht feststellen wenn du dich bei Brickd abmeldest und neu verbindest, dort bekommen wir das nicht mit. Dann muss der Brickd mal mit der BrickFW reden. Die einzige Möglichkeit das konsistent zu machen wäre gar kein Enumeration rauszuschicken. Das würde allerdings das Routing erheblich erschweren. Fuer mich waere das die beste Loesung, aber ich verstehe, dass man auch auf die anderen Belange Ruecksicht nehmen muss. Das ist schon ok. Die BrickFW kann es ja rauschicken, aber der brickd muss es doch nicht weiterschicken. Beispiel: Du verbindest ganz viele Bricks per USB an den PC und sendest dann ganz viele Setter um auf den Bricks irgendwas zu setzen. Wenn wir kein initiales Enumerate schicken würden, könnte der Brickd nicht wissen wo die Setter hin müssen und er müsste Broadcasten. Ja das verstehe ich, aber warum kann der brickd es nicht fuer sich behalten und muss es in Welt hinauspusten? Ich befürchte das Protokoll und das Enumeration Verhalten machen an dieser Stelle so wie sie sind am meisten Sinn. Was ist der Sinn dass der brickd mir die Infos schickt? Ich brauch sie nicht. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
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.