eBus Schaltung Rpi in Betrieb nehmen!

Begonnen von Reinhart, 19 Februar 2018, 19:38:23

Vorheriges Thema - Nächstes Thema

pc1246

Moin
Wie waere es, wenn wir einfach einen RPI4 fuer galileo sammeln. Das haben wir bei HM-Teilen mit Martin auch schon gemacht.
Es reicht ja, dass er seine Zeit investiert, nicht auch noch sein Geld!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

erwin

ich wär mit 10€ dabei!
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Reinhart

Zitat von: erwin am 04 Dezember 2019, 13:45:05
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin

da staune ich, den habe ich erst am 02.12 versendet und das bei dem weihnachtlichen Poststress!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

pc1246

Zitat von: erwin am 04 Dezember 2019, 13:45:05
ich wär mit 10€ dabei!
PS: ich habe heute den rpi-adapter erhalten, danke Reinhart & Galileo!
l.g. erwin
Von mirgibt es auch €5,-. Fuer mich ist das nicht so immens wichtig, aber da ich ja angefangen habe!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

HeikoGr

Zitat von: pc1246 am 04 Dezember 2019, 13:00:57
Wie waere es, wenn wir einfach einen RPI4 fuer galileo sammeln.

Ich kann mich mit 5 EUR beteiligen.

galileo

Hallo Leute,
Vielen Dank für die angebotene finanzielle Hilfe für einen Raspi4, aber das ist überhaupt nicht notwendig.
Es ist viel mehr eine Frage der Zeit die mir zur Verfügung steht und ob ich damit das Problem lösen kann.
Ich versuche bereits seit Wochen eine generische Lösung für das Problem mit der Interrupt Zuordnung zu finden, bin aber bis jetzt kläglich gescheitert.
Viel besser als eine Spende wäre da ein richtiger Linux-Spezialist, der ich leider nicht bin, und der mir bei den Interrupts weiterhelfen könnte.
Trotzdem, ein Raspi4 zum Testen ist bereits unterwegs, und ich hoffe damit wenigstens wieder eine dedizierte Lösung zu finden, wenn schon nicht eine generelle.
Aber wie schon gesagt, den Rest dieses Jahres geht da leider gar nichts mehr...
Bis dahin bitte keinen Raspi4 für den ttyebus verwenden, sonder nur 1-3.
LG

erwin

Hallo Galileo,

danke für deine Bereitschaft, da nochmals Zeit zu investieren!
Ich hab etwas geforscht und folgendes herausgefunden:
Der BCM_2711 verwendet eine andere Base adresse, ich hab mich mal daraun versucht, aber mit den interupts bin ich nicht klar gekommen! Hier ein diff:--- //mh-qnap419p/Download/myFHEM_mods/ttyebus/ttyebusm.c_orig So Dez  8 08:52:26 2019
+++ //mh-qnap419p/Download/myFHEM_mods/ttyebus/ttyebusm.c So Dez  8 12:43:29 2019
@@ -57 +57 @@
-// #define DEBUG 1                  // if uncommented, will write some debug messages to /var/log/kern.log
+#define DEBUG 1                  // if uncommented, will write some debug messages to /var/log/kern.log
@@ -129,0 +130 @@ static int IrqCounter = 0;
+#define RASPI_4_PERI_BASE    0xFE000000              // RASPI 4
@@ -181,0 +183 @@ static int IrqCounter = 0;
+#define RASPI_4_UART_IRQ       87
@@ -183,0 +186 @@ static int IrqCounter = 0;
+#define RASPI_4_UART_IRQ       81
@@ -818,0 +822 @@ unsigned int ttyebus_raspi_model(void)
+        case '4' : return 4; break;
@@ -854 +858 @@ int ttyebus_register(void)
-    if (RaspiModel < 1 || RaspiModel > 3)
+    if (RaspiModel < 1 || RaspiModel > 4)
@@ -887 +891 @@ int ttyebus_register(void)
-    PeriBase = (RaspiModel == 1) ? RASPI_1_PERI_BASE : RASPI_23_PERI_BASE;
+    PeriBase = (RaspiModel == 1) ? RASPI_1_PERI_BASE : (RaspiModel == 4) ? RASPI_4_PERI_BASE : RASPI_23_PERI_BASE;
@@ -901 +905 @@ int ttyebus_register(void)
-    UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+    UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : (RaspiModel == 4) ? RASPI_4_UART_IRQ : RASPI_23_UART_IRQ;
@@ -948 +952,2 @@ void ttyebus_unregister(void)
-    UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+//    UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : RASPI_23_UART_IRQ;
+    UartIrq = (RaspiModel == 1) ? RASPI_1_UART_IRQ : (RaspiModel == 4) ? RASPI_4_UART_IRQ : RASPI_23_UART_IRQ;

Die Int's sind miseriös: Enable ich den Uart, bekomm ich int 34 auf dem PL-011.
Disable ich den Uart, bekommt der SPI-Bus den Int 34.....
irgenwas mit den GPIO setting dürfte auch anders sein, siehe hier:
https://github.com/RPi-Distro/raspi-gpio/blob/master/raspi-gpio.c

Bin nicht sicher ob das weiterhilft...
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

galileo

Hallo erwin,
danke für deine Bemühungen. Genau das ist ja das Problem: Die Interrupts werden vom Linux dynamisch zugewiesen, je nach vorhandener Konfiguration.
Nur leider konnte ich bis heute weder herausfinden, nach welcher Logik das stattfindet, noch konnte ich die aktuelle Zuweisung aus dem Kernel auslesen, *bevor* der ttyebus geladen wird.
Und das in der Literatur vorgeschlagene try-and-error Verfahren bei laufendem Treiber hat mir das System jedes Mal permanent gecrasht.
Der Interrupt 34 ist jedenfalls bisher noch nicht vorgekommen. Bisher waren es 81 und 87, aber da war die Hardware auch immer (fast) ident.
Dass die GPIOs anders belegt sind würde mich auch nicht wundern, weil der Raspi4 ja jetzt 5 UARTs hat. Da gibt's aber auch schon genügend Postings und Beschreibungen dazu.
Das alles gilt es also zu checken.
LG

galileo

Ich besitze jetzt einen Raspi 4 und habe mich nun intensiv mit dem ttebus/Raspi 4 Problem beschäftigt.
Es gibt dazu einige Erkenntnisse:

- Der Raspberry Pi 4 benötigt zwingend Raspbian Buster.
- Der von HeikoGr gemeldete Fehler beim "sudo make install" ist darauf zurückzuführen, dass "insmod $(TARGET_DIR)/$(TARGET_MODULE).ko" nunmehr kein ".ko" mehr haben darf.
  In den Versionen vor Buster musste es aber zwingend vorhanden sein. Eine mögliche Lösung des Problems wäre "modprobe" statt "insmode" verwenden, dort gibt's das Problem nicht.
- Die "Peripheral Base Address" ist bei Buster/Raspi4 nunmehr auf 0xFE000000 gewandert.
- Der I/O Address-Space hat sich in der Größe verdoppelt.
- Die UART Interrupt Behandlung im Raspbian Buster ist komplett umgestellt, soweit ich das beurteilen kann ist das jetzt ein "chained" model.
  Die direkten Interrupts verschwinden dadurch und können auch nicht mehr manipuliert werden. Damit erhält der ttyebus keine Interrupts mehr.

Da der Raspberry Pi 4 aber zwingend ein Raspbian Buster voraussetzt, kann der ttyebus auf diesem Board nicht funktionieren.
Ob Raspbian Buster auf einem Raspi 3 auch die Interrupts verändert oder vielleicht doch gleich lässt, habe ich noch nicht getestet.

Ich muss also leider alle Raspi4 Besitzer enttäuschen: ttyebus funktioniert auf Raspi 4 nicht, und wird vermutlich auch nie funktionieren.
Für ttyebus auf Raspi 1-3 muss ich momentan warnen, auf Raspbian Buster upzugraden oder es zu verwenden, das könnte eventuell zu Problemen führen.

LG

HeikoGr

#294
Zitat von: galileo am 17 Dezember 2019, 10:40:58
Für ttyebus auf Raspi 1-3 muss ich momentan warnen, auf Raspbian Buster upzugraden oder es zu verwenden, das könnte eventuell zu Problemen führen.

ttyebus hat bei mir problemlos unter Raspbian Buster funktioniert (Hardware: Raspi 3B+ mit Aufsteckplatine)

HeikoGr

#295
Hier:
https://www.raspberrypi.org/forums/viewtopic.php?t=248772
wird auch über den Interrupt für den UART diskutiert.

Mit Verweis auf die Sourcen:
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2838.dtsi#L712
Wird als zuständiger Interrupt 121 genannt.

Ich kenne mich (leider) zu wenig mit Hardwarenaher Programmierung aus, aber hilft das?

galileo

Hallo HeikoGr
Ich kannte das schon, es hilft leider nicht viel. Es geht hier wahrscheinlich darum, dass die Interrupt Nummern über den Device Tree irgendwie zusammengebaut werden.
Wenn man jetzt das Device ttyAMA0 wegnimmt, dann verschwindet auch diese "errechnete" Interrupt Nummer, die aber offensichtlich nichts mit der Realität zu tun hatte.
Deshalb kann man diese Nummer auch nicht ganz simpel für den ttyebus weiterverwenden, so wie es früher funktioniert hat. Und das ganze "korrekt" über den Device Tree
neu einzubinden übersteigt meine Fähigkeiten bei weitem.

Zitatttyebus hat bei mir problemlos unter Raspbian Buster funktioniert (Hardware: Raspi 3B+ mit Aufsteckplatine)
Das wäre toll wenn das wirklich funktioniert. Könntest du bitte zur Sicherheit noch ein "cat /proc/interrupts" eingeben und schauen, welchen Interrupt der ttyebus bekommen hat?
Sollte eigentlich auf 81 liegen.
Und wie hast du den Fehler bei "sudo make install" wegbekommen? Auch mit modprobe ? Weil wenn das alles klar ist, dann bessere ich das im Repository aus.
LG

erwin

Hallo Galileo,

ich kann bestätigen, das der Adapter mit buster / raspi 3b+  funktioniert!
ein cat /proc/interrupt ergibt: 81:       1221          0          0          0  ARMCTRL-level  89 Edge      ttyebus_irq_handler
Ich hab ihn zwar noch nicht an der Vaillant dran, aber mit einem Netzteil (& 470 Ohm Wid) kann ich senden und das echo sehen (inkl. led's blinken).
Dieselbe SD Karte im RPI-4 geht definitiv nicht, auch probiert mit int 121....
alles mit: Linux MH-RPI-12 4.19.75-v7+ getestet.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

HeikoGr

Kann ich leider nicht unter real Bedingungen machen, da ich die rpi ebus platine weitervererbt habe und auf die esp variante umgestiegen bin  :-[

Was ich machen kann ist evtl. heute abend ttyebus auf meinem derzeit arbeitslosen rpi 3b+ Unter buster zu installieren. Aber ohne Platine am gpio...

so weit ich mich erinnere kam zwar die Fehlermeldung - das Modul wurde dennoch installiert. Kann ich heute abend (evtl.) testen.

integrator

#299
Moin Moin Leute,
ich wollte mich jetzt auch so langsam an meinen eBus wagen und habe vorab eine Frage.
Ich habe hier noch einen Pi 1 Model B und einen Pi 2 Model B Version 1.1 liegen.
Kann man die benutzen oder sollte man sich einen neuen besorgen?
Und welche raspbian Version sollte man nehmen?