ts555

Ja super - mit der neuen Version 2.0.2 funktioniert das einwandfrei 😀👍 Werde damit nun wieder meine Messungen starten, die über mehrere Tage gehen. Bin aber sehr zuversichtlich, dass die nun durchlaufen und keine Fehler mehr auftreten werden. Danke für Deine schnelle Hilfe!

Bei mir genügt schon ein kurzes Berühren der SCL-Leitung (am 2k2 Pull-Up Widerstand am Platinenrand / Pin 4 des ICs) mit einer Pinzette. Die SDA-Leitung scheint weniger "empfindlich" zu sein. Hier passiert bei einer Berührung nichts. Was ansonsten zuverlässig funktioniert: Die SCL oder die SDA Leitung kurz mit GND verbinden.

Ich habe den LTR329ALS Lichtsensor mit einem kurzen Kabel abgesetzt vom Bricklet montiert. Dabei ist mir Folgendes aufgefallen (mit Oszi gemessen): Eine kurze Beeinflussung/Störung/Unterbrechung der I2C-Kommunikation führt dazu, dass die I2C-Kommunikation permanent stehen bleibt. Auch wenn man dann im Brick Viewer die "Illuminance Range" oder die "Integration Time" umstellt, tut sich auf dem I2C Bus nichts mehr (keinerlei SDA/SCL Signale mehr messbar). Im Brick Viewer erhält man währenddessen jedoch keine Rückmeldung über den Fehlerzustand und es wird permanent der zuletzt gemessene Helligkeitswert angezeigt. Nur durch einen Bricklet-Reset kommt man wieder in den funktionierenden Zustand zurück. Ich glaube in der Firmware sind aber eigentlich Timeouts etc. vorgesehen, um Fehler durch nicht antwortende I2C-Slaves abzufangen? Wie könnte man die Firmware am sinnvollsten anpassen, sodass die I2C-Kommunikation nach einer Störung weiterläuft - oder, dass zumindest der Fehlerzustand erkannt werden kann (z.B. durch Senden eines Fehlerersatzwertes anstatt letztem Helligkeitswert nach I2C-Timeout)?

Das Auftauchen und Verschwinden der Bricks an USB ist bisher nur in Verbindung mit USB-Hubs aufgetreten. Ob die Meldung bzgl. ungültigem Paket auch ohne USB-Hub auftritt habe ich noch nicht getestet. Der Stack funktioniert trotz Invalid-UID Meldung. Ich glaube ich habe tatsächlich ein Problem mit meiner USB-(Steck)verbindung. Anbei ein kurzes Protokoll von heute. - Minute 42: brickd gestartet, Stack läuft - Minute 46: Verbindung zum Stack plötzlich getrennt (ohne äußeres Zutun) - Minute 48: USB-Stecker am Laptop minimal bewegt -> Stack wieder verbunden! (allerdings fehlt Master auf Pos 2) - Minute 51: Stack-Reset manuell ausgelöst -> Stack komplett wieder verfügbar Bei Gelegenheit sollte ich vielleicht mal die USB D+ und D- Signale mit dem Oszi monitoren, die am Stack bzw. USB-Hub ankommen... Aber entscheidend ist ja: Der neue brickd ist bisher nicht mehr abgestürzt. Werde den die nächsten Tage/Wochen mit GDB weiter testen. console 06-07-2021.txt

Habe es nochmal probiert. Jetzt funktioniert es. Ich weiß nicht, was beim letzten mal passiert ist... Ich hatte jetzt sogleich wieder einen Fall, wo sich die Bricks (ohne äußeres Zutun) zyklisch an- und abgemeldet haben. So wie es aussieht führt dies nun aber nicht mehr zum Absturz des neuen brickd. Im Anhang eine Kopie der Konsolenausgabe. brickd-debug.log Hast Du eine Idee, was die Ursache für die Fehlermeldungen sein könnte (invalid response packet/invalid UID)? console.txt

Nachdem ich die letzten Wochen leider keine Zeit hatte, kann ich die neue Version von heute an nun endlich testen. Bei der neuen Version werden folgende Meldungen ausgegeben; Verbindung zu TF-Mastern wird nicht hergestellt:

Ja ich kann das gerne nochmal testen.

Im Anhang nun mal ein GDB Absturzprotokoll. Was in diesem Fall passiert ist: Ich habe manchmal ein Problem mit der USB-Verbindung an sich. Es kann vorkommen, dass sich die USB-Geräte (also HUB mit Master) nach dem Anstecken an den PC zyklisch an- und abmelden. Das wiederholt sich dann beliebig oft ohne äußeres Zutun. Im Win10 Gerätemanager baut sich dann der Gerätebaum ca. alle 2-3 Sekunden neu auf und auch in der Windows-Startleiste rechts unten "blinkt" das USB-Symbol für ein neu erkanntes Gerät mit der selben Frequenz auf... Ich habe noch nicht herausgefunden, ob die Ursache hard- oder softwareseitig zu suchen ist (schlechte USB-Steckerverbindung oder doch eher Firmware-/Treiber-/Windows-Problem etc.?). Jedenfalls scheint in diesem besonderen Fehlerszenario der brickd laut den GDB-Ausgaben etwas "hinterherzuhinken". D.h. er bekommt die vielen "hochfrequenten" An- und Abmeldevorgänge nicht in vollständiger Anzahl sondern nur sporadisch mit. Vielleicht erfolgen dadurch Zugriffsversuche auf schon wieder nicht mehr vorhandene Geräte? gdb_bt_full_2021_04_09.txt

Mit GDB habe ich noch keine Erfahrung. Aber ich kann das gerne versuchen...

Danke! Ich habe die Version heute gleich ausprobiert. Das Abziehen des USB-Hubs wird nun immer erkannt. Allerdings sind dann beim Testen sporadisch andere Fehler aufgetreten, die ich mir nicht richtig erklären bzw. nicht reproduzieren konnte. Wie ich nun gemerkt habe, ist das wohl zum Teil auf einen Wackelkontakt am USB-Stecker zurückzuführen (zu viele Steckzyklen 🙄). Im Anhang ist aber ein Protokoll von einem Fehlerfall, der dazu führte, dass sich der Brick Daemon verabschiedet hat. Vielleicht findest Du Hinweise auf was das zurückzuführen sein könnte? Das kommt nur sehr selten vor, aber ich weiß in diesem auch Fall nicht, wie man den Daemon manuell wieder neu startet? Ich habe darauf hin den PC neu gestartet. (Zum Protokoll: Ich hatte da zwei separate Stapel zum Test wechselweise an- und abgesteckt - jeweils mit USB-Hub. Am USB Hub des 6rkehm-Masters waren hierbei noch andere USB-Geräte angeschlossen, u.a. FTDI RS232).brickd_live_20210316_160155.log

Hallo photron, hattest Du schon Zeit, Dich dem brickd zu widmen - bzgl. dem Enumerate-Disconnect Callback Thema?

Ja wäre super, wenn das verbessert werden könnte 👍

Hier zum Vergleich noch ein Log zu einem erfolgreichen Trennvorgang (trotz USB-Hub). Wieder mit Zeitangaben: 14:05:50 - Klick auf "Connect" im Brick Viewer 14:06:00 - USB-Hub angesteckt 14:06:10 - USB-Hub abgesteckt 14:06:20 - Klick auf "Disconnect" im Brick Viewer brickd_live_20210114_140805.log

Ich das jetzt mal so gemacht - allerdings noch mit parallel geöffnetem Brick Viewer, um sehen zu können, ob ich so einen Fehlerfall erwische. Zu folgenden Zeitpunkten habe ich Aktionen durchgeführt (vgl. Anhang): 13:26:30 - Klick auf "Connect" im Brick Viewer 13:26:40 - USB-Hub angesteckt 13:26:50 - USB-Hub abgesteckt 13:27:00 - Klick auf "Disconnect" im Brick Viewer Man kann erkennen, dass die Trennung vom Master Brick [6rkehm] eigentlich erkannt wurde? Im Brick Viewer blieb der Reiter "Master Brick 2.1" nach 13:26:50 aber offen... brickd_live_20210114_132710.log

Windows 10 Im Windows-Gerätemanager wird beim An-/Abstecken alles fehlerfrei an- und abgemeldet...

Hallo, mit folgendem Aufbau lässt sich ein Problem reproduzieren, dass ich erst kürzlich entdeckt habe: Ein Master Brick ist über einen USB2.0-Hub mit der USB-Schnittstelle eines PCs verbunden: PC <--> USB2.0-HUB <--> Master Brick (FW 2.4.10) Verwendet wird der Versionsstand Brick Deamon V2.4.3 und Brick Viewer V2.4.16. Im Brick Viewer wird eine Verbindung hergestellt und es erscheint ein Reiter "Master Brick 2.1". a) Wenn man nun die USB-Verbindung zwischen Master Brick und USB-Hub trennt, dann verschwindet im Brick Viewer der Reiter "Master Brick 2.1" automatisch. Nach erneutem Anstecken des USB-Kabels an den USB-Hub taucht der Reiter "Master Brick 2.1" automatisch wieder auf - so wie es sein soll. b) Wenn man die Verbindung zwischen PC und USB-Hub trennt, wird dies vom Brick Viewer (in den allermeisten Fällen) nicht erkannt. Der Reiter "Master Brick 2.1" bleibt bestehen. Alle set-Funktionen können ohne Fehlermeldung ausgeführt werden, obwohl der Brick gar nicht mehr angeschlossen ist! Nach erneutem Anstecken des USB-Hubs (inkl. Master Brick) an den PC wird zwar ein Connect-Callback/Enumerate ausgelöst, sodass der Master Brick dann auch wieder weiter läuft, aber die Trennung sollte ja auch erkannt werden. Woran könnte es liegen, dass die verlorengegangene USB-Verbindung zum Brick nicht erkannt wird, wenn man einen dazwischengeschalteten USB-Hub mit abtrennt?

Wegen dem leeren { } - Ausdruck? Das scheint es nicht zu sein. Deinen Vorschlag habe ich jetzt zwar noch nicht getestet. Aber ich möchte ja eigentlich die Debugging-Meldungen aktivieren (das war der Grund für das Neukompilieren). Auch bei dem anderen if-Zweig kommt dann der Fehler. Die runde Klammer habe ich testweise noch eingefügt: error: expected expression before 'do' #define logf(str, ...) (do{ printf("<F> " str, ##__VA_ARGS__); }while(0))

Ok - mit der gesetzten Umgebungsvariable HTTPS_PROXY klappt es. Die Proxy-Einstellungen werden beim Start des Brick Viewer angezeigt und die Internetverbindung läuft! 🙂

Ich habe innerhalb einer VM (Debian 10) die Build-Umgebung aufgesetzt. Das Skript ist hierbei nicht unmittelbar durchgelaufen, da ein paar Pakete durch aktuellere (mit neuem Namen) ersetzt werden mussten... Ich habe jetzt eine Lösung gefunden: Der Fehler wurde ausschließlich bei logf(...) gemeldet - nicht bei den anderen #defines. Daraus würde ich schließen, dass der Compiler "logf" wohl als "Logarithmus mit Wertebereich double" interpretiert. Denn es funktioniert nun, wenn ich einfach alle "logf(" beispielsweise durch "logfatal(" ersetze.

Ich habe eine Build-Umgebung entsprechend dem Tinkerforge-Tutorial aufgesetzt. Das Kompilieren von Bricklets funktioniert bereits. Jetzt habe ich versucht, die Master Brick Firmware zu kompilieren. Dabei erhalte ich folgende Fehlermeldung: In file included from ......./src/extensions/wifi/wifi_data.c:31:0: ......./src/logging/logging.h:118:25: error: expected identifier or '(' before '{' token #define logf(str, ...) {} ^ Der Fehler ist vermutlich nicht in logging.h selbst zu suchen? Er wird wahrscheinlich durch ein Problem an anderer Stelle verursacht?

Also beispielsweise in der Arduino IDE muss ich den Proxy auch manuell eintragen. Die automatische Erkennung klappt hier nicht. Andere Programme können Updates ohne manuelle Konfiguration ausführen (z.B. LTSpice XVII). In den Windows 10 Einstellungen ist die Manuelle Proxyeinrichtung zwar sichtbar (inkl. voreingetragener Proxyadresse) und ich kann "Proxyserver verwenden" von Aus auf Ein umstellen. Aber der "Speichern"-Button ist praktisch ohne Funktion. D.h. nach dem erneuten Öffnen des Menüs sind alle Einstellungen wieder zurückgesetzt (trotz Admin-Rechten)....

Danke für den Hinweis zum Bricklet Firmware-Update. Es war zwar schon ein Bricklet angeschlossen, aber der Bootstrapper, den ich selbst auf einen leeren uC geladen hatte, hatte noch Fehler. Inzwischen ist das aber behoben und das Bricklet läuft. Ansonsten hatte ich gestern meine Beiträge zu voreilig abgeschickt! Die vermeintliche Internetverbindung hatte ich nur bekommen, da ich zu diesem Zeitpunkt per Wifi verbunden war. Mit der "normalen" LAN-Verbindung, die über den Firmen-Proxy läuft, besteht das Problem leider nach wie vor. Und zwar unabhängig davon, ob ich die http oder https Version verwende. Wenn ich "brickv_windows_2_4_11_snapshot_e750b42.exe" starte, erscheint die Meldung "No proxies found". Wie und wo der Proxy im Firmennetz konfiguriert ist, weiß ich nicht. Ich habe nun mal versucht, direkt in Python3 eine Internetseite aufzurufen, über folgendes Script: import urllib.request x = urllib.request.urlopen('https://www.google.com/') print(x.read()) Das klappt über den Proxy natürlich ebenfalls nicht. Es funktioniert aber tatsächlich mit folgender Lösung (Proxy manuell eingetragen): import urllib.request as request proxy_handler = request.ProxyHandler({'http': 'http://www.example.com:3128/'}) opener = request.build_opener(proxy_handler) url = 'http://www.example.org' # open the website with the opener req = opener.open(url) data = req.read().decode('utf8') print(data) (Code-Ausschnitt kopiert von: https://stackoverflow.com/questions/34576665/setting-proxy-to-urllib-request-python3)

...naja fast. Es wird zwar eine Verbindung aufgebaut und die Firmware-Versionen auf dem Server können gelesen werden. Aber der Download an sich klappt dann noch nicht:

Super - die HTTP Version funktioniert bei mir! Endlich kann ich die Update-Funktion wieder richtig nutzen 😃

Auf die Adresse kann ich (per Chrome/Explorer etc.) zugreifen. Es sollte also nicht daran liegen, dass der Zugriff aus dem Brick Viewer heraus geblockt wird. (Durch die sehr übersichtliche Darstellung auf https://download.tinkerforge.com kann ich nun aber zumindest sehr schnell die neuesten Firmware-Files manuell herunterladen und im Brick Viewer laden )