borg

Ich weiß nicht, so ein Adapter würde auf jeden Fall mehr kosten als ein USB Kabel. Siehe z.B. hier: https://www.sparkfun.com/products/10031

Hö? Ist doch alles gut! Den Master Brick flasht du über den Brick Reiter, wenn er im Bootloader ist (Erase gedrückt). Die Bricklets flasht du über den Bricklet Reiter, wenn der Master Brick _nicht_ im Bootloader ist . Das Windows dort eine "GPS Camera" erkennt ist OK, Hauptsache es erkennt den Master als serielle Schnittstelle (was es damit tut). Also bitte nochmal zurück auf V2, dann den Brick flashen (über den Brick Reiter). Dann den Brick neustarten (jetzt taucht er im Brickv auf) und dann über den Bricklet Reiter oder per Auto-Update die Bricklets flashen.

Öh, versuch mal alles zu aktualisieren, also zuerst brickd, dann brickv, dann den Master Brick. Dann sollte der Master Brick im Brickv erscheinen. Tut er das, ist auch der Bricklet Reiter nicht mehr ausgegraut . Dann solltest du auch direkt per "Auto-Update" die Bricklets aktualisieren können.

Alles klar, vielen Dank für die Hilfe! Ich hab Ruby Bindings 2.0.2 veröffentlicht, die sollten mit Ruby 1.9.3 "out of the box" funktionieren. Naja, das "<" bei "C<" bei einem unpack Aufruf ist überflüssig. In Ruby 1.9.1 wird das "<" einfach ignoriert, Ruby 1.9.3 schmeißt eine Exception. Vermutlich hat keiner der Ruby Entwickler daran gedacht, dass diese Änderung existieren Code brechen kann.

Bindings: Ruby 2.0.2 Remove "C<" from unpack (not allowed in Ruby 1.9.3) Download: Ruby

Bindings: Ruby 2.0.2 "C<" aus unpack Aufruf entfernt (nicht erlaubt in Ruby 1.9.3) Download: Ruby

Bei mir funktionierts: olaf@pc:~/build20/ruby$ ls example_simple.rb tinkerforge olaf@pc:~/build20/ruby$ cat example_simple.rb #!/usr/bin/env ruby # -*- ruby encoding: utf-8 -*- require 'tinkerforge/ip_connection' require 'tinkerforge/bricklet_distance_ir' include Tinkerforge HOST = 'localhost' PORT = 4223 UID = 'aUt' # Change to your UID ipcon = IPConnection.new # Create IP connection dir = BrickletDistanceIR.new UID, ipcon # Create device object ipcon.connect HOST, PORT # Connect to brickd # Don't use device before ipcon is connected # Get current distance (unit is mm) distance = dir.get_distance / 10.0 puts "Distance: #{distance} cm" puts 'Press key to exit' $stdin.gets olaf@pc:~/build20/ruby$ ruby1.9.1 -I. example_simple.rb Distance: 10.5 cm Press key to exit olaf@pc:~/build20/ruby$ Allerdings gibt es in der ruby Doku in der Tat kein "C<" als Argument für unpack: http://www.ruby-doc.org/core-1.9.3/String.html#method-i-unpack Da es bei 8bit Typen keinen unterschied zwischen little- und big-endian gibt, ist es dort auch nicht notwendig. Kannst du mal einmal testweise alle "C<" in der ip_connection.rb durch "C" ersetzen?

Ah, wir haben die Größe der UID von 64 auf 32 bit geändert mit dem neuen Protokoll. "distir" als UID ist einfach zu lang. Da fehlt einfach ein Check in Brickv, der Überprüft ob die UID valide ist. Baue ich gleich ein, ist dann in der nächsten Version mit drin. Danke für die Hilfe!

Mhhh, benutzt du vielleicht Protokoll 2.0 Beispiele zusammen mit Protokoll 1.0 brickv und firmwares? Hier gibt es Informationen zur Migration: http://www.tinkerforge.com/doc/Transitioning_Guide_1To2.html Edit: Hab das [Ruby] Prefix hinzugefügt .

Das macht in gewisser Weise Sinn. Das schreiben klappt nicht (die alte UID bleibt bestehen), dann liest er zum verifizieren die UID wieder aus. Da liest er dann wieder eine 1, da das auslesen auch nicht klappt und für ihn sieht es so aus als habe das schreiben funktioniert. Also wir können definitiv ausschließen, dass es sich um einen Hardwaredefekt handelt: Das Dual Relay funktioniert am Servo Brick und der Master funktioniert mit einem anderen Dual Relay (und er kann es auch flashen). Damit sollte sichergestellt sein, dass weder das "böse" Dual Relay noch der Master einen Hardwaredefekt haben. Richtig? Jetzt muss sich das "böse" Dual Relay ja irgendwie von dem funktionierenden unterscheiden, anders geht es ja nicht. Der einzige Unterschied kann der Inhalt des EEPROMs sein, alles andere ist ja Softwareseitig nicht veränderbar auf einem Dual Relay. So weit so gut. Nun versucht der neue Brick Viewer ein wenig Magie zu machen, um herauszubekommen ob ein Bicklet eine Firmware hat, die noch das alte Protokoll spricht (wird dann rot hinterlegt im Auto-Update Fenster). An dieser Stelle muss natürlich das EEPROM gelesen werden und hier könnte in Theorie irgendein Fehler existieren der zu Problemen führt. Bis hierhin macht alles noch Sinn. Jetzt kommt der kritische Teil: Wenn du jetzt hergehst und folgendes machst: * Nur den Master Brick anschließen. * Das Update/Flashing Fenster öffnen (jetzt wird versucht herauszubekommen ob sich 1.x.y Bricklets am Master befinden). * Dann erst das Bricklet anschließen und über den "Bricklet" Reiter flashen oder UID auslesen. Jetzt wurde vorher nie mit dem EEPROM kommuniziert und es wird ausschließlich der Code zum auslesen bzw schreiben des EEPROMs ausgeführt, der genauso auch auf dem Servo Brick ist und dort funktioniert. Nun sind auf einmal alle möglichen Fehlerquellen ausgeschlossen und es funktioniert trotzdem nicht. Wirklich komisch...

Kann es sein, dass der Master Brick und das Dual Relay Bricklet noch eine Version 1.x.y Firmware drauf hatte? Das würde erklären warum es erst nicht auftaucht (Protokoll nicht kompatibel) aber dann nachdem es neu geflasht wurde wieder auftaucht (Protokoll jetzt kompatibel). Das Dual Relay war dann entsprechend rot hinterlegt und musste auch aktualisiert werden.

Gut Ding will Weile haben .

Es hat sich herausgestellt, dass wir die Sockets unbedingt mit "TCP_NODELAY" konfigurieren müssen, da es sonst durch das verwendete Betriebssystem zu langen Latenzzeiten kommen kann (siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1306.msg8384.html). Wir konnten allerdings trotz längerer Suche nicht herausfinden wie man diese Einstellung in Delphi vornimmt. Für die anderen Sprachen gibt es hier einen Diff: https://github.com/Tinkerforge/generators/commit/2ddcb2b9cd6098e12900512397d9c60195c31f31 Und für FreePascal hier: https://github.com/Tinkerforge/generators/commit/db828091a7996ee69b775bdabd0ed00d7f48c251 Falls sich jemand von euch da auskennt, wären wir über sachdienliche Hinweise dankbar! Ein Link zur passenden Dokumentation o.ä. würde vermutlich schon reichen .

Step-Down Power Supply does not need flashing (it is completely analog). You can reflash the "voltage/distance mapping" of the Distance IR Bricklet if it got lost, thats no problem: http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#voltage-distance-mappings Good to hear that we got everything working and thank you for your help!

Wow! Das heißt wir hatten diesen "Bug" schon immer in den Bindings. Wer weiß wieviele Leute schon Probleme mit hohen Latenzzeiten hatten, sich aber einfach nicht gemeldet haben . Auf jeden Fall vielen Dank für die Hilfe und das Testen!

@Wumpus: Kannst du nochmal mit Brickv 2.0.1 versuchen die Bricklets zu flashen? Das wird damit leider immernoch nicht gehen, wir haben aber mehr Fehlermeldungen eingebaut um hoffentlich differenzieren zu können was dort passiert. Deine Probleme sind sowas von komisch, wir versuchen hier schon den ganzen Tag rauszubekommen was dort Sache ist. Vor allem da es mit dem Servo Brick geht, macht überhaupt keinen Sinn ! Monti scheint ja in dem anderem Thread ähnliche Probleme mit einem Distance IR zu haben (kann UID nicht ändern). Komisch ist, dass sich bzgl Bricklet flashen im Prinzip nichts geändert hat zwischen den Protokollversionen .

Plugins: LCD20x4 Bricklet 2.0.1, LCD16x2 Bricklet 2.0.1 Bindings: C/C++ 2.0.1, C# 2.0.1, Delphi 2.0.1, Java 2.0.1, PHP 2.0.1, Python 2.0.1, Ruby 2.0.1 Unterstützung für benutzerdefinierte Buchstaben für LCD20x4 und LCD16x2 Bricklet hinzugefügt. Download Plugin:LCD20x4 Bricklet, LCD16x2 Bricklet Download Bindings: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Plugins: LCD20x4 Bricklet 2.0.1, LCD16x2 Bricklet 2.0.1 Bindings: C/C++ 2.0.1, C# 2.0.1, Delphi 2.0.1, Java 2.0.1, PHP 2.0.1, Python 2.0.1, Ruby 2.0.1 Add custom character support for LCD20x4 and LCD16x2 Bricklet Download Plugin:LCD20x4 Bricklet, LCD16x2 Bricklet Download Bindings: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Definitely! There is version information for the languages here: http://www.tinkerforge.com/doc/Software/API_Bindings.html#java But it is a little bit scattered there. Operating systems: Windows: XP and above, Linux: you need libusb1, Mac OS X: We are currently working on that (see your other thread). Where could i add it more centraly? Probably on the downloads page? http://www.tinkerforge.com/doc/Downloads.html

Sure, you can do that with the enumeration callback, see here: http://www.tinkerforge.com/doc/Tutorials/Tutorial_Rugged/Tutorial.html#c Note: This tutorial is for protocol 2.0, i don't know if you already updates the tools and your Bricks/Bricklets to the new protocol.

The problem has to do with the gcc configuration, with nearly 100% certainty. The code itself can't have an "illigal instruction". So you should look at the Makefile. MD5s:

Aber auslesen geht? Und sonst funktioniert alles oder kannst du ein neues Plugin auch nicht schreiben?

Everything we do is Open Source, you can find everything at github: https://github.com/Tinkerforge The Brick Daemon code is here: https://github.com/Tinkerforge/brickd/tree/master/src/brickd Did you try the new .dmg that photron made?

Which IP should brickv use to test it? We can't disable the connect button, since we don't know which IP you want to connect to .

Sind die Beinchen im Bricklet-Stecker OK? http://www.tinkerforge.com/doc/FAQ.html#mein-brick-wird-heiss Ansonsten würde ich erstmal klein Anfangen: Nur den Master Brick anschließen: Taucht er vernünftig als Master Brick mit Firmware 2.0 auf? Wenn ja, mit Dual Relay probieren. Wenn dann der Master Brick nicht im Brick Viewer erscheint ist vermutlich die Firmware irgendwie defekt (vielleicht hat das Flashen nicht geklappt). In dem Fall zuerst den Master Brick starten und dann das Dual Relay anschließen. Dann nochmal versuchen über den "Bricklet" Tab zu flashen. Wenn als UID 1 zurückgegeben wird, kann eine neue geschrieben werden?