eBUS Adapter 5 selber bauen

[GHolli]

Da ich bereits einen eBUS Adapter besitze ("v2", rein elektrisches Interface), würde ich diesen gerne mit der eBUS Adapter 5 Firmware verwenden. Dafür habe ich ein ESP32-C3 DevKit gekauft, geflasht und eBUS RX auf GPIO7 und eBUS TX auf GPIO10 angeschlossen.
Aber irgendwie will das ganze nicht so richtig funktionieren, es scheint den Bus zu blockieren - sind die Signale invertiert? Oder habe ich sonst noch etwas übersehen?

[LeZerb]

Ich versuche scheinbar gerade exakt das gleiche und habe auch das Gefühl, dass Tx und Rx möglicherweise invertiert sind. Bist du da weiter gekommen?

Hier ist meine Anfrage zu dem Thema. ebusd-esp32/issues/49

[LeZerb]

Hier nochmal ein kurzes Update. Es funktioniert leidig mit einem Inverter (sowohl RX als auch TX) zwischen ESP32C3 und dem Adapter v2. Ich suche noch nach einer Möglichkeit die UART invertiert zu betreiben. Das ist mir aber noch nicht gelungen. Aktuell wird in der Adapter v5 firmware die UART invertiert initialisiert. Theoretisch müsste man nur im UART register 0x60000020 des ESP32C3 zwei bits umsetzen. Schön wäre es wenn die firmware es erlauben würde die UART Initialisierung zu modifizieren.

[LeZerb]

Ich habe es jetzt zum laufen bekommen.

Ich habe dafür die Firmware so gepatcht, dass beim Aufruf von uart_ll_inverse_signal die Signale nicht mehr invertiert werden.

Außerdem habe ich den DC-DC Wandler entfernt und versorge jetzt die isolierte eBus Seite direkt aus dem Bus. Die letzten Probleme in der Kommunikation waren bei mir noch dadurch verursacht, dass ich nach dem Entfernen des Wandlers C3 bestückt gelassen habe. Der hat das Signal wohl doch ein wenig zu rund geschliffen. Nach dem Entfernen von C3 läuft jetzt alles stabil.

Das ESPC3 Board, dass ich verwendet habe ist ein ESP32_C3 Super Mini. Ich Stecke das jetzt einfach auf den Pin Header des v2 Adapters. Dabei werden die Pins 3.3V, IO4, IO3 und IO2 direkt kontaktiert. Das ist ein wenig gefährlich, da man in dieser Installation immer sicher gehen muss, dass die Pins auf Input stehen. IO2 ist außerdem ein Strap Pin des ESPC3 der auf dem Super Mini Board mit 10k gegen 3.3V gezogen ist. Da der v2 Adapter dort aber GND hat habe ich das GND Pin des Super Mini mit IO2 verbunden. Das führt also dazu, dass über den pull-up jetzt immer etwas Strom fließt (man könnte aber auch den Pull-Up entfernen). Zusätzlich ist der Strap Pin IO2 damit jetzt immer low. Das ist aber laut der ESPC3 Dokumentation in diesem Fall kein Problem, da IO8 auf high gezogen ist.

Schließlich musste ich noch IO4 mit IO7 (die ESP32 Firmware erwartet hier eBus Rx) verbinden und IO3 mit IO10 (das ist der eBus Tx Pin der Firmware).

[GHolli]

Vielen Dank @LeZerb, die erforderlichen Verbindungen mit GPIO 3/4 sind nicht so einfach zu erkennen.
Ich habe das ganze nun mit der Originalfirmware und Invertern getestet. Das Bus-Signal wird nun einwandfrei erkannt. Leider hatte ich wenig Zeit und konnte das Senden nicht testen, sieht aber dank deiner Tipps vielversprechend aus!
Mein Testaufbau:

Schaltplan:

[LeZerb]

Hallo.

Ich glaube das war das mit GPIO 3 und 4 war ein Missverständnis.
Das wird nicht benötigt wenn es "extern" verkabelt ist. Diese Verbindungen brauche ich nur weil in der Firmware fest GPIO 7 und 10 verwendet werden und ich das SuperMini Board aber direkt auf JP1 (Pins 1-4, Pin 5 (Raspi 5V) ist nicht verbunden) aufstecken wollte.

Damit ist dann 3.3 V, Tx, Rx, und auch GND automatisch auf das SuperMini Board verbunden. Allerdings Tx und Rx dann eben nicht an die richtigen GPIOs (7, 10) sondern an 3 und 4. Daher das blaue und das gelbe Kabel. GND liegt dann in diesem Setup am SuperMini GPIO 2. Das ist dann über das schwarze Kabel zu SuperMini GND geführt, dass sonst in der Luft hängt.

[LeZerb]

Ich habe meine gepatchte Version (basierend auf 20240330) mal unter 20240330.bin abgelegt. Damit wären die Inverter nicht nötig. Das Image muss an Adresse 0x10000 des ESP C3.
Allerdings gibt es zwei Firmware Slots. Wenn schonmal ein Firmwareupdate über die Weboberfläche gemacht wurde wäre es möglich, dass der andere Slot aktiv ist. Wo genau der liegt weiß ich jetzt nicht mehr genau. Man kann aber herausfinden welcher Slot verwendet wird wenn man sich am ESP-C3 seriell verbindet und über die Weboberfläche ein Reboot ausführt. Der Bootloader des ESP schreibt das dann aus.

Die original Images sind übrigens unter 20240330.json / 20240330.bin zu finden.

[LeZerb]

Nur der Vollständigkeit halber. Der zweite Firmware Slot ist bei 0x210000. Im folgenden log ist dort kein Firmware Image vorhanden und es wird von Slot 0 (0x10000) geladen.

ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0xc (RTC_SW_CPU_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403806b4
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0x1188
load:0x403cc710,len:0x8bc
load:0x403ce710,len:0x2b98
entry 0x403cc710
E (24) esp_image: image at 0x210000 has invalid magic byte (nothing flashed here?)
E (24) boot: OTA app partition slot 1 is not bootable
server started

Außerdem habe ich auch die gepatchte Firmware nochmal aktualisiert (20240420.bin)

[GHolli]

Vielen Dank für die detaillierte Beschreibung und die gepatchte Firmware!
Werde ich bei der nächsten Gelegenheit testen!