photron

Du kannst eine armhf VM auf einem x86 Host aufsetzen. Das geht allerdings meines Wissens nach nicht mit Virtual Box. Dafür brauchst du dann z.B. QEMU, das dann armhf auf x86 emulieren kann.

Deine VM wird höchstwahrscheinlich als x86 laufen und nicht als armhf. Daher wirst du auch von Linux aus noch für die Architektur des RED Brick Cross-Compilen müssen. Das Free Pascal Wiki hat einen Artikel darüber: http://wiki.freepascal.org/Setup_Cross_Compile_For_ARM Auf dem RED Brick wird der Free Pascal Compiler installiert sein, wie ihn auch Lazarus verwendet. Daher sollten deine Units auf dem RED Brick kompilierbar sein.

Du wirst Binaries direkt übertragen können. Das setzt aber voraus, dass du auf dem deinem Rechner auch Binaries für Linux ARM Hard-Float erzeugen kannst. Bei Java und C# oder den interpretierten Sprachen wie Python oder PHP ist das standardmäßig gegeben. Bei Delphi oder C muss du dazu dann aber Cross-Compilen. Davon hält dich keiner ab, ist aber nicht ganz so leicht. Daher ist auch geplant, dass du deinen Source Code überträgst und auf dem RED Brick kompilierst.

Ahhh! Sorry, I totally misunderstood your problem. Everything is working, except from the Perl example. Okay, now I see what your problem is. There is a problem in our Perl example for the Remote Switch Bricklet. It is calling the switch_socket() function. This function is there for backward compatibility only. It should actually call the switch_socket_a() function for type A devices. But you have a type B device (ITL-210). You need to call switch_socket_b() function. Actually you need to call the dim_socket_b() function, because the ITL-210 is a dimmer. You need to replace this line in the example $rs->switch_socket(42, 23, $rs->SWITCH_TO_ON); with this line $rs->dim_socket_b(1234, 1, 7); to set the dimmer value to 7.

2014-07-29 12:38:07.998117 <D> <hardware|hardware.c:102> No stacks connected, dropping request (U: 1, L: 8, F: 254, S: 2, R: 0) According to brickd you don't have any Bricks connected to USB. There was a problem with the USB host on original Beagle Bone, Bricks connected to it didn't work properly due to some USB problem. Maybe the Beagle Bone Black still has this problem, I don't know. Things you can test: - Does it work if you connect the Brick directly to your PC instead of the Beagle Bone? - Do you have an USB hub at hand to connect between the Beagle Bone and the Brick?

JoergK, kann ich hier so nicht reproduzieren. Funktioniert hier im Test wie es soll. Welche Master Brick Firmware Version verwendest du? Wie verhält sich die grüne LED auf der WIFI Extension? Sie sollte während des Verbindingsaufbaus blinken, und wenn die Verbindung steht dauerhaft leuchten.

Das kann ein Wärmeproblem sein. Update mal den Master Brick auf die aktuelle Firmware 2.2.2.

Okay auf den ersten Blick sehe ich das kein direktes Problem im Code. Ich bleibe bei meiner Vermutung, dass du den Interrupt in deinem Programm nicht richtig einstellst. In deinem ersten Post sprachst du von Pin 1. Meinst du damit den Pin der auf dem IO-4 Platine mit einer "1" gekennzeichnet ist? Wenn ja, dann aktiviert io4.SetInterrupt(1 << 0) nicht den Interrupt für diesen Pin, sondern für Pin 0, der auf der IO-4 Platine mit einer "0" gekennzeichnet ist. Für Pin 1 muss das so aussehen: io4.SetInterrupt(1 << 1) Dass es in deinen Tests dann doch funktioniert, wenn du in brickv auf den IO-4 Tab wechselst liegt dann daran, dass brickv in diesem Fall die Interrupts für alle Pins anmacht, also auch für Pin 1.

Der Vorschlag das Bricklet neu zu flashen ist ein Schuss ins Blaue, weil mit keine gute anderen Erklärung einfällt. Der GetInterrupt() Aufruf ist auch mehr ein Schuss ins Blaue. Dadurch wird das Problem nicht behoben werden. Interessant wäre aber, ob sich der Wert den du SetInterrupt() übergibst sich von dem unterscheidet, den dir GetInterrupt() zurück gibt. Die beiden sollten im Normalfall gleich sein. Wenn du in brickv den Tab des Bricklet anwählst werden die Interrupts für alle Pins aktiviert. Ist dein Problem vielleicht, dass dein Programm die Interrupts nicht richtig einstellt? Also SetInterrupt mit einem flaschen Wert aufruft und dann auf dem Pin auf dem du den Interrupt benutzen willst, der Interrupt gar nicht an ist? In brickv dann den Tab anzuwählen fixt das Problem, weil brickv immer die Interrupts für alle Pins anmacht. Teste mal in deinem Programm SetInterrupt(255) aufzurufen. Ich würde fast erwarten, dass das dein Problem löst.

Teste mal bitte diese kleine Script, es sollte "MSG_NOSIGNAL does NOT exist" ausgeben und sonst keine Fehler melden: use strict; use warnings; use Socket qw(MSG_NOSIGNAL); if (defined(&{"MSG_NOSIGNAL"})) { print "MSG_NOSIGNAL does exist\n"; } else { print "MSG_NOSIGNAL does NOT exist\n"; }

Interessant! MSG_NOSIGNAL macht also ein Problem. Die andere Meldung kommt daher, dass dein Thread::Queue Module nicht neu genug ist. Du brauchst mindestens Version 3.02. Das solltest du über CPAN updaten können: sudo cpan Thread::Queue

Komische Sache! Ruf doch mal nach dem SetInterrupt() in deinem Programm GetInterrupt() auf, um zu überprüfen ob der Interrupt auch wirklich aktiv ist. Hast du mal versucht das IO-4 Bricklet neu zu flashen?

Hrm, in Tinkerforge/IPConnection.pm stehen an drei Stellen Methodenaufruf mit MSG_NOSIGNAL als letzten Parameter. Ändere mal bitte alle drei ab indem du diesen Parameter entfernst und teste dann nochmal. Hier ein Beispiel: Vorher: $rc = $self->_get_local_socket()->send($packet, MSG_NOSIGNAL); Nachher: $rc = $self->_get_local_socket()->send($packet);

Steht auf jeder Seite der JavaScript Dokumentation, Zum Beispiel hier: http://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLight_Bricklet_JavaScript.html#api

Ich habe jetzt auch die Dokumentation der get_api_version() Funktion erweitert, um sie besser zu erklären.

setup.py und easy_install ist entweder oder. Die nächste Release der Bindings wird das tinkerforge.egg nicht mehr beinhalten, da diese Format mittlerweile deprecated ist und auch nicht gut funktioniert, wie du ja selbst siehst. Es wird in Zukunft nur noch "python setup.py install" und "pip install tinkerforge" geben, als Installationsoptionen. Wobei das ein entweder/oder Auswahl ist. Du muss nicht beides machen. Das geht aus der Dokumentation nicht wirklich gut hervor. Deswegen überarbeite ich die Installationsanleitungen aller Bindings auch gerade. Wenn "python setup.py install" für dich funktioniert, dann bleib dabei. Wenn du das nochmal ausführst sollte aus auch die kaputte easy_install Installation wieder retten können.

Da beide Aufrufe auf verschiedene Pins beziehen kommen sie sich nicht in die Quere. Der 2. Aufruf ändert nicht das Verhalten des schon laufenden Monoflops auf einem anderen Pin. Dein 1. Monoflop auf Pin 0 endet also nach 1,5s, wie vorgegeben.

Dann hast du wahrscheinlich pip nicht installiert, das nicht unbedingt standardmäßig bei Python dabei. Es lässt sich aber leicht nachinstallieren, siehe: https://pip.pypa.io/en/latest/installing.html

Die Bindings bieten keine Möglichkeit aus Python heraus zu bestimmen welche Release-Version es ist. Die Release-Version steht aber am Anfang der Brick und Bricklet Python Dateien in einem Kommentar. Wenn du die Bindings mit über pip installiert hast, dann kann dir pip sagen welchen Release-Version installiert ist. Bleibt die Rückfrage: Warum ist diese Information überhaupt interessant?

Loetkolben, das ist nicht die Protokoll-Version. Die kannst du nirgendwo direkt abfragen. wehnerc, das ist nicht die Release-Version der API Bindings. Die Bindings haben keine Funktion ihre Release-Version auszugeben. get_api_version() gibt die API Definitions-Version aus, die die gerade verwendeten API Bindings implementieren. Diese Versionsnummer ist recht nutzlos und die Funktion ist nur aus Gründen der Kompatibilität mit älteren Programmen noch da. Wir hätten sie beim Übergang von Protokoll-Version 1.0 auf 2.0 entfernen sollen, haben die Gelegenheit aber verpasst. Aus der API Definitions-Version kann man die Protokoll-Version ableiten, aber das war nicht deren Zweck. <Nachtrag> Die Protokoll-Version kann man natürlich auch aus der Release-Version der API Bindings und der Firmware ableiten. </Nachtrag> Hier gibt's also nichts zu sehen, bitte weitergehen

Nice cardboard construction 1) The black connector on the Stepper Brick will only supply the connected motor. There is no 5V regulator on the Brick to create 5V from the motor supply. You can use a Step-Down Power Supply and supply its black connector with up to 27V. The Step-Down Power Supply has a 5V regulator and will create 5V to supply the stack. It'll also forward the voltage you connected to its black connector to the Stepper Brick motor supply. So, if you want to supply the stack with 5V and the stepper motor from the same source then you need a Step-Down Power Supply at the bottom of the stack and feed its black connector. Without a Step-Down Power Supply you need to provide the 5V and the motor supply separately. 2) Sorry no clue, I'm going to leave this one for someone else 3) There should be no problem with calling enable()/disable() from a callback. Maybe you could show this portion of the code, so we can see how you're doing this?

Ahhhhh, jetzt weiß ich was los ist. Das ist ein Problem, dass im git schon behoben habe. Allerdings habe ich die Folgen diese Problems wohl nicht richtig beurteilt, sonst gäbe es schon brickd 2.1.1 in der es behoben wäre, sorry. Hier die Schritte den Patch dafür zu testen: cd brickd-2.1.0/src/brickd sudo apt-get install patch wget https://github.com/Tinkerforge/brickd/commit/442321f6d6619c0ff80770776f108d50dc53e6e2.patch patch -p3 < 442321f6d6619c0ff80770776f108d50dc53e6e2.patch CFLAGS=-g\ -ggdb make Dann kannst du wieder testen, das Problem sollte nicht mehr auftreten. Der Auslöser ist, dass der Client disconnected, wenn im Send Queue noch Antworten für den Client sind. In diesem Fall wird der Socket des Clients nicht richtig aus dem Event Loop entfernt. Was im Endeffekt dann dazu führt, dass Funktionen für einen Client aufgerufen werden, dessen Speicher schon längst freigegeben wurde => Crash. Es wird dann in Kürze eine neu brickd Version geben. Warum das Problem erst jetzt auftritt mag damit zusammenhängen, dass sich das Timing deines ganzen Aufbaus vielleicht etwas verändert hat, oder sich die Belastung etwas geändert hat, so dass es jetzt vorkommt, dass Clients disconnecten wenn brickd noch Antworten für sie hat.

Okay, da sind einige Invalid Reads zu erkennen im Valgrind Log. Leider kann Valgrind mit der brickd Version aus dem Debian Package keinen ordentlichen Backtrace erzeugen, so dass man sehen kann wo im Code das Problem ist. Daran hatte ich vorher nicht gedacht, sorry. Kannst du brickd selber kompilieren, so dass es Symbols usw. hat damit Valgrind besser anzeigen kann wo das Problem ist? Hier wie's geht: sudo apt-get install build-essential pkg-config libusb-1.0-0-dev libudev-dev pm-utils wget https://github.com/Tinkerforge/brickd/archive/v2.1.0.zip unzip v2.1.0.zip cd brickd-2.1.0/src/brickd CFLAGS=-g\ -ggdb make Danach liegt im aktuellen Verzeichnis der neue brickd. Und dann nochmal mit Valgrind: sudo valgrind --time-stamp=yes --log-file=valgrind.log ./brickd Zeitliche Zuordnung der Valgrind und brickd Ausgaben ist nicht unbedingt nötig, wenn Valgrind mir sagt wo im Code das Problem ist sollte das reichen, um es verstehen und beheben zu können. Aber es schadet nicht Valgrind einen Timestamp im Log ausgeben zu lassen. Der ist aber im Gegensatz zu brickd relative zur Startzeit von Valgrind.

Die Callbacks sind asynchron, wir verwenden dafür aber nicht process.nextTick(), denn wir verwendet die Callbacks der Socket Klasse. IPConnection.connect() erzeugt einen Socket, registriert zwei Funktionen für das Error und Connect Event und ruft dann Socket.connect() auf. Danach ist IPConnection.connect() durch und returned. Später ruft dann die Socket Klasse entweder die registrierte Error oder Connect Funktion auf vorauf hin die IPConnection entweder deine Error Funktion oder den Connected Callback aufruft. Alle Callbacks der Node.JS Bindings sind in dieser Weise an I/O Operationen gebunden. Alle I/O Operationen in Node.JS sind asynchron und die IPConnection nutzt das einfach. Wir brauchen kein process.nextTick() um asynchron Callbacks zu haben.

==24206== ERROR SUMMARY: 10000000 errors from 15 contexts (suppressed: 25 from 9) 10000000 Errors! Da ist irgendwas oberfaul. Es ist vom Aufbau von brickd her nicht möglich das diese Fehlermeldung zweimal für den gleichen Socket auftritt. Auch das es Fehlercode EBADF ist ist mit höchst Suspekt. Ich könnte mir vorstellen es reicht an einer Stelle passend eine der Datenstrukturen von brickd zu zerschreiben, dabei diese Problem zu erzeugen, den Rest aber weiterlaufen zu lassen. Starte Valgrind mal mit Logfile, damit dessen Ausgaben nicht in der Menge von brickd Meldungen verloren gehen: sudo valgrind --log-file=valgrind.log brickd