photron

Das Hinzufügen des EnumerateListener löst kein Enumerate aus. Das sieht für dich nur so aus, weil das zeitlich bei dir gerade in der passenden Reihenfolge passiert, das ist aber nicht kausal zusammenhängend. Es gibt 3 Gründe die eine Enumerate verursachen. 1) Du erzwingst es durch einen enumerate() Aufruf. Dann ist der enumerateType == AVAILABLE im EnumerateListener Aufruf. 2) Der Stack hat eine neue Verbindung aufgebaut. Dann sendet er von sich aus einen Enumerate Callback mit enumerateType == CONNECTED. Damit kann den Programm mitbekommen, ob ein Stack im laufenden Betrieb neugestartet ist/wurde. Bei WIFI führt dass dazu das du direkt nach dem Verbindungsaufbau ein Enumerate bekommst. 3) Der Stack wurde von USB getrennt, Dann sendet brickd von sich aus einen Enumerate Callback mit enumerateType == DISCONNECTED.

There really is a deadlock I can reproduce this problem. It takes about 15min of WIFI downtime to created it. I'm debugging this right now.

Es gibt jetzt auch welche für Qt Creator. Der Hinweis auf den Workaround für den GCC 4.7 Bug aus dem anderen Thread fehlt da mit Absicht. Ich habe noch einen anderen Workaround gefunden, der ohne Zutun des Nutzers funktioniert und Teil der nächsten C/C++ Bindings Version sein wird (er befindet sich schon im git).

Stellt sich heraus, dass das ein GCC 4.7 Bug ist. Ein Workaround dafür ist folgende Zeile in deine .pro Datei einzufügen: QMAKE_CXXFLAGS += -mno-ms-bitfields

The microcontroller on the Stepper Brick has 128 kB flash memory. The bootloader is not stored in this flash memory. But there are 4 kB flash reserved at the end of the flash memory for each of the two Bricklets. So there is currently 128 kB - 55 kB - 2 * 4 kB = 65 kB of free flash memory.

Es steht auf der TODO Liste, ich bin allerdings noch nicht dazu gekommen mich darum zu kümmern, sorry.

pluto, das mag sich ja gut anhören, aber ich muss das als Utopie entlarven. Denn dass würde bedeuten, für jede Programmiersprache die man da unterstützen wollte, einen neuen Compiler zu schreiben, der dann Machinencode für Cortex-M3 (die Architektur der Mikrocontroller auf den Bricks) erzeugt. Oder wenn mann nicht direkt Machinencode erzeugen wollte, dann müsste man alle zu unterstürzenden Programmiersprachen in einen Bytecode übersetzen und diesen dann auf dem Brick interpretieren. Ähnlich wie Java, C#, Python usw. auch funktionieren. Ich denke, dass wird weder in der einen noch der anderen Form passieren, denn den nötigen Aufwand für sowas kann ich gerade nicht mal überblicken. Für den Fall, dass man annehmen will, dass das überhaupt sinnvoll machbar ist.

Es gibt zwei Arten von Extensions: PC-zu-Stack: WIFI und Ethernet. Ersatz für ein USB Kabel. Stack-zu-Stack: RS485 und Chibi. Ersatz für die Board-to-Board Stecker der Bricks. Wenn ich die richtig verstehe möchtest du WIFI als Stack-zu-Stack Verbindung einsetzen, das ist so nicht vorgesehen.

Die Undefined Reference Fehler die du da noch hast beziehen sich alle auf WinSock2. Du musst noch wie hier beschriebene geben die ws2_32.dll linken: http://www.tinkerforge.com/de/doc/Software/API_Bindings_C.html#gcc Dafür fügst du in deine .pro Datei folgende Zeile ein: LIBS += -lws2_32

Okay, ich hab das mal versucht und kann wirklich "uses Macapi.CoreFoundation" verwenden. Aber "uses Macapi.CocoaTypes" gibt z.B. einen Fehler obwohl das laut Dokumentation auch gehen sollte. Die Dokumentation dazu ist sehr dünn von der Delphi Seite her. Laut Apple Dokumentation gibt es CFSocket im CoreFoundation Framework. Aber ich konnte nicht herausfinden wie man das dann in Delphi verwendet. Es scheint weder CFSocket, noch CFSocketRef, noch TCFSocket oder TCFSocketRef als Typ zu geben. Da steh ich auf dem Schlauch. Ich kann auch keinerlei Beispielcode dazu finden, wie das funktionieren soll. Edit: Nachdem ich noch mal ein neues Projekt angelegt habe kann ich jetzt CFSocketRef verwenden.

On Windows 8 the Brick Daemon and Brick Viewer installers don't install any drivers, that's correct. There are two reasons for this: 1. The drivers aren't signed and Windows 8 doesn't allow to installed unsigned driver by default. 2. Windows 8 can auto detect a Brick and install it's own driver for it. You don't need the drivers that come with Brick Daemon and Brick Viewer on Windows 8. If you connect a Master Brick (with a version 2 firmware) to USB, it'll show up as "Master Brick" in the USB devices category in the device manager. Now brickd should be able to find it and a connected brickv should show it. If a Brick is in bootloader mode then Windows 8 will auto detect it as a serial port named "GPS Camera Detect". This serial port can then be selected in brickv for flashing. Doesn't it work for you as described?

Das ist richtig. Im Moment wird angenommen, dass Delphi IDE == Windows bedeutet. Das funktioniert für iOS dann natürlich nicht mehr. Ich habe mir das gerade mal angesehen und es fehlt zumindest die Sockets Unit. Ich konnte allerdings bisher nicht herausfinden was man tun muss um die wieder zu bekommen, oder wie man mit Delphi unter iOS Sockets benutzt.

Das Umbenennen von *.c nach *.cpp ist denke ich die einfachste und beste Weise um die Bindings in C++ zu verwenden. Dann passt auch das Name Mangling automatisch usw. Ich nehme das mal als empfohlenes Vorgehen für C++ in die Dokumentation auf.

Here's a first prototype of the shell bindings. They are written in Python for portability and use the argparse module for the command line handling. Host and port default to localhost and 4223, they can be changed with the --host and --port option: tinkerforge --host 192.168.178.42 Enumerate It can enumerate connected devices: $ tinkerforge enumerate uid=68aT1f connected-uid=0 position=0 hardware-version=1,0,0 firmware-version=2,0,6 device-identifier=13 uid=SCT31 connected-uid=68aT1f position=a hardware-version=1,1,0 firmware-version=2,0,0 device-identifier=216 The output is in <key>=<value> format can can then be processed further with xargs, awk, etc. By default the bindings will wait 250ms for enumerate callbacks, this can be changed with the --duration option. Functions Calling the get-temperature function of a Temperature Bricklet with UID SCT31: $ tinkerforge call temperature-bricklet --uid SCT31 get-temperature temperature=2325 Callbacks Setting the temperature callback period to 500ms: $ tinkerforge call temperature-bricklet --uid SCT31 set-temperature-callback-period 500 and waiting for temperature callbacks $ tinkerforge dispatch temperature-bricklet --uid SCT31 temperature temperature=2418 temperature=2431 By default the bindings will dispatch callbacks forever, this can be changed with the --duration option. Output Processing There are two options for further output processing: --execute and --replace. The --execute option takes a shell command. The bindings then append the output values to this command and execute it: $ 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 With the --replace option the bindings don't append the output values to the shell command but apply the Python string format function to the command string: $ tinkerforge dispatch temperature-bricklet --uid SCT31 temperature --execute 'echo "scale=2; {temperature} / 100" | bc | xargs printf "`date`, the temperature is: %s °C\n"' --replace Thu Apr 25 13:44:25 CEST 2013, the temperature is: 24.25 °C This allows to use the key from the <key>=<value> output pairs as placeholders (wrapped in curly braces) in the shell command. The bindings replace them with the corresponding values before executing the shell command. This two options are mainly intended for platforms such as Windows that don't have advanced shell commands (xargs, awk, etc) ready to use. Bash Completion For tab completion in bash the tinkerforge.bash_completion file has to be moved to /etc/bash_completion.d/ as tinkerforge and the tinkerforge script has to be in a location in PATH. Now tab completion should work. tinkerforge tinkerforge.bash_completion

Okay, laut lsusb erkennt Linux den Servo Brick. Was sagt denn dass brickd Log unter /var/log/brickd.log dazu? Steht da was von "Added USB device" und "Removing USB device" wenn du den Brick per USB an- und absteckst?

Und jetzt auch mit dem ersten Versuch für bash Completion. Dafür muss sich tinkerforge im PATH befinden, tinkerforge.bash_completion muss nach /etc/bash_completion.d/ und in tinkerforge umbenannt werden. tinkerforge tinkerforge.bash_completion

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