photron

Ich hab die Dokumentation aktualisiert. Mit Antenne steigt der Verbrauch um ca. 10mA.

Wie sieht die Fehlermeldung aus, die du bekommst, wenn der Compiler "spinnt"? Versucht du das in der Arduino IDE zu kompilieren? Das wird nicht funktionieren. Du brauchst sowas wie Microsoft Visual Studio Express oder Qt Creator oder Dev-C++. Das hat nichts mit Windows XP zu tun, das ist nicht dein Problem. Da die C Bindings auch für ObjC funktionieren, wird es von uns zumindest in nächster Zeit keine speziellen ObjC Bindings geben.

Wo fügst du denn die Bindings ein? Welche Fehlermeldungen bekommst du denn? Was für Plugins meinst du? Die C/C++ Bindings sind mit dem GCC/G++ Compiler (auch MinGW) und dem Microsoft Visual Studio Compiler getestet, sollten aber auch mit anderen C/C++ Compilern funktionieren.

Das bedeutet, dass ein zu brickd verbundenes Programm (brickv, oder dein eigens Steuerprogramm) die TCP/IP Verbindung aktiv beendet hat und dies von der brickd Seite nicht erwartet war, da noch Aktionen ausstanden. Das kann z.B. sein, dass noch Daten zu lesen waren oder ähnliches. Das kann mit deinem Relais Problem zusammenhängen, muss es aber nicht. Es kann auch einfach nur auf ungünstiges Verhalten in deinem Programm hindeuten. Schwer zu sagen nur aus der Fehlermeldung heraus

Das ist komisch. Ich habe mir gerade die Änderungen zwischen 2.0.5 und 2.0.7 angesehen und da ist nichts dabei was diese Verhalten auf Anhieb erklärt. Okay zum Backtrace: der Receive Thread (Thread 2 in gdb) scheint im table_get() zu stehen. Das ist komisch. Auch das der table_get() Aufruf für UID 0ist, ist komisch, da UID keine gültige UID für ein Brick oder Bricklet ist. Weiterhin ist im ipcon_receive_loop() Aufruf pending_length = 34, der erste Header in pending_data ist aber voller Nullen. Will sagen, da ist was sehr faul. Da der Header voller Nullen ist ist length in Zeile 1302 auch 0 und damit bleibt pending_data auf 34 und die while (true) Schleife in Zeile 1296 bricht nicht ab und der Thread endet nicht. Der Receive Thread steht also nicht in table_get(), sondern du hast den Thread nur gerade zufällig da angehalten. Das Problem ist also, dass im pending_data Buffer falsche Daten stehen (lauter Nullen). Die Frage ist jetzt wie die dahin gekommen sind: Hat brickd die wirklich geschickt? Du könntest mit Version 2.0.7 nach dem socket_receive in Zeile 1272 einmal die Werte von length, pending_length und den Inhalt von pending_data per printf oder Ähnlichem ausgeben, um zu sehen ob da die Nullen wegkommen. Als Änderung für die IP Connection werde ich erstmal die while (true) Schleife in Zeile 196 durch eine while (ipcon->receive_flag) Schleife ändern, dann sollte das pthread_join() nicht mehr vergeblich warten. Das eigentliche Problem, dass im pending_data Buffer bei dir 34 Nullen stehen ist damit allerdings nicht behoben oder erklärt.

pthread_join() blockt weil es darauf wartet, dass sich der Receive Thread beendet, was aber nicht zu passieren scheint. Ich denke, dass der in recv() steht und der shutdown() Aufruf den recv() Aufruf nicht abgebrochen hat. Kannst du das Problem einfach reproduzieren? Mich interessiert ein gdb Backtrace für alle Threads: thread apply all backtrace full Um zu sehen wo der Receive Thread wirklich steht.

Danke für den Hinweise. Link ist korrigiert.

Funktioniert hier ohne Probleme unter Linux mit Python 3.2.3. Probier mal nach den prints stdout zu flushen: #!/usr/bin/env python import sys HOST = "localhost" PORT = 4223 UID = "aE7" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_io16 import IO16 # Callback function for interrupts def cb_interrupt(port, interrupt_mask, value_mask): print('Interrupt on port: ' + port) print('Interrupt by: ' + str(bin(interrupt_mask))) print('Value: ' + str(bin(value_mask))) sys.stdout.flush() if __name__ == "__main__": # [...]

Maybe the EEPROM on the Dual Relay Bricklet storing its plugin was effected by EMI and got (partly) erased. You could try to flash the Dual Relay Bricklet again. As your stack doesn't boot if the Bricklet is connected you need to hotplug it: First connect the Master Brick to USB and wait for the end of the blinken lights sequence, then connect the Bricklet to the running Brick and finally flash it in brickv.

Brick Viewer 2.0.7 Fix naming of Industrial Dual 0-20mA Bricklet Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.7 Benennung des Industrial Dual 0-20mA Bricklets korrigiert Downloads: Windows, Linux, Mac OS X

If the WIFI Extension associates with your router then the Master Brick has to be working (to some extent at least), because the WIFI Extension doesn't act on its own, it is configured and controlled by the Master Brick. IIRC you have a Dual Relay, a Distance IR and an LCD 20x4 Bricklet connected to your Master Brick. Is this the rest of the stack that doesn't show up anymore? Does the Master Brick itself still show up over the WiFi connection? If it doesn't, what happens if you connect the stack over USB?

Bindings: C/C++ 2.0.7, C# 2.0.8, Delphi 2.0.10, Java 2.0.8, PHP 2.0.8, Python 2.0.8, Ruby 2.0.8, VB.NET 2.0.4 Add support for PTC Bricklet and Industrial Dual 0-20mA Bricklet [all] Workaround for GCC 4.7 struct packing bug is only necessary on Windows [C/C++] Avoid breaking strict-aliasing [C/C++] Fix Windows Phone support [C#] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

Bindings: C/C++ 2.0.7, C# 2.0.8, Delphi 2.0.10, Java 2.0.8, PHP 2.0.8, Python 2.0.8, Ruby 2.0.8, VB.NET 2.0.4 Support für PTC Bricklet und Industrial Dual 0-20mA Bricklet hinzugefügt [alle] Workaround für GCC 4.7 Struct Packing Bug ist nur für Windows notwendig [C/C++] Strict-Aliasing Regeln werden eingehalten [C/C++] Windows Phone Support funktioniert wieder [C#] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

I changed the example to use ° to make it less error prone.

Der Brick Viewer benötigt keine Adminrechte. Eine Steueroption für den Brick Daemon in den Viewer einzubauen halte ich für keine gute Idee. Das wird viele Nutzer eher verwirren, u.a. weil sich das immer auf den lokale brickd beziehen würde und nicht den zu dem man gerade verbunden ist. Für Python gibt es für Service Steuerung das win32serviceutil Modul, unter der Annahme dass es hier um Windows geht. Ein Beispiel dazu. Ansonsten gibt es noch die Kommandozeilentools sc und net unter Windows: sc stop "Brick Daemon" net stop "Brick Daemon"

Brick Viewer 2.0.6 Remove averaging of analog value from Distance IR Bricklet plugin Set min/max degree correctly if all servos are selected in Servo Brick plugin Support splitted LCD 20x4 Bricklet plugin Fix monoflop time update if Go button is clicked in quick succession Add plugins for PTC Bricklet and Industrial Dual 0-20mA Bricklet Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.6 Averaging des Analogwerts aus dem Distance IR Bricklet Plugin entfernt Min/Max Winkel wird korrekt gesetzt wenn alle Servos im Servo Brick Plugin ausgewählt sind Update und Flashen des aufgeteilten LCD 20x4 Bricklet Plugins funktioniert wieder Problem mit der Aktualisierung der Monoflop-Zeit Anzeige behoben, wenn der Go Knopf schnell hintereinander geklickt wird Plugins für PTC Bricklet und Industrial Dual 0-20mA Bricklet hinzugefügt Downloads: Windows, Linux, Mac OS X

Dein angehängtes Programm funktioniert prinzipiell, du bist da aber in eine Falle mit dem Linker geraten. Das Problem ist, dass du eine Funktion namens send hast und es schon in der libc eine Funktion namens send gibt die die IPConnection inter verwendet. Der Linker nimmt jetzt aber deine send Funktion anstatt der aus der libc (weil die gleich heißen). Der Segfault kommt dann daher dass die falsche send Funktion aufgerufen. Die Lösung ist, deine send Funktion in sendString umzubenennen. Zusätzlich machst du am besten alle deine Funktionen (außer main) static, dann sind sie nur innerhalb der main.c sichtbar. Also statt sendByte (char c) { ... } void send(char *c) { ... } dann static void sendByte (char c) { ... } static void sendString(char *c) { ... }

Kann ich hier nicht reproduzieren. Funktioniert es denn wenn beide Master die neuste Firmware haben?

Ich habe das gerade nochmal hier getestet mit aktuellem Raspbian Image und das funktioniert alles so wie beschrieben. Am Ende habe ich im Menu von LXDE unter Other bzw. Sonstiges einen funktionierenden Brick Viewer Eintrag. Es dauert allerdings einen Moment bis brickv nach dem Klick startet, das Raspberry Pi ist nicht das schnellste Was steht denn bei dir in /usr/share/applications/brickv.desktop? Die sollte so aussehen: [Desktop Entry] Encoding=UTF-8 Name=Brick Viewer Version=1.0 Comment=Viewer for Bricks and Bricklets GenericName=Brick Viewer Terminal=false Icon=brickv-icon.png Type=Application Exec=python /usr/share/brickv/main.py Categories=Electronics;

Es reichen diese beiden Dateien plus die Pakete python-argparse und python-serial. Welche Abhängigkeiten meinst du? RouvenE fehlte python-serial, weil das in unserer Installationsanleitung nicht aufgelistet war, das ist behoben. Im brickv.deb selbst sind aber alle Abhängigkeiten richtig angegeben. Man könnte argumentieren, dass da python-argparse fehlt, wenn man flash-brick-cli.py als Teil des Pakets ansieht. Was nicht direkt so beabsichtigt war. Es wird dann ja auch noch ein eigenes .deb dafür geben, das dann python-argparse und python-serial als Abhängigkeiten haben wird.

Das brickv.deb ist natürlich nicht für Systeme ohne GUI gedacht, wie auch flash-brick-cli.py ist eigentlich so gedacht dass du dass zusammen mit samba.py dir irgendwohin kopiert un dann von da ausführst. Dass das im brickv.deb drin ist ist ehr unserer einfachen Art das .deb zu bauen geschuldet, und weniger einer Absicht. Ich gebe dir aber Recht, dass es natürlich hübscher wäre ein eigenes .deb für flash-brick-cli.py zu haben. Ich setze das mal auf die TODO Liste. Sorry, für die gestiftete Verwirrung und die späte Antwort.

Das "Problem" an PHP ist so ein bisschen, dass es eigentlich nicht als General Purpose Programmiersprache gedacht ist/war, sondern zur Programmierung von Webseiten gemacht ist. Wir empfehlen typischerweise Python als Sprache für Anfänger/Einsteiger.

Zu python-serial: Das fehlte in der Anleitung für brickv auf Raspberry Pi installieren, ist jetzt korrigiert. Zu brickd: Wenn du den aus dem .deb installiert hast, wird der automatisch beim Hochfahren mitgestartet. Zum Wetterstations Democode: Auf der Seite ist im ersten Abschnitt die Anleitung zur Installation der benötigten Python Bindings verlinkt. In Kurz: Das Zip für Python von der Downloadseite herunterladen und das .egg darin mit easy_install installieren. wget http://download.tinkerforge.com/bindings/python/tinkerforge_python_bindings_latest.zip unzip tinkerforge_python_bindings_latest.zip -d tinkerforge_python_bindings sudo easy_install tinkerforge_python_bindings/tinkerforge.egg Danach kannst du dann den Democode der am Ende der Seite verlinkt ist herunterladen und ausführen: wget https://raw.github.com/Tinkerforge/weather-station/master/write_to_lcd/python/weather_station.py python weather_station.py