cl-

The current macOS Brick Viewer version (2.4.20) can't find the OpenGL library to display the 3D view of the IMU 3.0 Bricklet.
I'm on macOS 12.0.1.

What OpenGl library are you looking for? PyOpenGL or something else?
In the source I could only find QT packages which I'm sure I have installed.

Cheers
Claudio

Bei mir unter Big Sur auf MacBook Pro (Mid 2015) läuft alles problemlos

Sorry! Das ist nicht so leicht zu verstehen. Vielleicht brauche ich noch einen Kaffee!

Wenn das Accelerometer Bricklet einen kontinuierlichen 8bit Callback für eine Achse eingestellt hat, dann bekomme ich nach dieser Rechnung 1000 Pakete mit jeweils 60 Werten pro Sekunde. Das macht dann 60.000 Samples pro Sekunde, obwohl der Accelerometer nur 25600 pro Sekunde konvertiert. Heißt das in diesem Fall, dass keine 1000 Pakete pro Sekunde, sondern eben nur 427 gesendet werden, um die 25600 Samples auszuliefern?

9 minutes ago, rtrbt said:

Edit: die 300µs Übertragungszeit musst du nicht kompensieren, das Accelerometer misst währendessen ja weiter.

Das meine ich so, dass wenn man alle Signale zeitlich miteinander korrelieren will, haben alle Samples mit dem gleichen Index in den jeweiligen Arrays/Vektoren im besten Fall den gleichen Zeitstempel. Da das beim nacheinander Pollen nicht möglich ist, ist signal[1].time[0] immer die (beispielsweise) 300 µs älter als signal[0].time[0], signal[2].time[0] immer die 300 µs später als signal[1].time[0], etc. Ich greife ja nacheinander, um eben die 300 µs verschoben, auf den gleichen Index zu, wenn ich einzelne Werte der Reihe nach speichere.

Das ist soweit auch nicht schlimm, als ich den Zeitversatz ja dann kenne und beim Vergleichen der Samples entsprechend des resultierenden Zeitversatzes (Indizes werden verändert) kompensiere. Somit vergleiche ich immer Daten mit möglichst identischen Zeitstempeln miteinander. Oder habe ich hier was nicht verstanden?

Ah ok. Ich verstehe! Ich habe noch ein paar Fragen dazu.

1 hour ago, rtrbt said:

Das Callback-Polling funktioniert intern so, dass die Bindings vom Bricklet ein Byte Daten abfragen, wenn das 0 ist, dann hat es gerade keine Daten zu senden. Dann wird das nächste Bricklet gepollt.

Hat ein Bricklet nicht immer Daten zu versenden? Kann dieser Zustand nicht nur am Anfang passieren, wenn das Bricklet gerade erst konfiguriert wurde?

1 hour ago, rtrbt said:

Wenn du jetzt pech hast und Bricklet X hat sein Paket gerade noch nicht bereit, dann werden erst die drei anderen Bricklets abgefragt, bevor es wieder dran kommt. Das kostet im schlimmsten Fall (wenn alle anderen Bricklets Pakete bereit haben) ~900µs, also fast eine Millisekunde, also ist Bricklet X selbst wenn jetzt alles perfekt läuft aus dem Takt und hängt immer ein Paket hinterher.

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.

1 hour ago, rtrbt said:

Ich vermute, dass du, wenn du da noch das letzte Paket rausquetschen willst (und vor allem im Takt bleiben), dann musst du die einzelnen Bricklets von Hand ticken, und zwar so, dass du erst wieder alle vier Bricklets tickst, wenn du alle vier Pakete der letzten Runde hast.

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.

5 minutes ago, rtrbt said:

Im Demo-Programm sehe ich spontan, dass du den hal_raspberry_pi includest, aber noch tf_hal_linux_init aufrufst. Das musst du mal anpassen und vermutlich auch dein Makefile.

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

19 minutes ago, rtrbt said:

Das hängt vermutlich davon ab wie du die Callbacks tickst. Was benutzt du dafür im Moment?

Abgesehen davon ist das vermutlich ein Effekt, den du nur beobachten kannst, weil das Programm praktisch permanent überlastet ist. Wenn du es schaffst alle Pakete die die Bricklets erzeugen zu verarbeiten, sollte das nicht mehr auftreten. Die Bricklets generieren Pakete ja mit einer festen Frequenz.

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.

On 7/22/2020 at 11:47 AM, rtrbt said:

• Welchen Compiler und welche Flags benutzt du? (Ich im Moment arm-linux-gnueabihf-gcc (GCC) 10.1.0 mit -Ofast -std=gnu99 )
• Welchen Kernel hast du auf dem Pi und hast du einen core_freq- oder arm_freq-Eintrag in der /boot/config.txt? (Ich im Moment Linux 4.19.97+ #1294 und core_freq=250)

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?

28 minutes ago, rtrbt said:

 

uint32_t bench_start = tf_hal_current_time_us(&hal);

while (tf_hal_current_time_us(&hal) - bench_start < 5000000) {
  tf_hal_callback_tick(&hal, 0);
}

 

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?

32 minutes ago, rtrbt said:

Das sieht aus als ob du das Programm nicht als Root startest. Die Root-Rechte brauchst du, damit du auf die SPI-Schnittstelle zugreifen darfst.

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.

Quote

Falls du wirklich den vollen Durchsatz brauchst, sehe ich als Option nur noch, dass du einen ESP32 nimmst. Der ESP hat zwei benutzbare SPI-Einheiten, theoretisch könntest du einen HAL für jede SPI-Einheit anlegen und dann die HALs und deren zugeordnete Bricklets mit jeweils einem eigenen Thread auf einem der zwei Kerne des ESPs laufen lassen.

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?

1 hour ago, rtrbt said:

Die Demo sieht soweit gut aus, es kann aber sein, dass du den Callback-Tick pro Device etwas länger ziehen musst, auf dem Raspberry Pi kann es dir bei ungünstigem Scheduling sonst passieren, dass du auf einem Device garnicht tickst und auf einem anderen dafür mehr, ist ja kein Echtzeitsystem. Bei meinen Tests meine ich mich daran erinnern zu können, dass etwas im Bereich 500 oder 1000µs besser lief.

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!