Nomenklatur für Brick/let-Namen und StackID?

Moin moin,

habt Ihr eine Nomenklatur für die Vergabe von Namen und/oder UID von Bricks und Bricklets festgelegt? Oder wie kann ich erfahren, was hinter einer ID/einem Namen für eine Funktion steckt? Eine FunktionsID habe ich noch nicht finden können. Also müßte ich, wenn ich etwas über die Funktionen im System erfahren möchte, die Namen parsen. Doch dafür wäre es sehr hilfreich, wenn man wüßte, daß sich ein bereits eingeführter Text (Stepper, Voltage, ...) nicht mehr ändert. Bekomme ich Eigenschaften ohne Vorkenntnisse über eine Systemkomponente von dieser (auch gern auf Anfrage) mitgeteilt?

Eine ähnliche Frage stellt sich bei der StackID: Die Antworten der Brick/lets kommen dem Anschein nach ohne besondere Reihenfolge. Es scheint so, als ob die StackID hochzählen und von der Strucktur her mit einem Brick beginnen, dann erst die daran angeschlossenen Bricklets in der StackID-Reihenfolge erscheinen und erst dann der nächste Brick kommt. Erfährt man, welches Bricklet an welchem Port angeschlossen ist? Die Klärung der Fragen ist interessant, wenn man ein System grafisch dem Nutzer veranschaulichen möchte und man nichts über das System weiß.

Kann man irgendwie die Anwesenheit des Stepdown-Moduls erfahren? Ich konnte nichts dazu finden.

gruss uwet

Moin moin,

habt Ihr eine Nomenklatur für die Vergabe von Namen und/oder UID von Bricks und Bricklets festgelegt? Oder wie kann ich erfahren, was hinter einer ID/einem Namen für eine Funktion steckt? Eine FunktionsID habe ich noch nicht finden können. Also müßte ich, wenn ich etwas über die Funktionen im System erfahren möchte, die Namen parsen. Doch dafür wäre es sehr hilfreich, wenn man wüßte, daß sich ein bereits eingeführter Text (Stepper, Voltage, ...) nicht mehr ändert. Bekomme ich Eigenschaften ohne Vorkenntnisse über eine Systemkomponente von dieser (auch gern auf Anfrage) mitgeteilt?

Die ganzen Bindings sind komplett autogeneriert und die Konfigurationsdateien wo die Informationen für die Generierung herstammen findest du hier:

https://github.com/Tinkerforge/generators/tree/master/configs

für den Stepper Brick z.B. hier:

https://github.com/Tinkerforge/generators/blob/master/configs/brick_stepper_config.py

Eine ähnliche Frage stellt sich bei der StackID: Die Antworten der Brick/lets kommen dem Anschein nach ohne besondere Reihenfolge. Es scheint so, als ob die StackID hochzählen und von der Strucktur her mit einem Brick beginnen, dann erst die daran angeschlossenen Bricklets in der StackID-Reihenfolge erscheinen und erst dann der nächste Brick kommt. Erfährt man, welches Bricklet an welchem Port angeschlossen ist? Die Klärung der Fragen ist interessant, wenn man ein System grafisch dem Nutzer veranschaulichen möchte und man nichts über das System weiß.t

Mhhh, das ist im Moment leider nicht möglich. Die Informationen sind auf dem Master Brick alleine leider auch nicht alle vorhanden. Der Master könnte einer Stack ID den Platz in der Platine zuweisen (z.B. dritte Platine von unten). Alle Bricks könnten einer Stack ID von einem Bricklet den Port zuweisen.

Stellt sich natürlich die Frage wie man dafür eine vernünftige API macht, muss ich mal drüber nachdenken.

Kurz zur Erklärung:

Der Master enumeriert sich erst selbst durch (seine Bricklets). Dann enumeriert er alle Stack Teilnehmer durch (und übergibt als startende Stack ID die momentan höchste Stack ID). Dann enumeriert er alle Extension Teilnehmer durch. Der Master der Extension seinen Stack schon enumeriert und es wird nur noch ein Offset in der ID übertragen.

Wenn nun eine Nachricht mit Stack ID x ankommt, weiß der Master der per USB angeschlossen ist genau wo die hin muss (z.B an die Extension oder an den Stack Teilnehmer Nummer y). Er weiß aber nicht was es für ein Typ ist oder an welchem Port ein Bricklet sitzt o.ä.

Kann man irgendwie die Anwesenheit des Stepdown-Moduls erfahren? Ich konnte nichts dazu finden.

gruss uwet

Da haben wir elektronisch keinen "Detection Pin" o.ä., das einzige was du machen kannst ist GetVoltage auf dem Master aufrufen. Wenn die Spannung ungleich 0 ist, ist eine Step-Down Powersupply da.

Ich glaube, ich habe mich noch nicht verständlich genug ausgedrückt, was die Nomenklatur angeht. Ich möchte gerne wissen, ob ihr für Vergabe der Namen für Module eine Namenskonvention in z.B. Stepper.Name festgelegt habt. Siehe "Stepper Brick 1.0" oder "IO-16 Bricklet 1.0". Gibt es eine bestimmte Struktur, die man parsen und aus dem Ergebnis genau auf ein Gerät schließen könnte? Wie würde der Name für ein I/O16-Modul mit galvanischer Trennung heißen? Und sollte das IR-Modul nicht "Distance-IR Bricklet 1.0" statt "Distance IR Bricklet 1.0" heißen? Es könnte ja auch ein "Distance-Laser Bricklet 1.0" geben. Oder ein "LED-Rot Bricklet 1.0", "LED-Blau Bricklet 1.0", ... Dann könnte man wenigstens auf Leerzeichen parsen. Und eben so weiter.

Oder kann man nicht in den Namen eine ID einbauen, die für diese Baugruppe einzigartig ist? Z.B. Master-Brick 0x00010101 (Bit 31..24 Reserve,Bit 23..16 FunktionsID, Bit 15..8 VariantenID, Bit 7..0 RevisionID) oder so ähnlich. "LED-Rot Bricklet 1.0" könnte dann 0x000a0101 und "LED-Blau Bricklet 1.0" 0x000a0201 sein.

gruss uwet

Ah, verstehe.

Mhhh. Also grundsätzlich solltest du es folgendermaßen Parsen können (Pseudocode):

liste = name.split(" ")
version = liste.last(); liste.remove_last()
type = liste.last(); liste.remove_last()
name = liste.join()

Sprich: Am Ende steht der Name, davor kommt der Typ (mit Leerstelle getrennt), dann kommt der Name (zwischen Typ und Name auch mit Leerstelle getrennt, aber der Name selber kann Leerstellen enthalten).

Aber: An der Stelle gibt es folgendes zu beachten: Die Versionsnummer ändert sich nur wenn die Hardware inkompatibel geworden ist.

D.h. auch bei den ganzen neuen 1.1 Hardwareversion wird dort 1.0 stehen. D.h. du kannst damit nicht herausfinden ob die Platinen glänzend oder Matt sind (was der Unterschied zwischen Stepper Brick 1.1 und 1.0 ist).

Ich hoffe das macht irgendwie Sinn. Wir wollen eigentlich nicht 1000 unterschiedliche Firmwares machen für Hardware die die gleiche Schaltung hat.

okay, aber dann ist "Distance 16" definitiv außerhalb dieser Namenskonvention, da ich mit dem dritten Parsen nur die "16" geliefert bekäme und Ausnahmebehandlungen vorsehen müßte. Ohne euch das jetzt aufdrängen zu wollen, aber eine FunktionsID hätte schon gewisse Vorteile.

gruss uwet

"Distance 16"? Du meinst "Distance IR Bricklet 1.0"? Das kannst du doch genauso parsen. Alles nach der ersten Leerstelle von rechts ist die Version, alles vor der zweiten Leerstelle von links ist der Name und das was überbleibt ist der Typ.

Mir ist aufgefallen, dass das Temperature IR Bricklet von Get_Stack_ID als "Temperature-IR Bricklet x.x" bezeichnet wird. Ist das so gewollt oder nur Zufall? Bin darüber gestolpert da ich davon ausgegangen bin, dass die Namen genau wie in der Dokumentation sind.

Beantworte meine Frage mal selbst:

if i < 0 or name[0:i].replace('-', ' ') != self.add_dev.expected_name.replace('-', ' '):

Wird separat behandelt in den Bindings also so gewollt/bekannt.

"Temperature-IR" mir Bindestrich ist noch ein altes Format. Eigentlich hätte das "Temperature IR" sein sollen, auch in der Firmware. Damit die neuen Bindings die jetzt auch den Device Typ prüfen auch noch mit dem alten "Temperature-IR" funktionieren.

persönliche Anmerkung: Ich "parse" mit einen harten String Vergleich...

if( brickname.Contains("Master Brick ") ) { ...} usw.

solange sich da nicht massiv was ändert ist dies mit die praktischte Lösung.

Gut wäre es wenn man den Namensaufbau in den Dokus extra anmerken kann.

Oder in den Bindings ein Array mit allen Namen der Bricks (oder besser je Klasse den Namen des Bricks in einer statischen Konstanten -> MasterBrick.Name == "Master Brick") dies sollte auch dynamisch zum erzeugen gehen...