photron

Plugins: IO-16 Bricklet 1.1.3

• Avoid useless I2C reads during monoflop handling
  

Download Plugins: IO-16 Bricklet

Plugins: IO-16 Bricklet 1.1.3

• Unnötige I2C Leseoperartion während Monoflopbehandlung vermieden
  

Download Plugins: IO-16 Bricklet

Ah, das war mir nicht bewusst, dass da C# XML Doku geht. Ist auf die TODO Liste gesetzt.

Erstmal wundert es mich noch mehr, dass du angeblich brickd downgraden musst damit es wieder funktioniert. Bist du sicher, dass Master Firmware 1.2.4 (aktuell), IO-4 Firmware 1.1.0 (alt) und brickd 1.0.9 (aktuell) nicht zusammen funktionieren und Interrupt richtig geht?

Wenn du deinen Code nicht vorzeigen kannst, kannst du dann mit dem Interrupt Example der IO-4 testen ob das Problem da auch auftritt?

Wie ist denn dein Stack aufgebaut, was ist da alles drin?

Video wird nicht nötig ein.

Bei mir funktioniert der Interrupt immer in allen meinen Tests.

Welche Master Firmware verwendest du? Falls es nicht 1.2.4 ist, dann teste bitte nochmal mit aktueller Master Firmware.

Falls das auch nicht hilft muss du mir mal deinen Aufbau genauer beschreiben, am besten plus Beipsielprogramm, dass das Problem demonstriert, da ich es wie gesagt nicht reproduzieren kann.

Was meinst du mit BrickD Treiber? Brick Daemon 1.0.9?

Für dein spezielles Problem schlage ich folgenden Workaround vor: Du kannst von Bricklet die UID im Flashing Fenster auslesen und so zwischen Port und angeschlossenem Bricklet matchen.

Du meinst vorher den Load Button im Flash-Fenster drücken, um die UID zu anzuzeigen und dann diese mit den Viewer-Angaben vergleichen ?

Richtig, für Ports die ein Brick hardwäremäßig nicht hat bekommst du eine Fehlermeldung, für Ports an denen kein Bricklet hängt typischerweise eine UID von 1 und für Ports an denen ein Bricklet hängt deren UID. Diese kannst du dann mit der UID in der Device Tabelle vergleichen.

1) Autom. Enable des Steppers beim Anklicken des Card-Reiters

Das stimmt so nicht. Brickv aktiviert den Stepper nicht von sich aus. Aber es zeigt an wenn der Stepper schon aktiviert ist. Dass heißt wenn du in Brickv (oder sonst wie) den Stepper aktivierst, dann einmal Disconnect und wieder Connect klickst, dann wird dir Brickv nach dem Connect anzeigen, dass der Stepper immer noch aktiv ist, denn du hast ihn ja zuvor aktiviert. Das ab- und anwählen des Stepper Tabs geht nicht mit einer De- bzw. Aktivierung des Stepper Bricks einher.

2) Beim Einspielen der FW prüfen ob der richtige Typ am richtigen Port hängt

Das ist nicht so einfach möglich. Ein Brick kann nicht immer feststellen was an welchem Bricklet Port hängt. Falls ein Bricklet richtig geflasht ist ginge es. Wir haben auf der großen TODO Liste auch ein verbessertes Enumerate, dass Topologie Information mitteilen kann.

Für dein spezielles Problem schlage ich folgenden Workaround vor: Du kannst von Bricklet die UID im Flashing Fenster auslesen und so zwischen Port und angeschlossenem Bricklet matchen.

Der Brick, der hat den Prozessor. Das heißt für den Fall, dass sich der Brick selbst aufhängt hilft Monoflop nicht.

OnMonoflopDone wird nur aufgerufen, wenn der Timer des Monoflop auch wirklich abgelaufen ist, der Monoflop also zurückspring.

Wenn du den Monoflop für einen Pin immer wieder erneuerst bevor der Timer abgelaufen ist, dann behält dieser Pin seinen Zustand und OnMonoflopDone wird nicht ständig aufgerufen. Erst wenn du aufhörst den Monoflop zu erneuern und der Timer wirklich abläuft springt der Monoflop zurück und OnMonoflopDone wird aufgerufen.

Und ja, ein Anwendungsfall ist, dass du einen Pin z.B. auf High setzen willst, aber auch sichergehen willst dass der Pin von selbst auf Low zurück geht wenn z.B. die Chibi Verbinding zum Slave an dem das IO Bricklet hängt abreißt.

Korrigierte Bindings sind verfügbar.

Das Problem lag an einer Race Condition in der add_device Funktion. Das sleep hat die Race Condition aufgehoben.

In den aktuellen Bindings ist das Problem korrigiert.

Bindings: C/C++ 1.0.18, C# 1.1.10, Delphi 1.0.2, Java 1.0.16, PHP 1.0.11, Python 1.0.19, Ruby 1.0.8

Plugins: IO-4 Bricklet 1.1.1, IO-16 Bricklet 1.1.2

Brick Viewer 1.1.6

• Fix race condition in bindings function add_device
  
• Add monoflop functionality to IO-4 and IO-16 Bricklet
  
• Display chip temperature in Brick Viewer
  

Download Bindings: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Download Plugins: IO-4 Bricklet, IO-16 Bricklet

Download Brick Viewer: Windows, Linux, Mac OS X

Bindings: C/C++ 1.0.18, C# 1.1.10, Delphi 1.0.2, Java 1.0.16, PHP 1.0.11, Python 1.0.19, Ruby 1.0.8

Plugins: IO-4 Bricklet 1.1.1, IO-16 Bricklet 1.1.2

Brick Viewer 1.1.6

• Race Condition in Bindings Funktion add_device korrigiert
  
• Monoflop Funktionalität für IO-4 und IO-16 hinzugefügt
  
• Chip Temperatur wird nun im Brick Viewer angezeigt
  

Download Bindings: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Download Plugins: IO-4 Bricklet, IO-16 Bricklet

Download Brick Viewer: Windows, Linux, Mac OS X

The possibility to connect external buttons is on our change list for the next version of the LCD Bricklet.

This change was suggested in the German board a while ago.

Mit Master Firmware 1.2.2 gingen die Buttons noch?

Wir sind da gerade einem Problem auf der Spur in Firmware 1.2.3, das könnte damit zusammenhängen. Sollte also in kürze eine neue Version geben, die das Problem beheben könnte.

Frage an photron (wahlweise TF): Mindestens in den C#-Bindings besteht der gleiche Fehler... unabhängig davon ob es in diesem Foren-Thread die Ursache ist, sollte er denke ich überall gefixed werden.

Richtig, das Problem bestand in allen Bindings und ich habe gerade den Fix committed. Neue Binding Releases gibt es morgen, denke ich.

Problem scheint gelöst: Ich hatte es nur an zwei verschiedenen USB3.0/2.0 Kombiports ausprobiert. An einem reinen USB2.0 Port ging es.

Das Problem war hier softwareseitig in brickd. Die aktuelle Brick Daemon Version 1.0.9 funktioniert jetzt auch mit USB 3.0.

Corius, das USB 3.0 nicht funktionierte lag daran, dass die Hersteller wie Intel und NEC/Renesas ihre USB 3.0 Controller nicht unter USB in Windows einsortieren sondern unter IUSB3 bzw NUSB3. Dadurch konnte libusb sie nicht finden, da es USB Hubs unter der USB Kategorie erwartet.

Brick Daemon 1.0.9 bringt für Windows eine neue libusb Version mit, die Workarounds für diese USB 3.0 Controller enthält. Dadurch werden Bricks jetzt auch gefunden wenn sie an USB 3.0 angeschlossen sind.

The_Real_Black, die Stabilität sollte mit Brick Daemon 1.0.9 jetzt auch besser geworden sein, da ich die Verwendung von libusb in brickd etwas verändert habe um mit hot-unplug besser umgehen zu können.

Brick Daemon 1.0.9

• Reduce Windows and Mac OS installer size
  
• Avoid race condition when enumerating USB devices on Linux
  
• Use more expressive log file name and correct line endings on Windows
  
• Don't cancel pending USB transfers to avoid segfault in libusb on Linux
  
• Update libusb to make USB 3.0 work on Windows
  

Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.9

• Windows and Mac OS Installer Dateigröße reduziert
  
• Race Condition beim Auflisten von USB Geräten unter Linux korrigiert
  
• Logdatei besser benannt und richtige Zeilenenden unter Windows verwendet
  
• Wartenden USB Transfers beim Schließen eines USB Gerätes vorläufig nicht mehr abbrechen um Crash in libusb zu vermeiden
  
• libusb aktualisiert, USB 3.0 funktioniert nun unter Windows
  

Downloads: Windows, Linux, Mac OS X

frankiefoo, kannst du brickv mal in gdb starten um zum segfault einen Backtrace zubekommen? Dann können wir sehen was ihn verursacht und stochern hier nicht länger im Trüben.

Der Kreis, der in brickv im Koordinatenkreuz die Position anzeigt, wird gefüllt gezeichnet wenn du den Knopf des Joysticks drückst.

Mal ein Wort zu der Sprach der Website und Dokumentation. Natürlich steht auf unserer großen TODO Liste auch drauf, dass wir die Website und Dokumentation auch in Deutsch haben wollen. Nur das ist nicht mal eben gemacht, dazu muss erstmal alles was noch nicht in Deutsch verfügbar ist übersetzt werden.

Wer uns da helfen möchte, ein einfacher Ansatzpunkt ist die API Dokumentation. Diese wird aus Config Dateien generiert. Das Configformat unterstützt schon mehrsprachige Dokumentation. Im Moment ist da nur Englisch drin. Das ganze findet sich auf Github

https://github.com/Tinkerforge/generators

im Unterverzeichnis configs. Wer also Spass am Übersetzen hat kann sich das Repository clonen, deutsche Dokumentation einfügen und einen Pull-Request machen

Hm, in der Stepper Firmware 1.1.8 steht wirklich 1.1.7 drin. wir korrigieren das.

Zum Joystick, es funktioniert also nur der Pressed/Released Callback nicht? Der Rest wie z.B. der Position Callback geht aber?

Der Ausgabewert des Rotary Potis ist fest -150 bis 150. Wenn du da jetzt gerne nur positive Werte haben willst dann kannst du in deinem Programm einfach fest 150 auf den Wert addieren. Dadurch bekommst du einen Wert der von 0 bis 300 geht.