eBus Adapter Version 2.0 / 2.1 / 2.2

Begonnen von chons, 26 August 2017, 23:37:34

Vorheriges Thema - Nächstes Thema

chons

Danke Galileo,
die sockellose Variante macht für mich Sinn (Lotto spielen ist sicherer  ;)) günstig und bringt der Erweiterungsplatine Vorteile durch die geringen Maße (Höhe) ;)

Thema: RPI Platine " ;) gute Idee" - diskutiert das ruhig und wenn genug Interessenten da sind, dann baue ich die aktuelle Platine um - es wird dann aber zwei Platinen geben - probiere das mal mit dem Modul aus (das wird sicher funktionieren)  ;) *ich pers. habe keinen RPI im Einsatz zumindest nicht produktiv... (heißt nix! Keine Vorurteile...)

Sorry ich bin für die nächsten Tage kurz Angebunden - dieses Therad soll dazu dienen sich auszutauschen - macht das... Danke...

john30

Zitat von: galileo am 29 August 2017, 11:12:23
Der USB-to-UART Adapter verwendet einen ,,anderen" UART-Typ und deswegen funktioniert es. Es gibt allerdings auch SPI-to-UART und I2C-to-UART Adapter.

Frage an john30: Was würde das für das Programm bedeuten? Ich bin mir ziemlich sicher dass es einen Linux-Treiber dafür gibt, aber lässt sich das einfach einbinden?
Hm, solange es ein kernel module gibt, das aus dem I2C Device einen regulären serial device node macht, sollte das kein Problem sein. Sppontan konnte ich aber keins für den chip finden, was aber nichts heißt.
author of ebusd

galileo

Ich werde mir einmal so ein SPI-UART Modul besorgen. Das dauert sicher und zum Ausprobieren muss ich dann aber auf den Print von chons warten weil ich aktuell keinen mehr besitze.
Da meine Linux Kenntnisse nur rudimentär sind werde ich zum Einbinden vermutlich Hilfe brauchen, aber schauen wir einmal...

john30

Zitat von: galileo am 30 August 2017, 07:23:26
Ich werde mir einmal so ein SPI-UART Modul besorgen. Das dauert sicher und zum Ausprobieren muss ich dann aber auf den Print von chons warten weil ich aktuell keinen mehr besitze.
Da meine Linux Kenntnisse nur rudimentär sind werde ich zum Einbinden vermutlich Hilfe brauchen, aber schauen wir einmal...
super, dann schauen wir mal.
Was natürlich auch noch gehen sollte, wäre in ebusd low level I2C calls abzusetzen, also einen mini Treiber dafür zu entwickeln.
author of ebusd

andig

Ich hoffe das ist als Halblaie jetzt nicht neben dem Thema, aber sowohl i2c als auch spi als Devices sollte möglich sein: https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=15511

galileo

ZitatWas natürlich auch noch gehen sollte, wäre in ebusd low level I2C calls abzusetzen, also einen mini Treiber dafür zu entwickeln.

Ich habe mir das Datenblatt vom SC16IS750 angesehen, welcher auf diesem Breakout Board verbaut ist. Der hat jedenfalls dem Modus "FIFO off", wodurch der Interrupt sofort beim ersten empfangenen Byte ausgelöst wird. Damit ist zu hoffen dass ein eventuell vorhandener LINUX Treiber mit VMIN=1 und VTIME=0 korrekt reagiert und die Latenz damit minimal wird. Wenn das nicht der Fall ist oder es keinen fertigen Treiber gibt ist ein Treiber auf I2C oder SPI (SPI ist schneller als I2C!) Basis schon verlockend.

Zitat...aber sowohl i2c als auch spi als Devices sollte möglich sein: https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=15511
Mir scheint das ein Treiber für I2C/SPI low level zu sein, wie von john30 vorgeschlagen. Damit bekommen wir aber noch kein UART device. Wenn man nach "sc16is750 linux driver" googelt bekommt man ein paar gut aussehende Hinweise, aber auf dieser Ebene tue ich mir schon sehr schwer... Aber jedenfalls dürfte so ein Treiber existierten.

galileo

Also wenn es wahr ist was ich herausgefunden habe (theoretisch - ausprobiert habe ich das nicht!):

Der sc16is750 ist ein SINGLE I2C/SPI to UART Controller.
Nicht zu verwechseln mit dem sc16is752, das ist ein DUAL I2C/SPI UART Controller.

Für beide Controller gibt es im Raspbian Unterstützung. Für den 750 aber nur im I2C Modus, für den 752 nur im SPI Modus (warum?).
Damit der Treiber für den sc16is750 geladen wird, muss man in /boot/config.txt den Eintrag

dtoverlay=sc16is750-i2c,int_pin=24,addr=48

einfügen. Tatsächlich finden sich unter /boot/overlays die beiden Files sc16is750-i2c.dtbo und sc16is752-spi1.dtbo.

Man erhält dann Zugriff über das Device /dev/ttySC0

andig


john30

Zitat von: galileo am 30 August 2017, 17:41:03
Man erhält dann Zugriff über das Device /dev/ttySC0
das klingt perfekt, keine zusätzliche Arbeit für mich :-)
author of ebusd

Reinhart

Zitat von: galileo am 30 August 2017, 17:41:03
Tatsächlich finden sich unter /boot/overlays die beiden Files sc16is750-i2c.dtbo und sc16is752-spi1.dtbo.

kann ich bestätigen, ist auch im Stretch so!

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

chons

Eine Frage in die Runde: Reicht die Spannungsversorgung des 78L05 aus, um den Wemos D1 mini zu versorgen? Oder könnte man evtl. auf den 7805 wechseln (der kann 1 oder 1,5 A) und was würde das für die aktuelle Schaltung bedeuten (müssen evtl. andere Bauteileteile darauf angepasst werden?) und kommt dann EBUS damit zurecht?

Reinhart

#26
Hallo chons!

laut eBus Spezifikation dürfen einzelne Geräte am Bus maximal 18 mA entnehmen.

Der kritische Punkt liegt in meinen Augen, dass bei Sendebetrieb ja über die Zenerdiode ein Spannungseinbruch (ein fast Kurzschluß) produziert wird. Das bedeutet, das die interne Versorgung des eBus von der Therme über einen Shunt erfolgen muss und daher darf die Stromentnahme nicht beliebig sein, sonst glaubt die interne Schaltung es handelt sich um einen Sendeversuch eines Slaves.

Wieviel der Wemos Mini beim senden verbratet, müsste man ausmessen, aber bei den 3 Leds auf der Basisplatine geht auch schon ein Teil der angebotenen 18 mA verloren. So gesehen reichen die 100mA des 78L05 allemal, weil man das gar nicht ausreizen darf.

So meine Meinung, aber wenn es jemand genauer weiß, dann bitte posten.

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

galileo

Hallo chons!

Ich hab da offensichtlich irgendwas verschlafen, denn ich habe keine Ahnung wie der Wemos Mini verwendet wird oder wozu er genau dient.

Aber ist es nicht jedenfalls so, dass er (vom eBus aus gesehen) HINTER den Optokopplern zum Einsatz kommt?
Dann darf er sowieso nicht vom 78L05 versorgt werden, sonst ist ja die ganze schöne galvanische Trennung dahin...
Aber wenn ich da ganz falsch liege, klär mich bitte auf  ;D

LG

Reinhart

da hast du vollkommen recht, auch die galvanische Trennung wäre dahin, obwohl die mehr oder weniger egal ist weil sie auf keinem anderen Potential terminiert.

Der Wemos Mini sitzt anstatt eines UART und ist für chon seine Erweiterungsplatine für den WLAN Betrieb gedacht.

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

Reinhart

ich habe nun wegen dem Wemos etwas gegoogelt, da sind Aussagen wie 180-200mA wenn er sendet und das wäre ohnehin das zehnfache des erlaubten! Also bleibt chons eigentlich nur der Weg über eigene Versorgung, bzw. eine andere Nieder Spannung an der Therme abgreifen, aber das haben dann vermutlich nicht alle Geräte zur Verfügung.

Ich werde das die Tage einmal genau nachmessen, weil das kommt mir schon etwas hoch vor. Der Spannungspegel würde ja passen, weil der Wemos an den seriellen Anschlüssen laut Schaltung nicht mehr als 3,3 V bekommt, das wäre sonst ein ko Kriterium.

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