Jump to content

cl-

Members
  • Content Count

    74
  • Joined

  • Last visited

Everything posted by cl-

  1. Bei mir unter Big Sur auf MacBook Pro (Mid 2015) läuft alles problemlos
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. Das passiert in angehangenem Programm auf dem Pi Zero. Ich nutze dein tf_hal_callback_tick(&hal, 5000000); dafür. main.c
  9. 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
  10. 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
  11. Kannst du uns den Quellcode zeigen? Dann können wir einen möglichen Fehler erkennen.
  12. 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
  13. 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?
  14. 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 🙂
  15. 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.
  16. 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?
  17. 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 u
  18. 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
  19. 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?
  20. 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.
  21. 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?
  22. 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 w
  23. Oha! Das ist spannend. Ich werde auch anfangen zu testen und euch Feedback geben!
  24. 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 Antwo
  25. 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 Brickle
×
×
  • Create New...