photron

Der Vorteil an daran, dass in Python zu machen ist, dass es überall da funktioniert wo Python und argparse vorhanden sind. Wir müssen also nicht für n verschiedene Plattformen n verschiedene Binaries erstellen. Der Nachteil daran ist, dass Python benötigt wird, ja. Das ist zumindest bei Debian sqeeze nicht richtig. An anderer Stelle habe ich schonmal gehakt. Es reicht hier Python 2.6: Okay. Laut Python Dokumentation ist es seit 2.7 in der Standard Library. Das hindert Debian natürlich nicht daran das auch für Python 2.6 bereitzustellen Das sind also quasi Variablen die man mit "--execute" und "--replace" weiterverarbeiten kann!? Warum muss das sein und was ist "format Funktion aus Python"? Ohne --execute werden die Ausgaben von Gettern und Enumerate als <key>=<value> per Zeile auf stdout ausgegeben. Das kannst du dann mit xargs, awk, etc weiterverarbeiten. --execute ist einfach eine andere optionale Variante die Ausgabe zu verarbeiten/formatieren. Die ist z.B. mit Hinblick auf Windows gedacht, wo Sachen wie xargs und awk nicht so einfach zur Hand sind. --execute nimmt einen Shell Befehl entgegen und hängt dann einfach alle Ausgabewerte an. tinkerforge call temperature-bricklet --uid SCT31 get-temperature --execute "echo" Hier wird dann "echo 2258" ausgeführt. Mit --replace können im Shell Befehl Platzhalter verwendet werden. In diesem Fall {temperature}: tinkerforge call temperature-bricklet --uid SCT31 get-temperature --execute "echo `date +%s` {temperature} >> t.log" --replace Hier wird dann "echo `date +%s` 2258 >> t.log" ausgeführt. Für diese Platzhalter wird einfach die Python format Funktion verwendet: http://docs.python.org/2/library/string.html#format-examples

Mit LCD 20x4 Bricklet Plugin 2.0.3 ist das Problem jetzt behoben. Der Cursor springt am Zeilenende jetzt in die jeweils nächste Zeile. Aus der letzten Zeile springt er dann wieder in die erste. War nicht so schwierig zu fixen wie borg erst dachte

Plugins: LCD 20x4 Bricklet 2.0.3 Fix cursor position logic at end of line Download Plugin: LCD 20x4 Bricklet

Plugins: LCD 20x4 Bricklet 2.0.3 Cursor Positionierung am Ende der Zeile korrigiert Download Plugin: LCD 20x4 Bricklet

Da das doch recht schnell von der Hand ging hier mal ein erster Prototyp der Shell Bindings. Sie basieren auf den Python Bindings und die Kommandozeilenbehandlung ist mit argparse gemacht. Dadurch wird mindestens Python 2.7 benötigt. Enumerate Ein Enumerate mit Standardausgabe: $ ./tinkerforge enumerate uid=68aT1f connected-uid=0 position=b'0' hardware-version=1,0,0 firmware-version=2,0,6 device-identifier=13 uid=SCT31 connected-uid=68aT1f position=b'a' hardware-version=1,1,0 firmware-version=2,0,0 device-identifier=216 Ein Enumerate mit --execute. Alle Parameter des Enumerate Callbacks werden durch Leerzeichen getrennt an die --execute Befehlszeile angehängt und dann das Ergebnis ausgeführt: $ ./tinkerforge enumerate --execute echo 68aT1f 0 0 1,0,0 2,0,6 13 0 SCT31 68aT1f a 1,1,0 2,0,0 216 0 Ein Enumerate mit --execute und --replace. Das --replace Flag sorgt dafür, dass auf die --execute Befehlszeile die format Funktion aus Python angewandt wird: $ ./tinkerforge enumerate --execute "echo {uid} {device-identifier}" --replace 68aT1f 13 SCT31 216 Funktionen Temperaturabfrage eines Temperature Bricklets mit UID SCT31: $ ./tinkerforge call temperature-bricklet --uid SCT31 get-temperature temperature=2325 Auch hier funktionieren --execute und --replace: $ ./tinkerforge call temperature-bricklet --uid SCT31 get-temperature --execute 'echo "scale=2; {temperature} / 100" | bc | xargs printf "Die Temperatur beträgt: %s °C\n" ' --replace Die Temperatur beträgt: 23.18 °C Callbacks Aufruf der set-temperature-callback-period Funktion des Temperature Bricklets mit UID SCT31: $ ./tinkerforge call temperature-bricklet --uid SCT31 set-temperature-callback-period 500 Auf Callbacks warten: $ python3 ./tinkerforge dispatch temperature-bricklet --uid SCT31 temperature temperature=2418 temperature=2431 Auch hier funktionieren --execute und --replace: ./tinkerforge dispatch temperature-bricklet --uid SCT31 temperature --execute 'echo "scale=2; {temperature} / 100" | bc | xargs printf "Die Temperatur beträgt: %s °C\n" ' --replace Die Temperatur beträgt: 23.18 °C Die Temperatur beträgt: 23.25 °C Was haltet ihr davon? tinkerforge

Okay, jetzt weiss ich was da passiert. PC2 verlangt einen Response für den set_configuration, wartet aber nicht auf die Antwort sondern macht die Verbindung wieder zu, bevor die Antwort bei brickd angekommen ist. Kurzer brickd Interna Ausflug: Für eingehende Anfragen mit R Flag merkt sich brickd den Header des Pakets in einer Liste pro TCP/IP Verbindung. Dadurch kann er eingehende Antworten an die Verbindung weiterreicht, die auf diese Antwort wartet. Wenn eine Antwort ankommt, auf die keiner wartet dann wir sie an alle geschickt. Dann kommt die verlangte Antwort von set_configuration an. Da aber die anfragende Verbindung schon wieder zu ist wartet keiner mehr auf diese Antwort und brickd schickt sie an alle offenen TCP/IP Verbindungen. Und daher bekommt deine temperaturabfragende Verbindung die IO-4 Antworten. Da ist also by-Design wenn du so willst.

Wie AuronX sagt, sind die Antworten vom IO-4, die du da sieht, die fürs Response Expected Flag. Unter der Annahme, dass du die Temperaturabfrage und das IO-4 Setzen nicht über die gleiche TCP/IP Verbindung machst solltest du diese IO-4 Antworten da nicht sehen. Spielt dir da vielleicht netcat einen Streich, oder machst du doch beides über eine TCP/IP Verbindung? Hast du mal ins brickd Log geschaut und dort nachverfolgt wann TCP/IP Verbindung auf und abgebaut werden und wo welche Antworten hingesandt werden? Wireshark kann auch sehr hilfreich sein. Dass da einer der IO-4 Nachrichten die letzten 2 Byte fehlen könnte an netcat liegen, dass dann eben nur die ersten n-2 von n Byte empfangen hat.

Zu 1: Das ist dokumentiert im Packet Layout Abschnitt: 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?).

Brick Daemon 2.0.5 Avoid non-portable usage of bit fields Handle big endian byte order correctly Show UIDs in log messages in Base58 Debian i386 package now really compiled for i386 instead of i686 Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.5 Nicht-portable Verwendung von Bitfelder korrigiert Big Endian Byte Order wird nun korrekt behandelt UIDs werden im Log in Base58 angezeigt Debian i386 Package wird jetzt wirklich für i386 compiliert, anstatt i686 Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Loetkolben, in beiden lsusb ausgaben ist 16d0:063d als VID:PID drin. Das ist der Brick normal gestartet, er ist nicht im Bootloader.

/dev/bus/usb/002/002 ist das USB Device an sich. Das ist hier nicht richtig. Du brauchst da den seriellen Port den der Bootloader des Bricks über USB anbietet. Typischerweise taucht der als /dev/ttyACM0 oder /dev/ttyUSB0 auf.

Richtig, exakt so läuft das. Denn nur so ist das kompatible zu älteren Firmwares. Die beiden genannten Dinge sind jetzt dokumentiert.

Das wurde vergessen zu dokumentieren, sorry. Die TCP/IP Dokumentation ist jetzt wieder aktuell.

In /usr/local/lib/python2.6/dist-packages/easy-install.pth sollte sowas wie import sys; sys.__plen = len(sys.path) ./tinkerforge.egg import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new) stehen und easy_install -m tinkerforge sollte daraus die ./tinkerforge.egg Zeile entfernen.

Hier ein .deb für i386 das jetzt auch wirklich mit gcc -march=i386 gebaut wurde. Wenn ich das Problem richtig verstehe sollte das jetzt bei dir funktionieren. brickd-2.0.4_really_i386.deb

easy_install hat kein wirkliches Uninstall Kommando. Man kann ein mit easy_install installiertes egg aber wie folgt wieder sauber entfernen: sudo easy_install -m tinkerforge Dies trägt tinkerforge aus der Modulliste wieder aus. Dieser Befehlt gibt die dann auch was wo das entpackte egg liegt: $ sudo easy_install -m tinkerforge Searching for tinkerforge Best match: tinkerforge 2.0.5 Processing tinkerforge.egg Removing tinkerforge 2.0.5 from easy-install.pth file Using /usr/local/lib/python2.7/dist-packages/tinkerforge.egg Dann noch dass entpackte egg manuell entfernen: sudo rm -rf /usr/local/lib/python2.7/dist-packages/tinkerforge.egg

Das erste was mir gerade auffällt ist das brickd-*_i386.deb auf einem i686 Rechner compiliert wird und daher eigentlich i686 ist. Kann es sein, dass du einen CPU < i686 hast? Was gibt "uname -a" aus? Was gibt "gcc -Q -v" aus, falls du gcc installiert hast?

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.

Beides durchaus sinnvolle Vorschläge. Die nächsten Bindings werden höchstwahrscheinlich für LabVIEW sein.

Ist korrigiert, danke für den Hinweis.

Das nenn' ich mal einen stabilen und wetterfesten Aufbau

Hab's gerade eingebaut. Qt bietet da gleich eine Option für. Ist dann in der nächsten brickv Version mit drin.

Argh, irgendwie ist in dem Stück Dokumentation der Wurm drin. Sorry. Es muss natürlich "device_identifier - uint16" lauten und ist jetzt auch korrigiert. Danke für die Hinweise.

Nein, das ist richtig. Auf TCP/IP Ebene sind uid und connected_uid des Enumerate Callbacks uint32, genauso wie die UID im Header jedes Packets auch uint32 ist. Die Bindings machen dann die Umwandlung zwischen Base58 und uint32, damit die UIDs auf Benutzerebene immer Base58 sind. Edit: Du hast recht, die Dokumentation passte nicht. Ich habe mich da an eine erste Version von Protokoll 2.0 erinnert, sorry. Dokumentation ist jetzt korrigiert.