rtrbt

Moin, Das verwirrt noch mehr. Die Relays haben bei allen Tests mit den Programmen 60 Sekunden abwechselnd geschaltet? Oder ist das Problem (bei HAT Firmware 2.0.2, die 2.0.3 kannst du künftig wieder ignorieren) nochmal aufgetreten, aber die Ausgabe hat sich nicht geändert? Mit dem Brick Viewer passiert es aber weiterhin? Um den gebroadcasteten Paketen im brickd.log nachzugehen, habe ich vom Brick Daemon eine Variante gebaut, die mehr Informationen liefert, wenn ein Paket defekt ist. Die ist in zwei Varianten im Anhang, einmal die 2.4.1 + das Logging, einmal alle Änderungen die wir seit der 2.4.1 schon hatten + das Logging. Bitte installiere mal jeweils eine Variante davon, reproduziere das Problem mit dem Brick Viewer und hänge das entsprechende brickd.log an. (Wegen der Übersicht: Bennene erstmal das brickd.log, dass du schon hast, um, sonst werden die Dateien so groß) brickd-2.4.1~log_armhf.deb brickd-2.4.2~log_armhf.deb

Moin, Hast du den Kernel über rpi-update auf die 5.4. aktualisiert? (kannst du auf der Konsole mit uname -a prüfen) Mit dem Kernelupdate kamen Änderungen am Device-Tree, mit denen die HAT+Brick Daemon-Kombination Probleme hat. Wir haben im Moment zwei Ansätze, das Problem zu lösen. Es gibt eine neue Firmware für das HAT, die mit dem geänderten Device-Tree umgehen kann, aber die bekommst du nicht geflasht, weil du schon auf dem neuen Kernel bist. Deshalb Ansatz 2: Installiere mal die angehangene Version vom Brick Daemon mit sudo dpkg -i brickd-2.4.1_armhf.deb Diese Version verwendet nicht mehr das spidev des Kernels, sondern kommuniziert direkt mit dem BCM2835-Chip. Das sollte das Problem umgehen und nebenbei etwas performanter sein. Du kannst dann darüber die neue HAT-Firmware flashen. Gruß, Erik brickd-2.4.1_armhf.deb

Sorry, dass die Antwort etwas gedauert hat. Das hat mich erst sehr verwirrt. Anscheinend bricht die Performance mit dem 5.4er Kernel ziemlich ein, obwohl das Kernelupdate eigentlich den gegenteiligen Effekt haben sollte (siehe z.b. hier) Ich habe deshalb (und weil es mit HAT und Brick Daemon Probleme mit dem neuen Kernel gibt) einen neuen HAL geschrieben, der direkt mit dem BCM2835-Chip spricht, der die GPIOs steuert. Falls du den HAL testen möchtest, habe ich ihn mal angehangen. Die Init-Funktion heißt noch tf_hal_linux_init und nimmt den spidev-Pfad, das wird aber ignoriert, ich habe das Interface noch nicht verändert, damit man einfacher hin und her wechseln kann. Du musst dann im Makefile folgende Änderung machen: SOURCES_HAL_LINUX := hal_linux/hal_linux.c \ hal_linux/gpio_sysfs.c \ hal_linux/utils.c \ ersetzen durch SOURCES_HAL_LINUX := hal_bcm2835/hal_linux.c \ hal_bcm2835/bcm2835.c \ Bei meinen Tests läuft der HAL bisher deutlich besser: ich komme auf 2000 PPS bei 1,4MHz und 2650 PPS bei 1,95MHz. hal_bcm2835.zip

You could connect your Bricklet to a PC over a Brick. Then you can check the UID with Brick Viewer. Also the bindings print the UID of all attached Bricklets to the serial console when calling tf_hal_arduino_init(). (This only works if the Bricklet is detected, so only with a level shifter in your case)

Hier das Testprogramm in zwei Variationen: Mit dem HAL der dem Brick Daemon entspricht und alternativ mit dem HAL, der direkt mit dem GPIO-Chip des Raspberry Pi kommuniziert. Du musst für beide Testprogramme erst den Brick Daemon auf dem Raspberry Pi mit "sudo systemctl stop brickd" beenden, danach kannst du die Programme laufen lassen. Ich habe dir den Source mal mit angehangen, beide Programme schalten die Relays im Wechsel und lesen die Monoflop-Informationen zurück. Poste mal bitte die Ausgaben beider Programme. embedded_c_hal_bcm2835 embedded_c_hal_linux main.c

Anschlussfrage: Hast du während das HAT Strom hatte die Bricklets an/ab/umgesteckt? Edit: Da war ich zu optimistisch am frühen Morgen, ich habe mir einfach ein Hot-Plug-Problem erzeugt, das ist aber nicht das selbe Problem, das du hast.

Moin, Ich habe hier mit dem Aufbau nochmal rumgetestet und konnte es jetzt reproduzieren. Bei mir reicht es, am Dual Relay an Port C Channel 0 zu schalten, dann werden sofort Timeouts hochgezählt. Passiert es bei dir auch, dass das Digital In an Port B schnell zu blinken anfängt, wenn du beim Relay an Port C Channel 1 schaltest?

Hi, Are you using some kind of level shifter between the Uno and the bricklet? This is required as the Uno (and all other AVR based Arduinos) have a logic level of 5V, but the bricklets only work with 3.3V. Some Unos seem to understand the 3.3V high level as a 5V high level, but some don't. The error code -10 indicates that the bindings can't find the bricklet (see errors.h), so you either have the logic level problem from above, or you use the wrong UID. The bindings will print all found devices to the serial console when tf_hal_arduino_init runs. You can connect to the serial console (maybe add a delay(5000) at the top of your setup-function, so you don't miss the output) and check if the bindings see the bricklet under another UID.

Die Infos kannst du ignorieren, das ist ein bekanntes Problem. Ich habe aber bisher noch nicht rausgefunden, wo das herkommt. Edit: Funktioniert die Regel abgesehen von den Meldungen?

*hust* nimm mal Beta 4. Das liegt vermutlich daran, dass der Pi Zero die Timings dann nicht ganz schafft. Ich bin hier mal auch auf einen Zero umgestiegen, am besten läufts bei mir im Bereich 1950000 bis 1960000. Ich komme aber trotzdem nicht auf deine Werte. Kannst du mal das angehangene Programm testen und mir im Gegenzug dein aktuelles Testprogramm schicken? Außerdem folgende Fragen: 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) main.c

Teste das nochmal mit Beta 3, die ich gerade in den Post oben eingefügt habe: Du kannst jetzt den Tick-Funktionen 0 als Timeout mitgeben, dann versuchen sie nur ein Callback zu empfangen, dass sofort gelesen werden kann, aber blockieren nicht weiter. Außerdem kannst du jetzt Callbacks z.b. so für 5 Sekunden ticken: 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); } Bei meinen Messungen war das praktisch genauso schnell, wie das Ticken von Hand auf die vier Bricklets zu verteilen. (Ich habe aber nur mit einem Pi 3 getestet, nicht einem Zero)

Ja, aber nicht mit dem enumerate_handler. Der ist nur für die interne erste Suche, was angeschlossen ist. Offiziell gibt es die Funktion bool tf_hal_get_device_info(TF_HalContext *hal, size_t index, char ret_uid[7], char *ret_port_name, uint16_t *ret_device_id); Die Funktion gibt dir zurück, ob der HAL das n-te Bricklet (index) kennt und falls ja schreibt sie in ret_uid, ret_port_name und ret_device_id die entsprechenden Informationen. Wenn die Funktion false zurückgibt ist der Index zu groß. Benutzen kannst du die Funktion dann z.b. so um das erste Device mit einer Device-ID zu finden. (Wie bei den normalen C-Bindings gibt es im entsprechenden Header ein define für die Device-ID, z.b. TF_ACCELEROMETER_V2_DEVICE_IDENTIFIER bool find_first_uid_by_did(uint16_t device_id, char uid[7]) { char pos; uint16_t did; for (size_t i = 0; tf_hal_get_device_info(&hal, i, uid, &pos, &did); ++i) { if (did == device_id) { return true; } } return false; } Wenn du alle Bricklets sehen willst, die angeschlossen sind, kannst du folgendes machen: int i = 0; char uid[7] = {0}; char port_name; uint16_t device_id; while(tf_hal_get_device_info(&hal, i, uid, &port_name, &device_id)) { printf("Device %d: %s of type %d at port %c\n", i, uid, device_id, port_name); ++i; }

Was es nicht alles gibt. Auf dem LCD ist dann auch nichts zu sehen? Soweit ich das sehe, (sind das diese Nodes?) sind die für Items, nicht für Actions. D.h. du müsstest irgendwie ein Item für den Text-Channel des LCDs anlegen und da dann einen String im Format "0,1,Hello World!" reinschreiben. Wenn du Node-RED benutzen willst kannst du aber alternativ zu den openHAB-Bindings auch die MQTT-Bindings verwenden, Node-RED kommt mit MQTT ziemlich gut klar.

Das ist eine gute Frage, ich habe das immer nur über die PaperUI gemacht. Da kannst du sowohl das Item anlegen (blau) als auch den Channel konfigurieren (rot). Wenn du das zwingend über die Textdateien machen willst: Ich habe beim danach suchen diesen Thread gefunden, das sieht so aus als könnte es funktionieren. Edit: Man sollte das Bild auch anhängen

Das macht der Brick Viewer für dich.

Moin, Hast du die tinkerforge-2.1.26.jar aus der Java-Bindings-Zip oder aus der openHAB-Bindings-Zip? Mir fällt gerade auf, dass die nicht die selben sind, zweitere sind ein Maven-Bundle. Ich editiere mal meinen Post oben, da linke ich auf die falsche Datei, sorry dafür. Führe in der Konsole mal sha256sum /usr/share/openhab2/addons/tinkerforge-2.1.26.jar aus. Korrekt ist die 22c9d235f1c62c29a4ec4c9d1feccccf0e6f8b33. Wenn du da etwas anderes rausbekommst, musst du die Datei durch die aus den openHAB-Bindings ersetzen.

Hi, By rebooting the Pi you mean power cycling it or just a software reboot? A software reboot does not restart the connected Master Brick, so this would indicate, that your problem is not the Brick or the Motion Bricklet. If this happens again, it would be interesting to see, if you can still connect to the Pi with Brick Viewer and if so, whether the Motion Bricklet is still working. Also the Brick Daemon log (/var/log/brickd.log) could be useful.

Moin, Das das Bricklet nach dem Reset nicht wieder auftaucht liegt vermutlich daran, dass dessen Enumerate-Paket verloren gegangen ist. Wenn du Reconnectest, löst das auch eine Enumerierung aus, dann taucht das Bricklet wieder auf. Bezüglich der hängenden Temperatur selbst: Teste mal bitte die angehangene Firmware, die I2C-Kommunikationsfehler subtil anders behandelt, eventuell löst das dein Problem. Ich habe meinen Aufbau hier auch darauf umgestellt. temperature-v2-bricklet-firmware.zbin

Moin, 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. Eventuell musst du erst set_configuration und dann die set_(continuous_)acceleration_callback_configuration aufrufen. Habe ich aber nicht getestet. Ich habe das hier mal getestet und komme auf 1850 Pakete pro Sekunde, also ~13900 Werte pro Sekunde und Bricklet (d.h. es würde für 16-Bit-Werte einer Achse mit 12800Hz reichen). Ich habe dabei die BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ in hal_linux.c auf 2000000 gesetzt, dann läuft die SPI-Kommunikation mit 2MHz, was das Maximum ist, das die Bricklets können und die Callback-Tick-Optimierung eingebaut, die ich erwähnt hatte. Ich habe dann mal mit dem Logic-Analyzer nachgesehen und festgestellt, dass selbst wenn ich das Programm "ideal" optimieren würde, man nicht die 25600 Hz bei 4 Bricklets schaffen wird: Der Linux-Kernel macht zwischen jedem Byte eine etwas längere Pause, die effektive Durchschnittsfrequenz liegt bei ~1.76 MHz. Mit der Frequenz kommt man dann auf 220 kByte/s unter der Annahme, ich könnte durchgängig Daten per SPI senden/empfangen. Ein Paket hat 60 Byte Payload, dazu 11 Byte Protokollheader usw. macht 71 Byte, ergibt ~3100 Pakete pro Sekunde, also 23250 Werte pro Sekunde und Bricklet. Durch den Overhead des Programms und weil ich auch auf das Bricklet warten muss, bis ein Acknowledgement kommt usw. verliert man dann nochmal einiges, auch deshalb, weil es vorkommt, dass aufgrund von Timing-Pech das Pi oder das Bricklet ein Paket neu senden muss. 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.

Der Tick macht genau was du schreibst: Er blockiert für die übergebene Zeit und liefert Callbacks des Bricklets aus. Da auf einem Mikrocontroller kein Multitasking verfügbar sein muss, muss man das als Nutzer händisch machen. Hm, da hast du recht, für deinen Fall sind die 250µs wirklich sinnvoller. Noch ein Gedanke: Du willst ja eigentlich nicht die 250µs stehen, sondern falls innerhalb dieser Zeit ein Callback ankam weißt du ja, dass das nächste erst eine Millisekunde später kommen kann. Die Restzeit kannst du sinnvoller verwenden. D.h. ich baue in den Callback-Tick ein, dass du einen Timeout von 0 mitgeben kannst, das heißt dann "versuche ein Callback zu empfangen, falls gerade eins da ist, wenn nicht, brich sofort ab". Dann kannst du in deiner Loop alle Callbacks mit 0 als Timeout ticken und solltest damit nochmal deutlich effizienter sein. Du kannst ein ähnliches Verhalten testen, indem du TF_TFP_SLEEP_TIME_US in bindings/tfp.c auf z.b. 50 setzt und dann die Callback-Ticks mit z.B. 100µs aufrufst.

Hi Claudio, 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. Ob das Continuous Callback schneller läuft als mit dem Brick Daemon würde mich auf jeden Fall auch interessieren, poste da mal deine Ergebnisse, wenn du getestet hast. Ich benutze im Linux-HAL zwar den selben Code wie der Brick Daemon, aber es gibt ein paar Stellen an denen ich aggressiver mit den Timings sein kann (Zielplattform sind ja Mikrocontroller), da kann es gut sein, dass du etwas mehr Performance rausziehen kannst. Die drei Callbacks gibt es garnicht, Connect und Disconnect fallen weg weil kein Brick Daemon läuft, zu dem man sich verbinden kann, Enumerate fällt weg, weil die Bindings beim hal_init nachsehen, welche Devices angeschlossen sind, danach aber nur mit diesen Devices arbeiten. High-Level-Callbacks sind Callbacks, die High-Level-Funktionen sind. (So weit, so nichtssagend). High-Level-Funktionen sind alle die intern streamen, also einen Funktionsaufruf der Bindings, bestes Beispiel dafür ist write_pixels vom LCD 128x64, in mehrere Pakete aufteilen, weil der Payload (in diesem Fall bis zu 128*64 boolsche Werte) nicht in ein Paket passt. High-Level-Callbacks sind dann zum Beispiel die für die Thermal-Bilder vom Thermal Imaging Bricklet oder das Spektrum des Sound Pressure Level Bricklets. Edit: Alle High-Level-Funktionen (also auch die Callbacks) haben eine entsprechende Low-Level-Variante. Man kann die Funktionalität also trotzdem verwenden, muss sich aber das Streaming selbst implementieren. Ich habe die High-Level-Callbacks mit vorgegebener Streaming-Implementierung rausgenommen, da die Daten temporär gehalten werden müssen, sie aber definitiv zu groß für den RAM eines Mikrocontrollers sind. (z.B: 80*60*2 =9600 Byte für das Thermal-Bild) Wenn man als User jetzt seine eigene Streaming-Logik implementiert, kann man z.b. ohne dass man das ganze Thermal-Bild im RAM hält, die wärmste Stelle im Bild finden.

Moin, Nimm wie gesagt nur das NodeMCU mit dem HAT, der MEGA hat 5V Logikpegel, damit kannst du dir im schlimmsten Fall das HAT beschädigen. (Das HAT hat 3,3V Logikpegel, ich habe bei mir auf dem Tisch eins liegen, dass ich vermutlich genau mit diesem Fehler kaputt gemacht habe.) Es gibt 5 CS-Pins, weil das HAT Zero selbst einen Koprozessor hat. Aus Sicht der Bindings ist das HAT auch ein Brick, mit dem du Daten austauschen kannst. Im Sketch musst du die Pins auflisten, die du auf deiner Seite benutzt, also wenn du den MEGA weiter benutzt (mach das wie gesagt nicht!) wäre folgendes korrekt: TF_Port ports[5] = {{ .chip_select_pin=53, .port_name='A' }, { .chip_select_pin=49, .port_name='B' }, { .chip_select_pin=47, .port_name='C' }, { .chip_select_pin=45, .port_name='D' }, { .chip_select_pin=43, .port_name='I' }}; Ich vermute, dass deine Probleme mit dem Fehler -10 (errors.h sagt, das ist TF_E_DEVICE_NOT_FOUND) daher kommen, dass der MEGA die Antworten der Bricklets nicht versteht, weil ein 3,3V High nicht stark genug ist.

Hi, If you use ti.set_spotmeter_config([20,20,40,40]) it should work: set_spotmeter_config requires an array of 4 elements instead of passing the four parameters directly.

Moin, Hast du auf deinem Rechner auch eine statische IP konfiguriert? Auf der Extension läuft kein DHCP-Server. Folgende Einstellungen sollten beispielsweise funktionieren: Auf dem Rechner mit dem du dich auf die Extension verbinden willst: Adresse 10.0.0.2 Netzmaske 255.255.255.0 Gateway 10.0.0.1 Im Brick Viewer des Rechners musst du dann 10.0.0.1 als Host eintragen. Gruß, Erik

Das hängt davon ab was für ein Brick/Bricklet das ist, bei dem du den Button drückst. Wenn du einen Brick oder ein altes 10-Pol-Bricklet resettest, startet der ganze Stapel neu. Wenn es ein 7-Pol-Bricklet ist, dann nur das Bricklet selbst. Danke, ich baue das hier mal nach. Falls sich da was tut, melde ich mich nochmal.