Jump to content

photron

Administrators
  • Content Count

    2733
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by photron

  1. 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.
  2. 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?
  3. 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
  4. Noch eine Frage: Hast du am HAT Zero Brick irgendetwas angeschlossen? Falls ja hilft es alles vom HAT abzustecken?
  5. 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.
  6. 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?
  7. @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.
  8. 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?
  9. Das Brick Daemon Debian Package ist jetzt auch für arm64 verfügbar.
  10. The Brick Daemon Debian package is now also available for arm64 architecture.
  11. 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
  12. 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
  13. 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 L
  14. 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 ä
  15. Ja, das wird in 2.4.3 drin sein. Ich denke das kommt noch heute oder morgen raus.
  16. 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
  17. 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 d
  18. Did the PTC problem occur once or is it reproducible? What kind of power supply do you use to feed the black power input on the HAT Brick? Could the system be underpowered?
  19. Do you run Raspberry Pi OS or Ubuntu at the moment? The -246.88 is the value you get if the sensor input on the PTC Bricklet 2.0 is shorted.
  20. I tested Raspberry Pi 4 with Raspberry Pi OS with brickd 2.4.2 and "stress -c 4". I can see that the SPI clock is 2x faster than expected and there are errors in the brickd.log, but the error rate is still low enough that the error recovery mechanisms in brickd can deal with it. But this is not a recommended setup, it's barely working and on the edge to failing.
  21. Yes, with brickd 2.4.2 the SPI frequency setting is broken in brickd and it might work for you under certain conditions, but might just fail under other conditions. Please test the attached snapshot versions of brickd in the post above. These have the SPI frequency setting logic fixed. In my tests here this works without problems with Ubuntu on Raspberry Pi 4. The original 2.4.2 version doesn't work there because the SPI frequency is way too high there because of a bug in brickd.
  22. I've found the difference between Raspberry Pi OS and Ubuntu. Raspberry Pi OS scales down the core frequency to 200 if there is not much load on the CPU. Ubuntu keeps the core frequency at 500 all the time, resulting the SPI clock being to fast all the time.
  23. Please test the attached brickd version with Ubuntu. The arm64 variant is for Ubuntu, the armhf variant is for Raspberry Pi OS. This version fixes the Problem for me with Raspberry Pi 4 and Ubuntu. There is no need to modify core_freq or anything else. This should work with an unmodified OS image. With this version you should not see these kinds of messages in the log file anymore: 2020-11-19 18:07:15.845333 <E> <bricklet_stack.c:396> Frame error (port: I, count: 33) 2020-11-19 18:07:15.853887 <E> <bricklet_stack.c:478> Message checksum error (port: I, cou
  24. Okay, the whole core_freq situation is way more complex. That it works for you with Raspberry Pi Os is just luck I think. Sorry, for the mess, I working on improving this situation. On RPi 4 core_freq can be 500, 550 or 360 depending on the TV-Out and HDMI config. The core_freq_min can be 250 or 275. The kernel will dynamically change the actual core frequency depending on the load. On RPi 1 and 2 core_freq and core_freq_min are fixed 250, no problem there. On RPi 0/W and 3A/B+ core_freq is 400 and core_freq_min is 250. In brickd 2.4.2 we switched to a new backend for SPI c
  25. Brick Daemon expects the Raspberry Pi core_freq to be 250, but with the Raspberry Pi 4 core_freq is 500 by default. The SPI clock is based on the core_freq. With a core_freq twice as fast as expected the SPI clock is also twice as fast. This is too fast for the Bricklets. This is a somewhat known problem. But our documentation doesn't cover this well. You can try forcing the core_freq to 250 in Ubuntu by editing /boot/firmware/config.txt and adding, but the Raspberry Pi documentation warns about doing this on a Raspberry Pi 4, as it might result in boot problems: core_freq=250 But
×
×
  • Create New...