Kommunikationsbus zwischen Basisgerät und Erweiterungen?

[TheDarkRose]

Derzeit entwickle ich ein kleines Steuergerät, welche gewisse Regelaufgaben im Haus übernimmt. Um etwas universeller zu sein, soll die Möglichkeit vorgesehen werden, Erweiterungen (z.B.: PLC oder CAN Gateway) anzuschließen. Jetzt stellt sich mir die Frage, welchen Bus ich zur Kommunikation zwischen den Einheiten verwenden soll. Hardwaremäßig soll alles in Hutschienengehäuse, und soll so wie eine Siemens Logo zusammengestöpselt werden.

Zuerst dachte ich ja an RS485, da dieser ja genug Knoten vertragt, würde aber wiederum extra Hardware benötigen. Nun TTL-UART wäre vielleicht eine Option? Wobei ich mich frage, wie weit man diesen über mehrere Platinen führen kann? Hat sonst noch jemand Ideen?

[indeas]

Wie wäre es mit einer Leitung, die mit Pull-Up and Vcc (12V oder 5V - egal) hängt. Mit einem open-collector (1 Transistor) kann die Leitung von jedem Teilnehmer als TX Kanal verwendet werden.
Über und einen einfachen Spannungsteiler (2 Widerstände bei 12V) oder einen Schutzwiderstand (bei 5V) können alle mithören (RX).
Wenn Du den Pull-Up recht klein machst, kannst Du hohe Übertragungsraten und lange Strecken realisieren. Nach diesem Prinzip funktionierte die gute alte K-Leitung (Diagnose) im KFZ.

[TheDarkRose]

Ist das schon zuverlässig?

[indeas]

Entsprechende Mechanismen zur Fehlervermeidung bzw. Fehlerbehandlung vorausgesetzt ist das sehr sicher und auch sehr zuverlässig.
Hardware: Spannungs und Strombegrenzende Maßnahmen (Schutzwidertände) spendieren.
Software: Datenprotokoll mit entsprechender Struktur (Master- Slave) und CRC implementieren.
Was genau (Datenmenge, Anzahl der Teilnehmer, Leitungslängen, Struktur, Reaktionszeiten usw.) möchtest Du übermitteln?

[TheDarkRose]

Gut, alles was sich in Software realisieren lässt, ist zwar Aufwand, hält aber die Gerätekosten gering.

Von der Datenmenge kann da je nach Anzahl der gedachten Erweiterungen, schon was zusammenkommen, da die Steuerung zyklisch abläuft und somit vor Zyklusbeginn alle Eingänge einliest, Nachrichten verarbeitet. Nach Zyklusende sollen alle Ausgänge gesetzt werden und Nachrichten gesendet. Hat ein bisschen SPS Stil dabei, ist aber die einfachere Möglichkeit, eine programmierbare Regelung zu ermöglichen. Denke bei max 10 Teilnehmern ist es eh schon sehr viel, wobei man technisch mehr vorsehen sollte. Dabei kann dann schon ne Gesamtlänge von 1-2 Meter entstehen. Bzgl Reaktionszeiten: so 50-100 ms wären schon super

[indeas]

Na das ist ja überschaubar. Übertragungsraten von 56k sollten ohne Probleme sein.
Die Daten würde ich als ASCII (erlaubte Zeichen 0..9, A..F), dazu Steuerzeichen: (* als Start, <CR> als Ende) Telegrammaufbau: *, Adresse (0...F), Dateninhalt x x x x x x x x x (y y y y) <CR>.
Slave antwortet mit # als Start, Adresse, Dateninhalt und CRC.
Jetzt kannst Du Dir überlegen wie es dauert bis ein Zeichen übertragen wird, wie lange Deine Telegramme sind und wieviele gesendet werden, Dann hast Du auch schon die Zykluszeit (für die Kommunikation).

[TheDarkRose]

Ok, danke schon mal für die Infos. Hardware-technisch wäre dies ja ein invertierter UART durch den Open-Kollektor Aufbau?

[indeas]

Ja der Open Collector invertiert. Wenn Du die Auswertung ebenso mit einem Open-Collector machst, dann passt es wieder.
Der Vorteil: Du hast eine recht gute Entkopplung gegen zu hohe Spannungen im Fehlerfall: Bei einem "Einschlag" zerlegt es erstmal die Transistoren...

[TheDarkRose]

Wie sieht es mit der Zuverlässigkeit bei Binärübertragung aus? Wäre ein guter Punkt, wenn sich die Controller der Erweiterungen über den Bus ebenso updaten lassen.

[indeas]

Das Thema Zuverlässigkeit hatten wir schon. Die ganze Elektronikwelt ist weitgehend digital also Binär und funktioniert eigentlich recht gut.
Zum Update über diese Schnittstelle benötigst Du halt einen µC der sich selber programmieren kann und einen passenden Bootloader.
Dazu eine noch Strategie wie der µC von der normalen Betriebsart in den update-modus geht.