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 korreliere
  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 d
  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
  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 t
  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 \ bin
  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
  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 bei
  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 650
  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...