photron

Okay, das war sehr hilfreich. Das ist ein Bug in brickd. Brickd erwartet, dass zwischen dem Abstecken und der Benachrichtigung vom OS dazu maximal eine Sekunde vergeht. Im ersten Log vergehen dazwischen aber 2,5 Sekunden. Im zweiten fehlerfreien Log vergeht nicht mal 1 Millisekunde dazwischen. Der Bug ist, dass brickd das Abstecken dann nicht richtig behandelt und dadurch der Enumerate-Disconnected Callback nicht gesendet wird. Dadurch bleibt der Tab in Brick Viewer stehen. Ich werde hier in Kürze eine korrigierte brickd Version zum Testen posten.

Dann zeichne bitte mal mit dem Log Viewer den Fehlerfall auf. Dazu folgende Schritte durchführen: Hub ist abgesteckt "Brickd 2.4.3 - Log Viewer" starten "Live Log" auf "Debug Level" stellen Hub anstecken, kurz warten und wieder abstecken. Falls das Problem nicht aufgetreten ist, dann Log Viewer schließen und bei 1. wieder beginnen. Log Viewer fehlt noch eine Clear Funktion, daher muss Log Viewer neugestartet werden. Bitte nur einen An- und Absteckvorgang aufzeichnen Live Log mittels "Save..." speichern und hier anhängen

The USB port on the HAT Brick is power only. The problem you're running into now is that the HAT Brick is in bootloader mode and in this mode the HAT autodetection of the Raspberry Pi doesn't work. Otherwise the HAT Brick you just show up in Brick Viewer and you could just flash it. You need to manually edit the /etc/brickd.conf file on the Raspberry Pi and add these lines to the end of the file: bricklet.group0.spidev = /dev/spidev0.0 bricklet.group0.cs0.driver = gpio bricklet.group0.cs0.name = gpio23 bricklet.group0.cs0.num = 23 bricklet.group0.cs1.driver = gpio bricklet.group0.cs1.name = gpio22 bricklet.group0.cs1.num = 22 bricklet.group0.cs2.driver = gpio bricklet.group0.cs2.name = gpio25 bricklet.group0.cs2.num = 25 bricklet.group0.cs3.driver = gpio bricklet.group0.cs3.name = gpio26 bricklet.group0.cs3.num = 26 bricklet.group0.cs4.driver = gpio bricklet.group0.cs4.name = gpio27 bricklet.group0.cs4.num = 27 bricklet.group0.cs5.driver = gpio bricklet.group0.cs5.name = gpio24 bricklet.group0.cs5.num = 24 bricklet.group0.cs6.driver = gpio bricklet.group0.cs6.name = gpio7 bricklet.group0.cs6.num = 7 bricklet.group0.cs7.driver = gpio bricklet.group0.cs7.name = gpio6 bricklet.group0.cs7.num = 6 bricklet.group0.cs8.driver = gpio bricklet.group0.cs8.name = gpio5 bricklet.group0.cs8.num = 5 as described here: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Brick.html#compatibility-to-other-boards-and-images Afterwards reboot the Raspberry Pi, then the HAT Brick should show up in Brick Viewer again and you can flash it. One the HAT Brick is flashed success fully, edit /etc/brickd.conf again and remove the lines you just added.

Linux, Windows oder macOS? Brick Daemon verwendet die USB Hotplug Erkennung des Betriebssystems. Ich fürchte da können wir nicht viel machen, wenn das nicht richtig funktioniert.

Wir sind seit 2017 dabei vom alten 10 Pol auf den neuen robusteren 7 Pol Bricklet Stecker umzustellen. Es gibt alle Bricklets seit einer Weile mit 7 Pol Stecker. Die alten 10 Pol Bricklets laufen nach und nach aus. Neuere Bricks wie der HAT (Zero) Brick oder der kommende ESP32 Brick haben nur noch Anschlüsse für 7 Pol Bricklets. 10 Pol Bricklets können nur an 10 Pol Bricks angeschlossen werden. Anders herum können aber 7 Pol Bricklets auch noch an 10 Pol Bricks angeschlossen werden. Daher kannst du 10 Pol Bricklets nicht an einen HAT Brick anschließen, sorry. Das ist aber auch deutlich so dokumentiert. Um 10 Pol Bricklets weiter nutzen zu können kannst du diese an einen 10 Pol Master Brick anschließen. Aber auch diese Übergangszeit wird im Laufe des Jahres enden, dann werden wir die bisherigen 10 Pol Bricks auch auf 7 Pol umstellen. Auf Dauer stirbt der 10 Pol Stecker aus. Existierende 10 Pol Hardware wird aber weiter funktionieren.

That will not happen, as the brickd.log is rotated. Yes, something like that is on the todo list, but log size it not a good indicator here. All Bricks and 7-pol Bricklet have error counter APIs. Brickd will get something similar. Regarding the error messages from the LCD Bricklet: I can see the problem here. This is unexpected and i'll look into this why the LCD Bricklet does this. But this is not an immediate problem as the actual functionality of the Bricklet is not affected, because the error recovery mechanisms are working. This is more a problem of error reporting in brickd. Before 2.4.2 all these errors where logged on debug level and you would not have seen them by default. In 2.4.2 we changed that to give these errors more visibility with the downside of given them too much visibility in some cases. Your case is on the edge of this.

Nein. Das ist mehr oder minder Absicht. Die Erfahrung zeigt leider, dass sich dann mehr Leute damit in den Fuss schießen und sich komische Probleme bauen, die dann schwer für uns zu debuggen sind.

D.h. der HAT Brick taucht in Brick Viewer auf, aber keines der angeschlossenen Bricklets? Erstell bitte erstmal kein Debug Log, auch wenn @lapawa dazu rät. Sondern häng einfach mal die /var/log/brickd.log von deinem Raspberry Pi an wie sie da gerade liegt. Hast du neben dem HAT Brick mit Bricklets noch irgendetwas anderes angeschlossen? Nicht das wir hier Softwareprobleme suchen und es sind dann Hardwareprobleme an anderen Bauteilen, wie es bei @lapawa der Fall war. Welche brickd Version verwendest du? Alle diese Probleme die es mit dem HAT Brick kürzlich gab mit Kernel 5.x und Raspberry Pi 4 sollten mit brickd 2.4.3 behoben sein. Du solltest keine sonstigen Änderungen durchführen. Welche meinst du genau?

Beim IO-4 Bricklet 2.0 kannst du die set_edge_count_configuration und get_edge_count Funktionen nutzen. Dieser Edge Counter kann mindestens mit 1 kHz abtasten, d.h. du kannst damit sicher Flankenwechsel mit 500 Hz messen. Geschwindigkeitsmäßig heißt das, dass von einer Signalflanke zur nächsten mindesten 2 ms vergehen müssten.

Der Schaltplan verwirrt mich. Von der Beschreibung des HATs her scheint der sich nur 5V und 3,3V vom Raspberry Pi Header zu holen. Ich bilde mir auch ein auf dem schwammigen Produktfoto Leiterbahnen zu diesen Pins laufen zu sehen. Die USB Kommunikation läuft dann über diese kleine Adapterplatine. Falls das wirklich so ist sollte das funktionieren können. Genau dieser Aufbau hat schon mal funktioniert, oder ein anderer Aufbau dieser Art? Was hat sich geändert? Hast du vielleicht das klassische Raspberry Pi Problem und du versorgst den Aufbau nicht gut genug mit 5V?

Das Bricklet versteht 0-2V als logische 0 (low) und 10-26V als logische 1 (high). 2-10V sind undefiniert (no man's land). Das ist vom Design her dafür ausgelegt ein 24V Signal zu verstehen. 3,3V und 5V Signale liegen damit im undefinierten Bereich des Bricklets. Das kannst du so also nicht direkt verwenden. Abhängig davon was du genau messen willst könntest du ein anderes Bricklet mit digitale Eingang nehmen, die meisten haben eine einfache Zählerfunktion. Oder du kannst dir aus einem Transistor einen Pegelwandler bauen, wobei du den Transistor dann mit 3,3V oder 5V steuerst und der Transistor and z.B. 12V oder 24V auf den Eingang des Industrial Counter Bricklets schaltet. Was leider den Nachteil hat, dass du dann diese höhere Spannung auch in deiner Schaltung zur Verfügung haben musst.

Noch eine Frage: Hast du am HAT Zero Brick irgendetwas angeschlossen? Falls ja hilft es alles vom HAT abzustecken?

Das ist interessant, dazu muss ich @photron mal befragen. Das war in 2.4.1 der Fall, das ist in 2.4.2 behoben und in 2.4.3 nicht mehr relevant, da dort die CS Pins im Normalfall nicht mehr durch sysfs gesteuert werden. Das sollte kein Problem sein, du hast ja ein HAT Zero, das hat sowieso keine RTC an Bord. brickd selbst greift nicht auf diese Datei zu, das ist vermutlich irgendwas in glibc oder libusb. Das kannst du ignorieren. Ich glaube nicht, dass das hier mit dem "Message checksum error" Problem zusammenhängt, dass Superb hat, wie @rtrbt vermutet. brickd 2.4.1 meldet diese Fehler auf Debug Level, was standardmäßig nicht sichtbar ist. Die Debug Logauszüge sehen aber gut aus. Komisch. Komisch ist dann auch, dass es mit brickd 2.4.1 nicht hilft, die core Clock auf 250MHz zu setzen. Für brickd 2.4.3 ist das setzen von core_freq auf 250 nicht mehr notwendig, da diese Version mit abweichenden core Clock Frequenzen um gehen kann. Vielleicht ist die BCM2835 Library ein Problem, die wird in brickd 2.4.3 standardmäßig verwenden, in Zusammenhang mit deinem Custom Linux Builds ein Problem. Brickd 2.4.1 verwendet stattdessen spidev und sysfs. Teste mal bitte folgendes: Installiere wieder brickd 2.4.3 und setze in /etc/brickd.conf die bricklet.spi.driver Option auf spidev: bricklet.spi.driver = spidev Du solltest dann in der Logausgabe Using spidev backend for Bricklets (forced by config) anstelle von Using BCM2835 backend for Bricklets (Raspberry Pi detected) stehen. Hilft das? Wenn das nicht hilft, dann teste bitte mal mit einem Standard Raspbian und Standard brickd 2.4.3 anstelle deines Custom Linux Builds. Nicht das hier ein Hardwaredefekt an HAT oder Raspberry Pi vorliegt. Ist beides schon vorgekommen. Hast du noch ein anderes Raspberry Pi zur Hand u das testen zu können?

Downgrading to brickd 2.4.1 will "hide" these messages, because before brickd 2.4.2 these messages where logged on debug level, which is not visible by default. Do you actually have issue with the LCD 128x64 Bricklets functionality? Or are you just seeing these messages in the brickd.log file, but the Bricklet works fine regardless? What else do you have connected to the HAT Brick?

@bugra_s Welche brickd Version ist auf dem Raspberry Pi installiert? Wenn es nicht 2.4.3 ist, dann test bitte zuerst mal brickd 2.4.3 zu installieren.

Tinkerforge::DEVICE_DISPLAY_NAMES is internal for error message purposes. What you're looking for is a device factory. The Ruby bindings don't have that. That's not a bad idea at all, that basically how Brick Viewer solves this problem. But instead of doing a linear search, Brick Viewer builds a dictionary that maps device identifier to device class and then uses that dictionary to do the lookup efficiently. What are you trying to build that requires a device factory?

Das Brick Daemon Debian Package ist jetzt auch für arm64 verfügbar.

The Brick Daemon Debian package is now also available for arm64 architecture.

Brick Daemon 2.4.3 Fix SPI clock for HAT (Zero) Brick on Linux, if core_freq differs from 250 MHz Add config option to override SPI backend detection Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Brick Daemon 2.4.3 SPI-Clock für HAT (Zero) Brick auf Linux korrigiert, falls core_freq von 250 MHz abweicht Config-Option zur Überstimmung der SPI Backend-Bestimmung hinzugefügt Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS

Wie in der Doku beschrieben kommt ein Enumerate-Connected unaufgefordert durch Starten oder Resetten der Hardware. Ein Enumerate-Available kommt durch Anforderung über die enumerate() Funktion. Ich erwarte, dass bei den beiden Enumerate-Callbacks einer ein Connected- und einer ein Available-Callback ist. Alternativ hast du noch ein anderes Programm laufen, dass auch enumerate() aufruft. Enumerate Callback die von einem Programm ausgelöst werden kommen auch an allen Programmen an die zur gleichen Adresse verbunden sind. Anstatt die Toten die Lebenden finden. Den Fall, dass die onewire Liste leer ist muss nicht extra behandelt werden. Wenn die Liste leer ist, dann wird die for Schleife nicht betreten, found bleibt False. if device_identifier == BrickletOneWire.DEVICE_IDENTIFIER: self.sensors.stop_auto_reading() alive = [] found = False for i in self.onewire: try: if i.get_identity().uid == uid: found = True except: pass # ignoring non-responding Bricklet else: alive.append(i) if not found: alive.append(BrickletOneWire(uid, self.ipcon)) self.onewire = alive self.sensors.add_onewire(self.onewire) Weil das Device Object keinen relevanten Zustand hält außer die Response-Expected-Einstellungen. Daher muss es nicht neu angelegt, wenn sich das Bricklet enumeriert, denn es ändert sich durch das Enumerieren aus der Sicht des Device Object nichts.

Nein. Ja. Schaust du auf den enumerate_type und unterscheidest Connected und Available Enumerate Callbacks? Zu der "Device has been replaced" Fehlermeldung: Die IPConnection hält intern eine Liste von UID auf Device Object. Wenn du für eine UID ein neues Device Object anlegst, dann wird das alte Device Object ersetzt. Wenn du dann auf dem alten Device Object Funktionen aufrufst, dann bekommst du den "Device has been replaced" Fehler. Das ganze kommt durch die "i = BrickletOneWire(uid, self.ipcon)" Zeile. Das ersetzt nicht den Eintrag in der onewire Liste, sondern du änderst nur die lokale Variable i, ersetzt aber in er IPConnection das alte BrickletOneWire Object durch das neue, das dann aber nicht in der onewire Liste landet. Dadurch verwendest du später das alte BrickletOneWire Object wieder. Es ist aber an der Stelle auch nicht notwendig das BrickletOneWire Object neu anzulegen. Sprich wenn du die Zeile löscht löst sich dadurch dein Problem.

Ja, das wird in 2.4.3 drin sein. Ich denke das kommt noch heute oder morgen raus.

Das funktioniert auf dem Raspberry Pi 4 auch nur zufällig, weil der CPU Governor dort die Core Clock bei wenig Last runter skaliert. Auf dem Raspberry Pi Zero läuft die Core Clock aber auf volle Pulle und dadurch ist die SPI Kommunikation zu schnell, weil brickd die falsch berechnet. Dadurch verstehen die Bricklets das dann nicht. Teste mal bitte die angehängte brickd Version. brickd_2.4.2+snapshot~b4e01c3_armhf.deb

Ich glaube wir haben dich erfolgreich verwirrt! Die API des RED Brick selbst wird von Brick Viewer verwendet um z.B. Programme auf den RED Brick zu laden und zu verwalten. Wenn du auf dem RED Brick ein Java Programm ausführen willst, das an den RED Brick angeschlossene Bricks und Bricklets verwendet, dann hast du mit der API des RED Bricks nichts zu tun. Du würdest dein Programm entwickeln und dann über den Brick Viewer auf den RED Brick laden und ausführen lassen. Daher hast du in dem Fall auch mit nichts zu tun was du dort im Beispiel siehst. Dieses Beispiel zeigt nicht, wie du ein Programm schreibst, das auf dem RED Brick läuft. Dieses Beispiel existiert, weil mal ein Kunde danach gefragt hat, wie man aus einem Programm A heraus ein Programm B auf dem RED Brick manuell starten kann. Das ist aber ein Spezialfall. Der Normalfall ist, dass du dein Programm auf den RED Brick lädst und es dann durch den RED Brick automatisch starten lässt. Kurz zu deinen Fragen: Das ist der Identifier aus dem Program Wizard für das Programm das manuell gestartet werden soll. Das ist nicht der Identifier für dieses Beispiel Programm. Mit der startProgram Funktion der RED Brick API kann ein vorher hochgeladenes Programm manuell gestartet werden. Der restlich Code davor dient dazu das zu startende Programm anhand seines Identifiers zu finden. Dort wird keine Klasse instantiiert weil das Beispiel möglichst einfach sein soll, keine Objektorientierung nötig in diesem Beispiel. Dein Programm basiert nicht auf Ableiten einer Basisklasse oder Implementieren eines Interfaces oder diesem Beispiel überhaupt. Außer wenn du wirklich Brick Viewer Aufgaben in deinem Programm selbst umsetzen willst, hast du nie etwas mit der RED Brick API oder den Dingen in diesem Beispiel zu tun. Beispiel: Du hast auf dem RED Brick einen Master Brick, daran ein Temperature Bricklet 2.0 und willst mit einem Program auf dem RED Brick die Temperaturwerte aufzeichnen. Dann könntest du z.B. das Temperature Bricklet 2.0 Java Callback Bespiel nehmen, die UID auf die deines Temperature Bricklet 2.0 setzen, das Programm kompilieren und über Brick Viewer auf den RED Brick landen und ausführen lassen. Die Standardeinstellungen des Program Wizards sind so, dass die Ausgaben des Programms in einer Logdatei auf dem RED Brick aufgezeichnet werden, die du über Brick Viewer einsehen kannst. Fertig ist ein simpler Temperatur Logger. https://www.tinkerforge.com/de/doc/Software/Bricklets/TemperatureV2_Bricklet_Java.html#callback