AuronX

Yes, any unreplied message with an expected response takes the system 2.5 Seconds ^^ The sequence numbers are just 4 Bits, so a map of Sequence number to Future would collide way too often for a reliable system.

Also wenn ein Paket eine UID enthält die zu einem Brick gehört, dann ist die zufälliger-Schrott-Wahrscheinlichkeit eher gering. (da würde die UID wohl kaum korrekt sein) Es ist aber bereits tatsächlich vorgekommen, dass neue Bindings an alten Bricks benutzt wurden. Das führte dann zu Nachfragen im Forum, die eine NotSupportedException vermieden hätte ^^

Sehr gut. Aber: Ich finde es generell schade, dass das Brick nicht mit Error antwortet, wenn man eine unbekannte Function-ID anfragt, sondern dies nur ignoriert. Daher zwei Ideen (sich gegenseitig ausschließend): 1. Neues Flag aus dem Future Use Pool: NotSupported Das Brick würde zumindest auf R-Pakete mit gesetztem Error- und Notsupported-Flag antworten, wenn es eine Funktion nicht kennt 2. Nutzung des Payload bei Error Bei gesetztem Error-Flag könnte man auch den Payload nutzen, um den Error zu präzisieren. Vorstellbar wäre ein int als error-code, wobei es globale Error-Codes (not-supported) und Brick-spezifische Errorcodes geben kann (z.B. "ungültige Servo-id" oder "ungültiger drehwinkel") Insbesondere wäre damit noch immer ein NotSupported möglich (wodurch kein Timeout bei unbekannten Gettern auftritt, sondern etwas sinnvolles) und der Mehrwert des E-Flag ließe sich weiter steigern (falls bei einem Aufruf mehr als ein Error auftreten kann)

Ich hätte vermutlich AddDevice gänzlich entfernt wenn es möglich wäre. Alternativ kann man ja auch das Brick mit der IPConnection erzeugen: new BrickServo("uid", ipcon) Die Device-Klasse könnte ja dann noch so etwas wie eine CheckDevice()-Methode o.ä. anbieten die man unabhängig vom hinzufügen (also potenziell auch regelmäßig/event-basiert) aufrufen kann. Also etwas das den von euch beschriebenen Test durchführt und per Rückgabe (bool/enum) o.ä. den Status meldet. Mögliche Rückgaben (enum-beispiel): OK, VERSION_MISMATCH, NO_RESPONSE andere Frage: Kann man den enumeration-aufruf (also nicht den Callback, sondern die Aufforderung zum Callback) per UID eingrenzen? Also statt zu fragen: "sagt mir alle wer ihr seid" zu rufen "Das Bricklet mit der UID x möge sich bitte im Kinderparadies melden"... Das wäre eine Möglichkeit die Anwesenheit eines speziellen Bricklets zu prüfen.

Ich habe überall Dezember gelesen fürs neue Protokoll ^^

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")

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?

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

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.

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

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?

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.

Ich habe keine Ahnung von diesem cmake-projekt, deswegen sollte photron oder so sich hier nochmal äußern. Von mir gibt es dennoch einen Versuch: Grundsätzlich kann so ein cmake-script aus verschiedenen CMakeLists.txt bestehen. Es wäre also möglich, dass du die falsche erwischt hast. Versuche am besten eine im root-verzeichnis des zip-files zu finden. Ansonsten finde ich es komisch, dass du sie im build-verzeichnis ablegen musstest. Ich kenne das nur so: Du hast eine Ordnerstruktur mit Quellcode (bei dir \software usw.) und legst dort einen build-ordner an. Jetzt gehst du in diesen build-ordner und rufst "cmake .." auf. Cmake legt jetzt alles zum kompilieren dort rein und du hast vorher nie etwas dort reingelegt. Aber vorsicht, das ist einfach nur so wie ich es kenne und das kann verdammt falsch sein Vielleicht wurdest du ja dennoch inspiriert ^^

Das sollte TF dann vielleicht nochmal klarstellen... Falls du es nicht inzwischen selbst rausgefunden hast: cmake ist dazu da, dass man auf mehreren Plattformen kompilieren kann, also cmake erzeugt dir am Ende deine Dateien zum bauen (z.B. makefiles unter linux oder csproj wenn du mit Visual Studio bauen möchtest). Aber ich glaube da du auf den GCC angewiesen bist wirst du wohl am besten auf makefiles zurückgreifen wollen ^^ Wenn du unter Linux arbeitest dann passt das, ansonsten kann es dir auch passieren, dass du dir noch make besorgen musst. Alles Dinge von denen ich übrigens keine tiefe Ahnung habe

cmake saugen, da kommst du denke ich nicht drum herum...

Also überall wo "clonen" steht müsste auch "kopieren" funktionieren... (kopieren ist ja git-frei ^^) Ich kann selbst auch nur raten, ich vermute im src-ordner muss dann das liegen was im bricklib-ordner war. Also wird aus Tinkerforge-bricklib-2b5c016/unterverzeichnis-oder-datei io4/software/src/unterverzeichnis-oder-datei Ist aber auch nur nach bestem Wissen und Gewissen geraten

na dann... *applaus*

Runterladen des Quellcodes sollte für dich äquivalent sein. Klonen bedeutet, dass du Git benutzt um an den Quellcode zu gelangen, das ist ein Versionsverwaltungssystem. Der Nutzen in Git liegt an zwei Stellen: - du kannst es auch für deinen Kram als Versionsverwaltung nutzen (vereinfacht: als Lösung zum Rückgängig machen von Änderungen und zum merken von funktionierenden Versionen) - du könntest das ganze zeug auf diese Weise auch wieder anderen zugänglich machen (z.B. via Github) Ist aber beides nciht zwingend nötig, insofern: ZIP ZIP!

Also ich würde den Stack definitiv über eine idiotensichere Variante anschließen. Das ist PoE (also das standardisierte PoE). Aber eh wir viel zu weit abdriften: Wo eine Ethernet-Extension, da auch ein Master-Brick, reicht es nicht wenn diese per USB versorgt wird? Denn USB-Netzteile schlagen vom Preis her sogar deinen Injektor: http://www.amazon.de/s?ie=UTF8&index=blended&keywords=usb%20netzteil

Glaube je langwelliger desto besser. Weil bei UV-Licht ist auch irgendwann Luft nicht mehr durchsichtig ^^

Was war gerade nochmal der Vorteil dieser Variante? Also abgesehen von den 7 Euro Anschaffungskosten.

Das meinte ich doch Ist ja auch nur meine Meinung, aber an eurer Stelle würde ich den alten Compiler nehmen wenn das hilft und keine anderen Schäden bringt (ist ja nur für ein paar Monate) edit: Wie inkompatibel ist das eigentlich? Also was passiert wenn ich es trotzdem tun würde?

Leider war ein Punkt dazwischen, also waren es zwei Sätze ^^ Dennoch habe ich auch ganz deutlich verstanden, dass borg gesagt hat, dass es zu Weihnachten eine Ethernet-Extension geben wird @borg: In wie großen Scheiben werden denn MAC-Adressblöcke verkauft? bzw. wie groß ist euer Raum?

@borg: Habe ich das richtig verstanden, dass das Bricks und bricklets zueinander inkompatibel machen würde (also 250er zu 256ern)? Falls ja würde ich das unter allen Umständen auf die Protokolländerung verschieben und das Problem bis dahin durch ein Compilerdowngrade beheben (wenn das hilft). Sonst habt ihr kurz hintereinander zwei inkompatible FW-Updates, obwohl eines (das beide inkompatibilitäten mitbringt) reichen würde. Falls alles kompatibel bleibt ignoriert was ich geschrieben habe.

@Nic: Ein Problem hat TF halt nur dann, wenn sich die stabile Version der FW die auf alle lagernden 4000 Bricklets aufgespielt wurde als fehlerhaft herausstellt. Ein Flashen beim Versenden wird vermutlich auch nicht möglich sein. Am Ende sollte der Bastler sich bewusst sein, dass er Bastelware in den Händen hält (deswegen ja auch Tinkerforge). Mein Handy ist keine Bastelware und ich wäre sehr böse, wenn dieses fehlerhaft geliefert wird @borg: danke für die Erläuterung. Wegen Weihnachten: Also je nachdem wie sehr Weihnachten einen Einfluss auf eure Verkaufszahlen hat würde ich das entweder deutlich vor oder nach Weihnachten machen (mit dem neuen Protokoll), aber nicht währenddessen Ich bin für nach Weihnachten, dann habt ihr unter dem Weihnachtsbaum noch Zeit für ausgiebige Integrationstests