borg

Firmware: Piezo Speaker Bricklet 2.0.3 Don't disable IRQs during calibration, since newer Brick versions use interrupts during I2C communication Download: Piezo Speaker

Firmware: Piezo Speaker Bricklet 2.0.3 Don't disable IRQs during calibration, since newer Brick versions use interrupts during I2C communication Download: Piezo Speaker

Ich hatte hier jetzt eine Zeit lang einen Testaufbau am laufen der immer nur get_touch_position aufgerufen hat mit der Hoffnung dass ich irgendwann einen "falschen Touch" sehe. Ich konnte das leider bisher nicht reproduzieren. Ein Pressure-Wert von 1 ist bereits der niedrigste Wert, meine Behauptung von vorher dass ich dort einen Threshold niedriger setzen kann macht also keinen Sinn. Meine neueste Vermutung ist, dass du für eine ganz kurze Zeit fälschlicherweise irgendwo eine Berührung siehst (beim Aufruf von get_touch_position nach dem Callback ist der Pressure-Wert dann schon wieder auf 1) und der Fix wäre eher ein Minmum-Klickzeit für den Button-Klick einzuführen. Ich hab da jetzt nochmal mehr logging eingebaut und es sind jetzt auch Buttons mit konfigurierten Callbacks mit eingebaut. Das lasse ich jetzt nochmal ein paar Tage laufen. Melde mich dann wieder.

Firmware: Thermal Imaging Bricklet 2.0.4 Nutze Double Buffering für Lepton-Statistiken um Tearing in den Statistiken zu verhindern Download: Thermal Imaging

Firmware: Thermal Imaging Bricklet 2.0.4 Double buffer lepton statistics to prevent statistics tearing Download: Thermal Imaging

Einen Widerstand kannst du mit den Bricklets am einfachsten über einen Spannungsteiler und einem (Industrial) Analog In Bricklet messen. https://www.elektronik-kompendium.de/sites/slt/0201111.htm In dem Beispiel wäre R1 der veränderliche Widerstand und R2 ein fester Widerstand. Die Spannung zwischen den beiden Widerständen verändert sich dann wenn sich R1 ändert.

Ich bin jetzt dazu gekommen mir das einmal mit dem Profiler anzuschauen. Einen kleinen Flaschenhals hab ich bei den SPI Chip Selects gefunden, die konnten ohne großen Aufwand effizienter gemacht werden. Das hat sowas wie ~15% eingespart. Zusätzlich hab ich eine "sleep_between_read"-Option pro Bricklet in die /etc/brickd.conf hinzugefügt. Damit kann jetzt eingestellt werden wie lange der Brick Daemon mindestens warten soll zwischen zwei "Reads" von einem Bricklet. Der Wert ist in us und war damals per Default 200us. Die Default-Konfiguration sieht mit der neuen brickd Version jetzt so aus: bricklet.portA.sleep_between_reads = 200 bricklet.portB.sleep_between_reads = 200 bricklet.portC.sleep_between_reads = 200 bricklet.portD.sleep_between_reads = 200 bricklet.portHAT.sleep_between_reads = 2000 Die Default-Einstellung vom HAT selbst hab ich von 200us auf 2ms erhöht, da das HAT selbst sowieso nie große Datenmengen übertragen muss. Wenn am Bricklet nichts angeschlossen ist was große Datenmengen überträgt kann aber auch z.B. alles auf 5ms gesetzt werden und es funktioniert immernoch gut: bricklet.portA.sleep_between_reads = 5000 bricklet.portB.sleep_between_reads = 5000 bricklet.portC.sleep_between_reads = 5000 bricklet.portD.sleep_between_reads = 5000 bricklet.portHAT.sleep_between_reads = 5000 Meine Ergebnisse nach den Änderungen: HAT mit Defaultkonfiguration, keine Bricklets angeschlossen: HAT mit Defaultkonfiguration, Thermal Imaging Bricklet an port B streamt mit vollem Durchsatz Bild über WIFI: HAT mit 5ms-Konfiguration, Rotary Encoder an Port B: Anbei die Beta-Version des neuen Brickd mit den Änderungen. brickd-2.4.1-beta1_armhf.deb

Anbei Beta-Versionen des nächsten Bindings-Release von Rust und MATLAB: http://download.tinkerforge.com/_stuff/tinkerforge_rust_bindings_2_0_11_beta1.zip http://download.tinkerforge.com/_stuff/tinkerforge_matlab_bindings_2_0_23_beta1.zip

Firmware Version 2.0.2 ist jetzt veröffentlicht und sollte das fixen. Ich hab die Firmware in dem Zuge auf die neuen Coop Tasks umgestellt die wir in der bricklib haben (gab es zu dem Zeitpunkt als wir die Firmware geschrieben haben noch nicht) Die Baudrate hab ich auf 200kHz erhöht um das Jitter zu verringern, wobei der Durchsatz bei 100kHz prinzipiell auch bereits gereicht hatte. So sieht das jetzt aus: 976 SPS 488 SPS 244 SPS Der etwas größere Block bei CLK sind immer die Daten und die kleinen Blöcke sind die Statusabfrage. Das sieht jetzt IMO ganz gut aus und bleibt auch langfristig gleichmäßig.

Firmware: Industrial Dual Analog In V2 Bricklet 2.0.2 Fix error in sample rate configuration Use coop task instead of complicated state machine Properly reconfigure ADC in case of invalid data Download: Industrial Dual Analog In 2.0

Firmware: Industrial Dual Analog In V2 Bricklet 2.0.2 Fix error in sample rate configuration Use coop task instead of complicated state machine Properly reconfigure ADC in case of invalid data Download: Industrial Dual Analog In 2.0

So, ich hab jetzt eine entsprechende Funktion hinzugefügt: https://www.tinkerforge.com/en/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_filter_configuration Gibt es in Firmware Version 2.0.2. Die API wird dann mit dem nächsten Bindings-Release aktualisiert. Das kann leider noch ein wenig dauern. Welche Programmiersprache verwendet ihr? Dann erstelle ich für euch einmal schnell Beta-Bindings zum testen (wenn bedarf besteht).

Ich hab es mir auf die TODO-Liste geschrieben da nochmal mit einem Profiler zu schauen wo die CPU-Zeit verloren geht. Eventuell können wir da ein einstellbares Abfrageintervall o.ä. machen für Anwendungen wo kein hoher Durchsatz benötigt wird.

Steht irgendetwas in der /var/log/brickd.log? Zum Thema CPU-Auslastung: Kann es sein dass der brickd gerade so wenig CPU zieht das der RPi sich heruntertaktet und dann eine relativ hohe Auslastung anzeigt? Um das zu testen kannst du einmal probeweise den Linux Governor auf "performance" stellen: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#konfiguration-fur-verbesserten-durchsatz

Mh, ich glaube ich muss da nochmal eine Debug-Firmware fertig machen die den Rohwert des Touchscreens ausgibt um zu sehen wie nah das an einem "Pressure-Wert" von 1 dran ist. Vielleicht muss da generell der Threshold ein bisschen höher. Ich melde mich hier nochmal wenn ich da mehr Erkenntnisse hab.

Ich hab es mir nicht im Detail angeschaut, sieht aber in der Tat nach einem sehr unnötigen Bug aus! Schaue ich mir schnellstmöglich an, gibt dann eine neue Firmware. Danke für den Hinweis .

Wir haben das gerade nochmal getestet, bei uns startet der brickd automatisch wenn wir es nach Anleitung machen. Sehr komisch. Falls das irgendwie nicht funktioniert hat kannst du den Autostart auf jeden Fall mit sudo systemctl enable brickd aktivieren. Ich glaube der Service taucht da auch nicht zweimal auf, du siehst da nur zwei Threads. Ansonsten hat der RPi Zero halt nur einen Kern mit 1GHz, da kann der brickd schon schnell viel CPU ziehen. Welche Bricklets hast du denn angeschlossen und was machst du mit diesen/hast du mit diesen vor?

I tried the newest Raspbian Image with RPI 2/3/4 and the behavior is now the same with all three versions*: The SPI speed scales with the CPU frequency, which is depended on the Linux governor. I added a section to the documentation: https://www.tinkerforge.com/en/doc/Hardware/Bricks/HAT_Brick.html#configuration-for-improved-throughput With the RPi 3 and 4 i get the full 1000 messages per second after the changes.

I did some real fast preliminary tests: The SPI clock on the RPi4 seems to be derived from the main cpu clock (on the RPi3 it is derived from the VPU, which is even crazier...). This means that if the CPU governor scales down the CPU, it also scales down the SPI speed. One solution is to put the governor in performance mode: Another, very unintuitive, solution is to have something running on the RPi that uses a lot of CPU. Just running a while(true)-loop on 2 cores does the trick in my tests, i then get the full speed too... . I have written on my TODO-list to install the newest version of Raspian on a RPi2, RPi3 and RPi4 and compare the exact performance and document the steps necessary to configure the PIs for the best performance. I will add this to the HAT and HAT Zero documentation.

In der Tat! Aktuell bleiben IIR_BYPASS und LPRO immer auf Default. Ich füge das als Konfiguration der API hinzu. Komme ich vermutlich frühestens Mittwoch zu. Edit: Nur ein kurzer Hinweis: Ich habs nicht vergessen, komme aber erst nächste Woche dazu.

It should be possible to transfer about the same amount of data through the HATs (maybe a little bit less) as with a Master Brick. From the perspective of the Linux kernel there is a lot of context switching going on (between kernel and user land as well as between IO and CRC calculation etc). There is unfortunately some time lost compared to the Master Brick, since the Master Brick does not do anything else in-between. Also, the processor of the RPi3 does not support SPI CPHA (which we need) on spidev1.x. Because of that we have to manage 8 chip selects with one hardware SPI unit. The SPI unit does not have 8 hardware chip selects, so we have to do them from the user land via GPIO. This also costs additional time. That being said: I did all my tests with the RPi3. During the development of the HAT the RPi4 was not yet released. I will do some measurements with the RPi4 to see where the time is lost and if there maybe is a kernel configuration somewhere that we can do to increase the throughput. I think i will be able to do this on Wednesday, give me a few days for this. I will post the results in this thread.

Das ist komisch. Wenn die LED am RPi wieder anfängt zu leuchten, bekommt das RPi ja offensichtlich auch wieder Strom. Ich wüsste nicht warum es dann nicht booten sollte. Hast du die Möglichkeit einen Monitor am RPi anzuschließen? Wenn die LED leuchtet, hängt der RPi dann irgendwo im Bootprozess?

Das Isolator Bricklet kann so wie es ist mit den HATs verwendet werden! Dazu benötigt man jetzt natürlich beidseitig 7p-7p Kabel.

Ist aktuell nicht geplant, wenn es da genug Nachfrage gibt könnte man sowas aber natürlich machen.

Ein RED Brick 2.0 ist geplant. Wird allerdings noch ein wenig dauern, da wir jetzt zuerst noch die anderen Bricks umstellen wollen nachdem wir mit den Bricklets durch sind.