Jump to content

rtrbt

Administrators
  • Content Count

    601
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by rtrbt

  1. Bevor du mit dem Brick-Viewer drauf gehst frag mal (mit einem Python-Script oder sowas) die Callback-Konfiguration und die aktuelle Temperatur ab (jeweils mit dem Getter, nicht die Temperatur per Callback abfragen).
  2. Nein die Nachricht geht nur an das Bricklet, nicht an den Sensor selbst. Am Code fallen mir spontan zwei Dinge auf: Da deine Callbacks value_has_to_change=true haben, ist nicht so richtig unterscheidbar, ob die Temperatur gleich ist oder das Bricklet nicht mehr kommuniziert. Würde der Rest deiner Software das überstehen, da false mitzugeben? Dann kannst du auch viel strikter das Bricklet resetten, wenn z.b. 10 Sekunden lang kein Wert mehr kam. Du reagierst nur auf IPCON_ENUMERATION_TYPE_AVAILABLE, wenn das Bricklet sich neu startet (warum auch immer) bekommst du aber _CONNECTE
  3. Moin, Der Fehler war auch wieder, dass du über Minuten zwar Callbacks bekommen hast, aber die immer den selben Wert hatten? (Im Gegensatz zu du hast keine Callbacks mehr bekommen) Was macht dein Daemon mit dem Bricklet wenn ein Enumerate kommt? Nur Callbacks registrieren oder einen Reset oder den Heater an oder sowas? Das allein eine Enumerierung und ein Callback-Neuregistrieren eine eventuell hängendes I2C wiederbelebt ergäbe keinen Sinn, dann müssten wir die These wohl zu Grabe tragen. Gruß, Erik
  4. Für die Nachwelt: Wir haben telefonisch rausgefunden, dass es ein Hardwareproblem mit doppelt belegten GPIOs ist. Im HAT-Schaltplan kann nachgesehen werden, welche GPIOs vom HAT verwendet werden.
  5. Hm das stimmt, ich hatte bei mir den core_freq-Eintrag drin. Ich schreibe mir mal auf die Liste, dass ich die core_freq zur Laufzeit abfrage und die SPI-Clock entsprechend kompensiere. Das klappt aber nur, wenn force_turbo=1 ist, sonst schwankt die core_freq zur Laufzeit und ich bekomme nie eine stabile Clock. Damit die Tests sinnvoll sind habe ich eine neue Speicherkarte mit dem aktuellen Raspberry Pi OS (vom 27.05., Kernel 4.9.118) genommen. Wenn die core_freq nicht gesetzt wird, ist sie auf 400 Mhz, dann führt meine Einstellung auf 1,4 MHz dazu, dass in Wirklichkeit 1,4/250*400 = 2,24
  6. 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.
  7. 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.
  8. Der neue HAL ist jetzt als hal_raspberry_pi in Beta 5 enthalten. Da es jetzt etwas offizieller ist, habe ich den HAL umbenannt und den unnützen spidev-Parameter entfernt.
  9. Dann starte den Brick Daemon mal von Hand mit "sudo brickd".
  10. 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 se
  11. 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 verw
  12. 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
  13. 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)
  14. 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
  15. 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.
  16. 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?
  17. 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 co
  18. 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?
  19. *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
  20. 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 z
  21. 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 fi
  22. 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.
  23. 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
×
×
  • Create New...