Jump to content

cl-

Members
  • Content Count

    73
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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? 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?
  2. 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!
  3. 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?
  4. 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).
  5. 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.
  6. 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
  7. Das passiert in angehangenem Programm auf dem Pi Zero. Ich nutze dein tf_hal_callback_tick(&hal, 5000000); dafür. main.c
  8. 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
  9. 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
  10. Kannst du uns den Quellcode zeigen? Dann können wir einen möglichen Fehler erkennen.
  11. 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).
  12. 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?
  13. 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 🙂
  14. 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.
  15. 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?
×
×
  • Create New...