cl-

Ah ok. Ich verstehe! Ich habe noch ein paar Fragen dazu. Hat ein Bricklet nicht immer Daten zu versenden? Kann dieser Zustand nicht nur am Anfang passieren, wenn das Bricklet gerade erst konfiguriert wurde? Wenn ich in deinem Beispiel nun nach ca. 900 µs wieder bei Bricklet X angelangt bin und es befrage, bekomme ich dann die zeitlich jüngsten Daten des Bricklets oder noch die alten Daten von vor ca. 900 µs, die ich fast hätte kriegen können? Oder in anderen Worten: Aktualisieren die Bricklets ihre Daten für den Ausgang, auch wenn sie nicht angefragt werden? Die Frage geht in die gleiche Richtung wie oben. Es ist klar, dass die entsprechende Bricklet Konfiguration gewährleisten muss, dass die Samplingrate/Datarate des Sensors hoch genug ist, um auch wirklich aktuelle Daten zu generieren. Sagen wir, während der Zeit von 900 µs hat der Sensor des Bricklets (KX122 in meinem Fall) mehrmals neue Messwerte generiert. Ja genau! Mir geht es primär um den Takt, die immer gleiche, zeitliche Abfolge von Samples. Wenn ich gewährleisten kann, dass es beispielsweise immer um die 300 us sind, die zwischen zwei aufeinanderfolgenden Pakten liegen, dann kann ich das programmatisch kompensieren. Besten Dank!

Ich habe jetzt auch mal das aktuelle Raspberry Pi OS genommen, wieder den aktuellen Kernel 5.4.51+ geladen, die core_freq auf 250 gestellt und vier Accelerometer V2 Bricklets angeschlossen. Ich nutze das hal_raspberry_pi (Beta 6) und diesmal habe in dieser Konfiguration keinerlei Fehler mehr bei der Kommunikation. Das ist absolut top! Scheinbar war irgendetwas nicht richtig an meiner vorherigen Konfiguration und/oder Software Zusammenstellung. Ich komme bei 1,40 MHz SPI Speed jetzt auf ca. 2020 bis 2030 PPS (mit vier Accelerometer V2 Bricklets). Channel 0: Packet counter is 2535 after 5.000476 seconds. Channel 1: Packet counter is 2535 after 5.000476 seconds. Channel 2: Packet counter is 2535 after 5.000476 seconds. Channel 3: Packet counter is 2536 after 5.000476 seconds. Combined: 2028.006958 packets per second Mit 1,95 MHz SPI Speed kriege ich jetzt ca. 2750 bis 2770 PPS (mit vier Accelerometer V2 Bricklets). Channel 0: Packet counter is 3461 after 5.000326 seconds. Channel 1: Packet counter is 3458 after 5.000326 seconds. Channel 2: Packet counter is 3461 after 5.000326 seconds. Channel 3: Packet counter is 3452 after 5.000326 seconds. Combined: 2766.219482 packets per second Die 1,40 MHz SPI Speed laufen aber runder, weil ich für alle Kanäle die (fast) identische Anzahl von Paketen bekomme, während ich bei den 1,95 MHz starke Abweichungen erkennen kann. Die Error Counts der Accelerometer V2 Bricklets geben keine Auskunft über einen möglichen Grund. Für beide SPI Speeds bekomme ich folgende Werte: Channel 0: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 1: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 2: Ack Checksum: 0, Message checksum: 0, Count frame: 0, Count overflow: 0 Channel 3: Ack Checksum: 0, Message checksum: 1, Count frame: 0, Count overflow: 0 Ich gucke in den nächsten Tagen mal, warum die Abweichungen bei 1,95 MHz zu erkennen sind. Oder liegt es einfach an der Tatsache, dass die Performance des BCM2835 chips für mehr nicht ausreicht?

Update: Ich bin zurück auf dem Kernel 4.19.97+ #1294 Also es liegt bei mir an dem core_freq=250 Eintrag. Wenn ich den nicht auf 250 setze (standardmäßig ist nichts definiert in der /boot/config.txt), dann läuft das neue Raspberry Pi HAL nicht. Auch kann ich die BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ nicht auf 1950000 hochsetzen. Nur mit dem Defaultwert (1400000) kann ich bei mir überhaupt Kontakt zu den Bricklets aufnehmen. Aber das Programm findet auch mit dem alten Kernel weiterhin nur selten alle vier angeschlossenen Bricklets. Mit dem core_freq=250 Eintrag bekomme ich zumindest teilweise die alten Werte wieder (867 Packages). Auf deine Werte aber komme ich nicht (2000 PPS bei 1,4MHz und 2650 PPS bei 1,95MHz).

Mit dem Pi Zero, HAT Zero Brick und dem 5.4.51+ Kernel läuft es scheinbar noch nicht gut. Du hattest ja auch von möglichen Kernel Problemen gesprochen. Aber kein Problem, ich gehe erstmal zurück auf den alten Kernel und teste damit weiter.

Sorry mein Fehler, das war das falsche main.c, was angehangen habe. Lokal auf dem Pi lag aber das Richtige (siehe neuer Anhang). Auszug aus meinem Makefile: # Executable name TARGET := linux_demo CC = $(CROSS_COMPILE)gcc CFLAGS += -std=gnu99 -Ofast -Wall -Wextra -Wno-padded -I.. LDFLAGS += -pthread LIBS += -lrt -ldl WITH_DEBUG ?= yes ifeq ($(WITH_DEBUG),yes) CFLAGS += -g -ggdb endif # These files are always required when using the bindings SOURCES_BINDINGS := bindings/base58.c \ bindings/bricklet_unknown.c \ bindings/endian_convert.c \ bindings/errors.c \ bindings/hal_common.c \ bindings/packetbuffer.c \ bindings/pearson_hash.c \ bindings/spitfp.c \ bindings/tfp.c \ # HAL specific files #SOURCES_HAL_LINUX := hal_linux/hal_linux.c \ # hal_linux/gpio_sysfs.c \ # hal_linux/utils.c \ SOURCES_HAL_LINUX := hal_raspberry_pi/hal_raspberry_pi.c \ hal_raspberry_pi/bcm2835.c \ # List your used devices here SOURCES_DEVICES := bindings/bricklet_accelerometer_v2.c main.c

Das passiert in angehangenem Programm auf dem Pi Zero. Ich nutze dein tf_hal_callback_tick(&hal, 5000000); dafür. main.c

Ok. Ich habe jetzt die Beta 5 getestet. Es kommt dazu, dass ich nicht immer alle Bricklets ansprechen kann. Es sind aber immer andere, die das Hal nicht finden kann. Die Anzahl der Pakete (max. 85) erscheint mir als ein wenig gering. Ich werde mal schauen, wodran das liegt. Es müssten aber mindestens 867 sein, wie im oberen Beispiel. pi@raspberrypi:~/tf/source $ sudo ./linux_demo Found device 2kAkfr of type 2130 at port A Found device 2kBkGe of type 2130 at port B Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Failed to create acc: no device with the given UID is reachable (return code -10, errno 0) Segmentation fault pi@raspberrypi:~/tf/source $ sudo ./linux_demo Found device 2kBkGe of type 2130 at port B Found device 2uvASe of type 2130 at port C Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Failed to create acc: no device with the given UID is reachable (return code -10, errno 0) Segmentation fault pi@raspberrypi:~/tf/source $ sudo ./linux_demo Found device 2kAkfr of type 2130 at port A Found device 2kBkGe of type 2130 at port B Found device 2uvASe of type 2130 at port C Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Channel 0: Packet counter is 48 after 5.000009 seconds. Channel 1: Packet counter is 85 after 5.000009 seconds. Channel 2: Packet counter is 77 after 5.000009 seconds. Channel 3: Packet counter is 81 after 5.000009 seconds. Combined: 58.199894 packets per second 436.499205 samples per channel per second pi@raspberrypi:~/tf/source $ sudo ./linux_demo Found device 2kAkfr of type 2130 at port A Found device 2kBkGe of type 2130 at port B Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Failed to create acc: no device with the given UID is reachable (return code -10, errno 0) Segmentation fault

Ich habe noch eine andere Frage. Es ist statistisch erkennbar, dass ich nie eine identische Anzahl von Nachrichten für die verschiedenen Kanäle bekomme. Das ist erstmal nicht so schlimm, da die 5 Sekunden halt irgendwann vorbei sind und dann einige Pakete nicht mehr mit gezählt werden. Es ist aber so, dass ich für das Bricklet an port a immer mit Abstand die meisten Pakete bekomme. Im Schnitt sind das 15 mehr als Kanäle b, c, und d. Das kann ich mir nicht erklären. Auch deckt sich das mit Beobachtungen meiner anderen Programme, bei denen ich den Brick Daemon nutze. Wenn ich beispielsweise eine Minute lang Messwerte abfrage (Continuous Callback mit den Accelerometer V2 Bricklets) und sekündliche Statistiken ausgebe, dann sehe ich diesen Sachverhalt in jeder einzelnen Sekunde. Auf Dauer führt das dann dazu, dass die Kanäle sich relativ zueinander verschieben. Gibt es hierfür eine technische Erklärung? Mache ich was falsch? Besten Dank! pi@raspberrypi:~/tf $ sudo ./linux_demo Hello World! Found device 2kAkfr of type 2130 at port A Found device 2kBkGe of type 2130 at port B Found device 2uvASe of type 2130 at port C Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Channel 0: Packet counter is 1094 after 5.000550 seconds. Channel 1: Packet counter is 1079 after 5.000550 seconds. Channel 2: Packet counter is 1080 after 5.000550 seconds. Channel 3: Packet counter is 1079 after 5.000550 seconds. Combined: 866.304749 packets per second 6497.285614 samples per channel per second pi@raspberrypi:~/tf $ sudo ./linux_demo Hello World! Found device 2kAkfr of type 2130 at port A Found device 2kBkGe of type 2130 at port B Found device 2uvASe of type 2130 at port C Found device Wdm9R of type 2130 at port D Found device JUj of type 112 at port E Channel 0: Packet counter is 1095 after 5.000013 seconds. Channel 1: Packet counter is 1081 after 5.000013 seconds. Channel 2: Packet counter is 1081 after 5.000013 seconds. Channel 3: Packet counter is 1079 after 5.000013 seconds. Combined: 867.197754 packets per second 6503.983154 samples per channel per second

Kannst du uns den Quellcode zeigen? Dann können wir einen möglichen Fehler erkennen.

Ich nutze momentan auf dem Pi Zero gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) mit den gleichen Flags wie du (-Ofast -std=gnu99) Die Kernel Version ist 5.4.51+ und der arm_freq=800 Eintrag ist nicht aktiv. Mit deinem Testprogramm und vier Accelerometer V2 Bricklets komme ich auf kombinierte 867 Pakete pro Sekunde. Channel 0: Packet counter is 1095 after 5.000120 seconds. Channel 1: Packet counter is 1081 after 5.000120 seconds. Channel 2: Packet counter is 1080 after 5.000120 seconds. Channel 3: Packet counter is 1080 after 5.000120 seconds. Combined: 867.179138 packets per second 6503.843536 samples per channel per second BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ habe ich hierbei nicht verändert (ist ja im Default auf 1400000 gesetzt).

Noch was: Wenn ich die BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ in hal_linux.c auf 2000000 setze, sorgt das bei der Beta3 dafür, dass die Anzahl der empfangenen Werte stark schwangt. Während es bei 1400000 stabile Werte zwischen 12000 und 12300 pro Bricklet gibt, schwankt bei 2000000 die Anzahl der empfangenen Werte zwischen 11000 und 13000. Das mag aber auch an einer Raspberry Pi Zero spezifischen SPI Implementierung liegen? Ich habe irgendwo in den Bindings gesehen, dass man bei den Raspberry 3 Modellen irgendwas ändern soll?

Das geht bei mir nicht. Wenn ich auf das Hal ticke, passiert nichts (also ich bekomme keine Ausgaben aus meinen Callbacks). Muss das vielleicht außerhalb der demo_loop() aufgerufen werden (was aber ja eigentlich keinen Unterschied machen dürfte)? Ich bekomme jetzt mit der Beta3 ca. 12000 Werte pro Bricklet, das sind in etwa 1000 mehr als bei der Beta2 🙂

Sehr cool. Genau das habe ich gesucht! Habs direkt getestet und es läuft. Kurzes Feedback noch zum Raspberry Pi Zero (mit HAT Brick). Ich kriege mit drei angeschlossenen Accelerometer V2 Bricklets mit den Defaulteinstellungen der Bindings und einem 16 Bit Continuous Callback (eine Achse) ca. 11000 Werte die Sekunde pro Bricklet.

Bietet die API die Möglichkeit, die UIDs der angeschlossenen Bricklets zu erfragen? Ich habe im Code gesehen, dass es zumindest eine entsprechende Methode existiert. bool tf_hal_enumerate_handler(TF_HalContext *hal, uint8_t port_id, TF_Packetbuffer *payload) Bietet sie intern die gleichen Möglichkeiten wie in den normalen C/C++ Bindings?

Komisch! Das mache ich auch nicht, wenn der Zugriff auf die SPI Schnittstelle (nach Deaktivierung des Brick Daemon) funktioniert. Also ich lasse das Programm nie mit Root-Rechten laufen. Kann ich aber ab jetzt machen. Stabile 12800 Hz reichen für mich erstmal aus. Aber die Option mit der Unterteilung in zwei Threads sehe ich mir definitiv genauer an. Es ist auch so schon ein enormer Vorteil, wenn ich direkt mit den Bricklets sprechen kann. Denn jetzt (ohne Brick Daemon) wird auch das Raspberry Pi Zero wieder attraktiv für datenhungrige Anwendungen. Ich werde weiter testen und Bescheid geben, was sich ergibt. Besten Dank!

Anbei meine erweiterte Demo für die 4 Accelerometer V2 Bricklets mit Continuous Callback. Aus irgendeinem Grund funktioniert aber das normale (Periodic) Callback nicht mehr, seit ich den Continuous Callback drin habe. Ist da irgendeine Reihenfolge falsch? Ich komme mit den Default Werten für TF_TFP_SLEEP_TIME_US (250) und 250 us Tick-Intervall in der demo_loop() auf jeweils ca. 12500 Werte für alle vier Accelerometer V2 Bricklets. Ich lese eine Achse bei 16 Bit Auflösung. Das ist noch vergleichbar mit dem Brick Daemon. Ich denke aber, dass man das noch optimieren kann. demo_continuous.c

Wenn ich den Brick Daemon am Raspberry Pi deinstalliert habe, bekomme ich keinen Kontakt zu den Bricklets. Es geht bei mir nur, wenn ich den Brick Daemon habe und nach jedem Neustart deaktiviere. Could not open '/sys/class/gpio/gpio25/direction': EACCES (13)Failed to init hal: failed to set GPIO direction (return code -101) Failed to create acc: -10 Segmentation fault Was mache ich falsch?

Den Callback-Tick habe ich noch nicht ganz verstanden.Ich gebe zu, ich konnte mir die API noch nicht im Detail angucken und weiß daher nicht genau, wie die callback_tick Routinen funktionieren. Wenn das Programm für 1000 µs blockiert und Callbacks eines Bricklets empfängt und ausliefert, dann verpasse ich doch die Callbacks der anderen angeschlossenen Bricklets oder nicht? Daher habe ich 250 µs gewählt, damit ich zumindest in 1 ms alle (in meinem Fall) vier Bricklets abfragen kann.

Achso, was ich vergessen habe. Wenn du sagst, dass High Level Callbacks nicht unterstützt werden, was genau meinst du damit? Sind beispielsweise die Connect, Disconnect oder Enumerate Callbacks High Level?

Erstmal Danke an Erik! Sehr cool, dass das jetzt möglich ist. Ich werde damit in Zukunft viel arbeiten, das steht fest! Ich habe ein paar schnelle Tests gemacht, nur um zu schauen, wie der Workflow ist und ob alles so arbeitet, wie es sollte. Ich habe ein RaspBerry Pi 4 mit TF Hat genommen, um 4 Accelerometer V2 Bricklets anzusteuern. Ich habe die entsprechende demo.c angehangen (Achtung: Quick & Dirty Programmierung). Es hat alles auf Anhieb funktioniert. Ich checke in der kommenden Woche, was passiert, wenn ich die Continuous Callback verwenden an allen 4 Bricklets und wie hoch ich gehen kann damit. Cheers, Claudio demo.c

Oha! Das ist spannend. Ich werde auch anfangen zu testen und euch Feedback geben!

Wir haben verschiedene Spannungsversorgungen getestet, auch ein normaler PC. Einen speziellen Aufbau haben wir nicht. Wir nutzen nur eure Bausteine. Wir haben jedoch den Verdacht, dass es bei uns im System ein Masseproblem ist. Daher haben wir zum Testen den 0 ohm Widerstand (R1) des IDAI v2 Bricklets entfernt und den AGND Teil dann mit dem AGND des Master Bricks direkt verbunden. Das hat dafür gesorgt, dass der Störpegel von 80 mV auf ca. 3 mV gesenkt werden konnte (was für uns erstmal ausreicht). Das HF Rauschen wurde von 100 kHz auf 1 MHz erhöht. Ich habe noch keine Antwort auf die Frage, wo die 2,5 Hz bzw. 5 Hz herkommen. Wir schauen mal, ob wir noch mehr rausfinden können. Vielen Dank aber schon mal an dieser Stelle für deine Hilfe!

Wir haben heute Messungen gemacht. Die Störung ist auf allen 2/4/6/8 angeschlossenen Kanälen messbar. Grundsätzlich kann man sagen, dass es keinen Unterschied macht, ob man ein, zwei, drei oder vier Bricklets angeschlossen hat und ob man IN+ und IN- verbindet. Das Scope hat folgende Ergebnisse geliefert: Ein IDAI v2 Bricklet: Störsignale um die 5 Hz mit einer Amplitude von bis zu 40 mV Zwei IDAI v2 Bricklets: Störsignale um die 2,5 Hz mit einer Amplitude von bis zu 80 mV Drei und vier IDAI v2 Bricklets: Hier ändert sich nicht mehr viel zu den Zahlen mit zwei Bricklets (siehe 2.)

Ich messe auch die Signale, die eigentlich zu messen wären. Lose Kabel sind nicht verbunden, die als Antennen dienen könnten. Die Störungen treten ortsunabhängig auf ... egal ob im Garten, im Haus oder im Büro. Auch in einem 10 km entfernten Ort habe ich das Störsignal. Wir messen das morgen mal mit dem Scope und geben Bescheid, sobald wir die Messergebnisse haben.

Hallo zusammen, ich habe momentan zwei Industrial Dual Analog v2 Bricklets an einem Master Bricklet angeschlossen. Testweise auch mit zwei Isolator Bricklets dazwischen (was jedoch das Störsignal nicht verändert). Ich bekomme ein 5 Hz Störsignal auf die Leitung, auch wenn ich die Eingänge der IDAI v2 Bricklets offen lasse. Ich verwenden nur TF Bricklet Kabel. Hierbei ist es egal, ob ich das Notebook mit oder ohne Netzteil laufen lasse. Hattet ihr das Problem auch schon mal? Ein solches Signal kenne ich sonst nur von Wellengleichungen. Habt ihr eine Idee, wo ich noch mal nachgucken sollte? Cheers, Claudio