photron

Laufen die Programme die die Anfragen machen durch oder startest du die für jede Anfrage neu? Wenn dein Programm durchläuft und ab und zu "vergisst" Sockets/IPConnections wieder zu schließen, dann könnte sich so eine Liste offener Verbindungen ansammeln. Diese würden dann vom Betriebssystem wieder geschlossen, wenn das Programm beendet wird. Da ich aber annehme, dass du das Protokoll von Hand mit einzelnen netcat Aufrufen sprichst kann das eigentlich nicht das Problem sein.

Sorry, das was ungeschickt formuliert. Valgrind gibt das alles an einem Stück aus, das sieht dann z.B. so aus: ==19182== Invalid write of size 4 ==19182== at 0x804838F: f (example.c:6) ==19182== by 0x80483AB: main (example.c:11) ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==19182== by 0x8048385: f (example.c:5) ==19182== by 0x80483AB: main (example.c:11) Das Log sieht jetzt aus wie ich es erwarten würde, nach deiner Beschreibung. Connect und Disconnect schön abwechselnd. Im Fehlerfall sind dann aber im Log Häufungen von Disconnects, was ich komische finde. Das passt nicht so wirklich zum beschriebenen Verhalten deines Aufbaus.

Das steht in den technischen Daten: 4,8V bis 5,7V. Unter der Annahme du meinst Versorgung über den Mini-USB Stecker.

Okay, ich erwarte das Valgrind Invalid Read oder Write Operationen meldet wenn das Problem auftritt. Die Ausgabe von Valgrind dazu mit samt den Backtraces interessiert mich, um zu sehen wo das Problem her kommt. Ich habe mit deine Logs nochmal angesehen und zwei Dinge sind mir aufgefallen. Die letzten zwei Logausgabe bevor das Problem auftritt sind immer: 2014-07-11 21:22:16.454644 <I> <network|client.c:242> Client (S: 20, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-11 21:22:16.455385 <W> <network|client.c:495> Destroying client (S: 20, T: plain, P: 192.168.23.81, A: disabled) while 2 response(s) have not beed send Ein Client schließt seine Verbindung bevor brickd im alle Response Pakete schicken konnte. Auch ist auffällig, dass kurz vorher viele Verbindungen in sehr kurzer Zeit geschlossen werden: 2014-07-12 05:10:14.060499 <I> <network|client.c:242> Client (S: 44, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.060691 <I> <network|client.c:242> Client (S: 45, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.076709 <I> <network|client.c:242> Client (S: 17, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.077244 <I> <network|client.c:242> Client (S: 16, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.078239 <I> <network|client.c:242> Client (S: 18, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.079139 <I> <network|client.c:242> Client (S: 19, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.080047 <I> <network|client.c:242> Client (S: 20, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.080975 <I> <network|client.c:242> Client (S: 21, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.081860 <I> <network|client.c:242> Client (S: 22, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer Da frage ich mich gerade wie das zustande kommt. Wie lange bleiben die Verbindungen der minütlich zugreifenden anderen Rechner bestehen?

Ich hab das Beispiel des Industrial Quad Relay Bricklet gerade getestet und es funktioniert. Wenn die UID richtig ist bleibt nicht mehr viel anderes was die Ursache sein könnte. Füge zum Testen mal nach "ipcon.connect(HOST, PORT);" folgende Zeile im Beispiel ein: iqr.setResponseExpectedAll(true); Wenn es Kommunikationsprobleme gibt sollte das Exceptions erzeugen.

Verwendest du im Beispiel auch die richtige UID deines Bricklets?

Speed ist die Anzahl an LEDs die sich der Dot pro Frame bewegt. Das hat nichts mit der Frame Duration zu tun.

Diese beiden Zeilen sind interessant: 2014-07-12 05:10:14.277472 <E> <network|client.c:260> Could not receive from client (S: 7281224, T: plain, P: P^Mo, A: disabled), disconnecting client: EBADF (9) 2014-07-12 05:10:14.334119 <E> <network|client.c:260> Could not receive from client (S: 7281224, T: plain, P: PTî¶PTî¶23.81, A: disabled), disconnecting client: EBADF (9) "S: 7281224" heißt der File Descriptor des Sockets diese Clients hat einen Wert von 7281224, das ist sehr hoch und ungewöhnlich, daher kommt da dann auch ein EBADF (ungültiger File Descriptor) als Fehler bei rum. "P: PTî¶PTî¶23.81" ist der Peername des Clients, da sollte eine IP Adresse stehen, das sieht aber nach Schrott aus. Das sieht auf den ersten Blick nach Heap Corruption aus. Irgendwie bringst du brickd dazu irgendwo falsch im Speicher herumzuschreiben. Kannst du das Problem reproduzieren? Es wäre hilfreich dazu ein Valgrind Log zu sehen. Dazu brickd manuell mit Valgrind starten: sudo valgrind brickd

Ich habe gerade mal ein paar neue dinge dem Brick Viewer hinzugefügt: - "Show Black" Knopf - Gradient funktioniert jetzt auch mit einer LED und besser mit geringen LED Zahlen - Gradient läuft anders herum - "Moving Color Dot" Mode hinzugefügt Ich nehme an du hast noch deinen git Clone von brickv, dann kannst du das gleich testen

Die IE Meldungen werden von Windows SmartScreen kommen. Der "neue" Treiber ist der alte Atmel Bootloader Treiber für die Bricks, den Atmel jetzt in einer signierten Version bereitstellt, so dass er auch auf Windows 8 ohne Umwege installiert werden kann und frühere Windows Versionen sich nicht mehr über einen nicht-signierten Treiber beschweren. Mal sehen was wir aus deinen LED Strip Ideen machen. Dazu melde ich mich dann später nochmal

Schau bitte mal ins brickd Log auf dem Raspberry Pi: /var/log/brickd.log Falls du daraus nicht schlau wirst, dann kannst du das auch hier posten, damit wir einen Blick darauf werfen können.

Okay, Version 2.1.1 ist jetzt im Sonatype OSS Repository angekommen: https://oss.sonatype.org/content/repositories/releases/com/tinkerforge/tinkerforge/ Es ist auf http://search.maven.org/ noch nicht zu finden, das sollte in Kürze aber auch gehen.

Sorry, über die ganze RED Brick Entwicklung ist das hier irgendwie hinten runtergefallen Ich hab bei Sonatype jetzt ein neues Projekt für die Bindings beantragt und mein Maven Setup für das Projekt nach deren guter Anleitung konfiguriert. Das sollte in den nächsten Tage also was werden

Android Apps sind in Java geschrieben. Brick Viewer ist aber in Python mit Qt als GUI Bibliothek. Man müsste entweder brickv in Java neuschreiben, oder den Python Code für Android flott machen. Es gibt da wohl Projekt für Python auf Android. Das ist aber alles nicht mal eben und dann ist das GUI Layout von brickv auch nie für Smartphones gedacht gewesen. Erwarte also in nächster Zeit kein Brick Viewer Android App Schau dir aber mal den Prototypen von Brick Viewer im Browser an: www.brickv.com. Allerdings werden da noch nicht alle Brick und Bricklet und Funktionen unterstütz. Das ist in JavaScript und recht leicht zu erweitern.

2.1.3 ist veröffentlicht.

Bindings: C/C++ 2.1.3 Redeklaration von strnlen in einigen MinGW Umgebungen behoben Download: C/C++

Bindings: C/C++ 2.1.3 Fix strnlen redeclaration in some MinGW environments Download: C/C++

Sorry, test mal bitte diese Version. tinkerforge_c_bindings_2_1_3_rc1.zip

Ist umbenannt.

Brick Viewer 2.1.1 Use a more recent UI style on Windows Store port, authentiation options and secret per host and double host history length Use a signed Brick bootloader driver on Windows Add support for WS2811 and WS2812 to LED Strip Bricklet plugin Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.2, C# 2.1.1, Delphi/Lazarus 2.1.1, Java 2.1.1, JavaScript 2.0.1, LabVIEW 2.1.1, Mathematica 2.1.1, MATLAB/Octave 2.0.1, Perl 2.1.1, PHP 2.1.1, Python 2.1.1, Ruby 2.1.1, Shell 2.1.1, VB.NET 2.1.1 Add support for WS2811 and WS2812 to LED Strip Bricklet API [all] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET

Brick Viewer 2.1.1 Modernen UI Style unter Windows Port, Authentifizierungs-Optionen und Secret werden pro Host-eintrag gespeichert und die Länge der Host-Historie wurde verdoppelt Brick Bootloader Treiber für Windows ist jetzt signiert Support für WS2811 und WS2812 zur LED Strip Bricklet API hinzugefügt Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.2, C# 2.1.1, Delphi/Lazarus 2.1.1, Java 2.1.1, JavaScript 2.0.1, LabVIEW 2.1.1, Mathematica 2.1.1, MATLAB/Octave 2.0.1, Perl 2.1.1, PHP 2.1.1, Python 2.1.1, Ruby 2.1.1, Shell 2.1.1, VB.NET 2.1.1 Support für WS2811 und WS2812 zur LED Strip Bricklet API hinzugefügt [alle] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET

Kein Tippfehler, sondern missverständlicher Satzbau. Besser wäre gewesen: 0b00001111 in Binär ist also 15.

Du kannst auch mit set_port_configuration() alle 8 Pins eines Port setzen. io.set_port_configuration('b', (1 << 0) | (1 << 7), 'o', True) Hier wählt das erste Parameter den Port, in diesem Falle 'b'. io.set_port('b', 0b00001111) Hier wählt das erste Parameter wieder den Port, in diesem Falle 'b'. Das b in 0b00001111 steht für Binär. 0b00001111 ist also 15 in Binär. In Hex wäre das 0x0F. 0b00001111 (Binär) ist 15 (Dezimal) ist 0x0F (Hex). Einige Programmiersprachen, wie z.B. Python erlauben es Binärzahlen direkt hinzuschreiben. (1 << 0) | (1 << 7) z.B. erzeugt durch Shift- und Or-Operationen die Binärzahl 0b10000001. Die das IO-16 Bricklet dann als Bitmaske interpretiert und den ersten und achten Pin an Port B auf High und alle anderen auf Low setzt, weil das erste und das achte Bit 1 sind und der Rest 0.