photron

Du mischt da definitiv verschieden Bindings Version. Deine ip_connection.h kommt aus Version 1.0.6 oder älter und dein brick_imu.c kommt aus Version 1.0.7 oder neuer. Dass das nicht richtig funktionieren kann, wenn du da einfach dem struct ein Feld hinzufügst ist eigentlich klar Stell mal bitte sicher, dass du alle Dateien aus einer Bindings Version verwendest und am besten dann auch die neuste: http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_1_0_10.zip

Also hier funktioniert das mit /TP auf Projektebene setzen. Zu dem function_id Fehler: Mischt du ip_connection.h und brick_imu.c aus verschiedenen C/C++ Bindings Versionen?

Sicher bleibt das Open Source, wie alles hier. Du kannst alle Software hier finden: https://github.com/Tinkerforge Der Bindings Generator im speziellen ist hier: https://github.com/Tinkerforge/generators

Wir verwenden C nach C99 Standard, Visual Studio kann aber nur C89. Daher musst du Visual Studio sagen den Code als C++ zu kompilieren. Wie das geht steht hier am Ende: http://www.tinkerforge.com/doc/Software/API_Bindings.html#c-c

Committed ist (soweit ich das sehe) der Speicher den die Prozesse wirklich angefordert haben. Aber das ist nicht der Speicher den sie wirklich auch belegen. Daher kann das auch mehr sein als RAM und Swap zusammen gerade belegt sind. Committed ist also nicht der richtige Wert zur Beurteilung des Speicherverbrauchs von brickd. Dazu solltest du dir das Resident Set (RSS) von brickd ansehen. Das Resident Set ist der Teil des Virtuellen Speichers eines Prozesses der wirklich im physikalischen RAM liegt. Zusätzlich solltest du auch noch den Swap Wert des brickd Prozesses ansehen. Beides ist unter /proc/<brickd PID>/status als VmRSS und VmSwap zu finden. Bei mir liegt VmRSS + VmSwap bei ca. 15MB und steigt bei jedem Brick Reset oder neu verbundenen Brick um ein paar kB. Ja den Übergang meine ich. Und ich habe gesagt, dass mir die grüne Linie komisch vorkommt, "denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen." 15MB kamen mir zuviel vor, aber ich habe die Achse falsch gelesen und der Sprung zwischen 6 und 7 ist nur 7MB hoch. Aber dennoch ist mir das komisch, denn ich kann das hier nicht reproduzieren. Solange es läuft ist doch gut, lass es laufen Es gibt noch ein potentielles Problem in den Bindings, dass wenn Packets nicht in einem Stück ankommen sie nicht richtig behandelt werden, was aber im allgemeinen nicht passiert. Diese habe ich in brickd Version 1.0.7 behoben und werde es in den nächsten Tagen auch in allen Bindings beheben.

Ich hab mir deine Lua Bindings gerade angesehen und das sieht sehr gut aus Ich würde hier ähnlich vorgehen wollen wie bei den Delphi Bindings. Hier hat Nic schon die Vorarbeit geleistet und die IPConnection implementiert und einige Bricks und Bricklets. Auf dieser Basis werde ich Delphi Bindings in unser Bindings Generator System einbauen. Ich würde also aufbauen auf deine manuell geschriebenen Bindings unser Bindings Generator System für Lua erweitern wollen, wenn du da nichts gehen hast

Loetkolben, mir ist bei deiner Munin Speicher Grafik nicht ganz klar was die grüne Linie darstellt und welche Achsenskalierung dazugehört. Denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen. Ja, brickd 1.0.7 belegt im Moment bei jedem Anschließen eines Bricks so ca. 100kB mehr Speicher. Da ist also ein Memoryleak. Ich bin dem ganzen aber auf der Spur. Was deinen Eindruck mit mehr "unused" Speicher nach der Installation von brickd 1.0.7 angeht, so sieht das für mich einfach nach Flushen des Filesystem Caches in deiner Grafik aus.

Im Prinzip gibts config.py auch auf Windows, allerdings ist es nicht als editierbare Datei verfügbar, wenn du Brick[dv] per Installer installierst. Bessere Konfigurierbarkeit des Loggings und einfaches Ablesen der Versionsnummer sowie Dokumentation des ganzen steht auf der Todoliste

Loetkolben, brickd schreibt ein Log unter /var/log/brickd.log. Allerdings landen da standardmässig nur Errors. Das Log Level kannst du in src/brickd/config.py einstellen. LOGGING_LEVEL = logging.DEBUG aktiviert alle Log Ausgaben. Wenn du brickd per Debian Package installiert hast findet sich die Datei unter /usr/share/brickd/config.py

Wie AuronX sagt scheitert Reset per Software daran das eben diese Software ja hängt. Loetkolben, der struct.error: unpack requires a string argument of length 2 kommt durch dadurch wenn im brickd ein Packet in mehreren Teilen ankommt. Dass das passieren kann wurde bisher in brickd ignoriert. In brickd Version 1.0.7 ist das jetzt behoben.

Der Syntaxfehler auf Windows ist in Ruby Bindings Version 1.0.1 behoben.

Erstmal zum Syntaxfehler, der tritt nur unter Windows auf und hat mit der Block Syntax zu tun, die ich da verwenden. Unter Linux (Ruby 1.9.2) funktioniert lcd.register_callback BrickletLCD20x4::CALLBACK_BUTTON_PRESSED, do |i| puts "Pressed: #{i}" end unter Windows muss es aber lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| puts "Pressed: #{i}" end sein, warum auch immer. Ich werde das in der nächsten Release der Ruby bindings beheben. Dein eigentliches Problem ist aber folgendes: Die folgenden Zeilen sind kein gültiger Ruby Code: if lcd.register_callback BrickletLCD20x4::CALLBACK_BUTTON_RELEASED == 1 lcd.write_line 1,0, 'released 1' end register_callback erwartet eine Callback ID als int (z.B. BrickletLCD20x4::CALLBACK_BUTTON_RELEASED) und einen Block (do |...| ... end) Du verwendest es aber als wäre es ein Getter, das funktioniert nicht. Eine richtige Verwendung von register_callback sieht z.B. so aus: lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| puts "Pressed: #{i}" end Callback heißt, du übergibst der register_callback Methode einen Block und der wird immer dann ausgeführt wenn ein Callback vom Bricklet ankommt ohne weiteres Zutun von deiner Seite. Callback bedeutet nicht, dass du aktiv in einer Schleife immer wieder fragst ob etwas passiert ist, das nennt mal Polling. Und genau das tut dein Beispiel im Prinzip. Wenn ich deinen Code richtig verstehe willst du solange auf Button 1 reagieren bis Button 2 ein mal gedrückt wurde. Das kann man wie folgt tun: sync = Queue.new # register block for button pressed callback lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_PRESSED) do |i| # if it's button 1 write a line if i == 1 lcd.write_line 1, 0, 'pressed 1 ' end end # register block for button released callback lcd.register_callback(BrickletLCD20x4::CALLBACK_BUTTON_RELEASED) do |i| # if it's button 1 write a line if i == 1 lcd.write_line 1, 0, 'released 1' # if it's button 2 push something to the queue so the pop below returns elsif i == 2 sync.push nil end end # block until there is something to pop sync.pop ipcon.destroy Ich benutze hier eine Queue als Synchronisationsmittel damit das Programm so lange am sync.pop steht bis Button 2 gedrückt wurde.

Okay, das Read kann eigentlich nur mit einem Timeout fehlschalgen. Tust du mit dem Brick noch sonst etwas während du das Bricklet flashed? Falls du den Brick stark mit anderen Aufgaben beschäftigst kann es sein, dass das Schreiben des Plugins noch im Gange ist wenn Brickv schon wieder versucht es zu lesen und das Lesen bekommt dann einen Timeout. Falls dein Brick an dem das Bricklet hängt sonst nichts tut, dann kannst du versuchen die Wartezeit zwischen Schreiben und Lesen zu erhöhen. Im Moment sind das 2 Sekunden und eigentlich sollte das auch reichen. In src/brickv/flashing.py in Zeile 438 und 452 steht jeweils ein time.sleep(1). Da kannst du versuchen die Zeit höher zu setzen, z.B. time.sleep(3) oder noch länger.

Dass bcmath benötigt wird steht auch schon ein paar Tage hier: http://www.tinkerforge.com/doc/Software/API_Bindings.html#php Technischer Hintergrund: bcmath wird benötigt um die UID von Base58 in einen 64bit Integer zu konvertieren. Da PHP Zahlen inter als 32bit Integer oder Float darstellt und das beides nicht groß genug ist für einen 64bit Integer.

Wumpus, ich habe gerade die Fehlermedlung beim Bricklet flashen detaillierter gemacht. Du sagtest du hättest deine Version per git geclont. Kannst du die Änderung pullen und noch mal testen? Es ist sehr unerwartet dass das Flashen mal geht und mal nicht geht.

Welche Fehlermeldung bzw. Ausgabe in der Konsole hast du denn wenn das Flashen eines Bricklets nicht funktioniert? Und ja du musst den Brick erst per Erase Knöpfchen gedrückt halten beim Anstecken in den Bootloader bringen. Dann im Flashing Dialog auf dem Brick Tab den Refresh Button klicken. Jetzt sollte in der Serial Port Dropdownbox sowas wie /dev/ttyACM0 stehen. Das ist der Brick im Bootloader. Passenden Firmware auswählen und Save klicken.

Nein, der Code ist nicht für G++ optimiert. Der C Code baucht C99 und Visual Studio kann nur C89. Der Workaround ist bei cl.exe die /TP Option mitzugeben, die dem Compiler sagt den Code als C++ zu kompilieren. cl /TP example.c

"Temperature-IR" mir Bindestrich ist noch ein altes Format. Eigentlich hätte das "Temperature IR" sein sollen, auch in der Firmware. Damit die neuen Bindings die jetzt auch den Device Typ prüfen auch noch mit dem alten "Temperature-IR" funktionieren.

Ich hab mir gerade eine USB3 Steckkarte (LogiLink PC0054) eingebaut und unter Linux (Ubuntu) funktioniert das problemlos.

tex, ich arbeite im Moment nicht an Perl Bindings und mir ist auch noch nicht zu Ohren gekommen, dass sonst jemand daran arbeiten würde. Also kannst du ruhig daran arbeiten wenn dir danach ist. Nic, richtig, die Ruby Bindings sind heute fertig geworden. Als nächstes sind Delphi Bindings dran. Ich werde mir dazu zunächst mal deinen Prototypen ansehen und wohl darauf aufbauen, wenn du nichts dagegen hast

Ruby Bindings sind da! http://www.tinkerforge.com/doc/Software/IPConnection_Ruby.html http://download.tinkerforge.com/bindings/ruby/tinkerforge_ruby_bindings_latest.zip Als nächstes kommen Delphi Bindings, wahrscheinlich aufbauend auf Nics Prototypen: http://www.tinkerunity.org/forum/index.php/topic,444.msg2314.html

Du hast da einen Bug in den Python Bindings gefunden (cannot join current thread). Der ist jetzt in Version 1.0.11 behoben. Das ist aber nicht dein eigentliches Problem, sondern nur ein Nebeneffekt. Teste doch noch mal bitte mit den aktuellen Python Bindings. Was mir noch in deinem Code auffällt: Du registrierst den Callback für den Interrupt bevor du das DC Brick Objekt erzeugst. Du greifst aber im Callback auf die dco Variable zu. Es kann also passieren dass ein Callback kommt bevor die dco Variable richtig gesetzt wurde. Mit anderen Worten: Änder doch mal bitte die Reihenfolge von io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection zu dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) einfach um da auf der sicheren Seite zu sein. Oder prüfe im Callback ob dco != None ist bevor du es verwendest.

In den aktuellen Bindings Versionen (C/C++ 1.0.8, C# 1.1.2, Java 1.0.8, PHP 1.0.3 und Python 1.0.9) wird jetzt auch der Device Typ überprüft. Für einen erfolgreichen AddDevice Aufruf muss jetzt ein Device mit passendem Typ und UID antworten.

Okay, dieses Python 3 Problem ist in Python Bindings 1.0.8 jetzt behoben.

Ich habe jetzt die Beispiele in der TCP/IP Dokumentation noch etwas mehr mit den Typen der Bestandteile eines Packets versehen und ein weiters Beispiel für die kurze UID eines Bricklets hinzugefügt.