Forum: Mikrocontroller und Digitale Elektronik Sternförmiges BUS-System


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Timo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo miteinander,

ich bin gerade auf der Suche nach einen Bussystem das auch Sternförmig 
betrieben werden kann.

Folgendes habe ich vor:
Als "Server" will ich einen RaspberryPi (oder etwas ähnliches) nutzen. 
Dieser kommt auf eine hübsche Platine an die mehrere 
Sensor/Aktor-Platinen über RJ45 Buchsen angeschlossen werden können. Die 
Kabellänge vom Raspi zu den einzelnen Platinen beträgt zwischen 1 und 25 
Metern. Über das gleiche Kabel sollen die "Sub-Platinen" auch mit 
Energie (12V & 5V) versorgt werden.

Die einzelnen Sub-Platinen müssen nicht untereinander kommunizieren 
können - das soll dann alles über den Raspi gehen. Allerdings sollten 
die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort 
Daten an den Server schicken können.

Bei CAN oder RS485 ist Sternförmig ja (so wie ich bisher gelesen habe) 
nicht möglich. Was gibts da sonst noch? Ethernet wäre ne Möglichkeit - 
frisst mir aber zu viel Strom.
Das ganze sollte mit möglichst wenig Komponenten machbar sein.

Danke! :)

von Klaus R. (klara)


Bewertung
0 lesenswert
nicht lesenswert
1wire

von rmu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mehrere transceiver-ICs?

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Bei CAN oder RS485 ist Sternförmig ja (so wie ich bisher gelesen habe)
> nicht möglich.

Könnte man aber mit Hin- und Rückleitung aufzwirbeln. Braucht dann halt 
mehr Adern - und hat die Verfügbareit von Thinwire Ethernet, d.h. die 
erste kaputte Buchse stört den Bus.

Timo schrieb:
> Das ganze sollte mit möglichst wenig Komponenten machbar sein.

USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485 
Treiber anschließt.

Vorteil: Viele Busse, Störungen bleiben auf einzelnen Bus begrenzt,
sendende Ereignisse erzeugen weniger Kollisionen.

von Stefan K. (stefan64)


Bewertung
2 lesenswert
nicht lesenswert
CAN funktioniert bei niedrigen Baudraten auch sternförmig. Dazu gab es 
hier mal einen Link zu "CAN in Automation", dort stand eine Tabelle mit 
den maximal möglichen Stichleitungslängen in Abhängigkeit von der 
Baudrate. Leider ist der Link mittlerweile tot (hat jemand noch diese 
Tabelle offline gespeichert?). Die Werte bei 20kbaud habe ich aber noch 
in einem alten Thread gefunden:

> Bei 20kbit/s darf z.B. eine Stichleitung nicht länger als 137m sein,
> alle Stichleitungen zusammen dürfen nicht länger als 687m sein.
> Natürlich sind diese Angaben abhängig von den verwendeten Treibern. Die
> Tendenz ist aber klar: je niedriger die Baudraten desto weniger Probleme
> bekommst Du mit Stichleitungen. Analog trifft das auch auf RS485 zu.

Ich persönlich verwende in meinem CAN-Hausbus eine sternförmige 
Verkabelung (geschätzte 600m verteilt auf ca. 15 Stichleitungen) ohne 
Probleme.

Übrigens sind die meisten anderen Bussysteme nur deshalb unkritischer, 
weil sie von Haus aus für eine niedrigere Übertragungsrate spezifiziert 
sind.

Viele Grüße, Stefan

von Timo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
rmu schrieb:
> mehrere transceiver-ICs?

Darüber hatte ich auch schon nachgedacht. Allerdings wäre ich dann ja 
bei der Anzahl der Teilnehmer auf die Anzahl der Transceiver beschränkt. 
Sollte also irgendwann mal noch ein Platinchen hinzukommen siehts 
schlecht auch.

Jim M. schrieb:
> Könnte man aber mit Hin- und Rückleitung aufzwirbeln. Braucht dann halt
> mehr Adern - und hat die Verfügbareit von Thinwire Ethernet, d.h. die
> erste kaputte Buchse stört den Bus.

Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf 
einer Platine/Leitung keine Auswirkungen auf das restliche System hat.

Jim M. schrieb:
> USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485
> Treiber anschließt.

Auch das möchte ich nicht unbedingt. Ich will den Raspi "kopfüber" auf 
die Platine stecken und alles über die GPIO Pins abgreifen.

Stefan K. schrieb:
> Leider ist der Link mittlerweile tot (hat jemand noch diese
> Tabelle offline gespeichert?).

Habe gerade mal ein bisschen gegoogelt... Meinst du das hier?
https://www.can-cia.org/de/can-knowledge/canopen/canopen-lower-layers/

Hmm... Ich denke ich werd das ganze mit CAN versuchen. Laut der Seite 
müssen die einzelnen Stichleitungen nicht terminiert werden?
> "and the maximum unterminated cable drop lengths"
Wo muss ich dann terminieren?
Direkt am Transceiver und dann nochmal nach den RJ45-Buchsen?

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Habe gerade mal ein bisschen gegoogelt... Meinst du das hier?
> https://www.can-cia.org/de/can-knowledge/canopen/canopen-lower-layers/

Exakt. danke fürs Raussuchen ;-)

> Hmm... Ich denke ich werd das ganze mit CAN versuchen. Laut der Seite
> müssen die einzelnen Stichleitungen nicht terminiert werden?

Ja. Es gibt die Methode der Zentralterminierung. Dabei wird im 
Sternpunkt ein einzelner Terminierungs-R eingesetzt, der den normalen 2 
* R parallelgeschaltet entspricht, also 60Ohm.

Wenn ich mich recht erinnere, habe ich bei mir an 2 Stichleitungen die 
"normalen" Terminierungs-R eingesetzt.

Willst Du die 5V direkt für die Versorgung der dezentralen Elektroniken 
verwenden? Das halte ich für störanfällig - besser ist die dezentrale 
Erzeugung der VCC aus den 12V.

Viele Grüße, Stefan

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf
>einer Platine/Leitung keine Auswirkungen auf das restliche System hat.

Dann bleibt dir doch nur noch Ethernet.

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Das möchte ich vermeiden. Ich möchte sogar noch das ein Kurzschluss auf
> einer Platine/Leitung keine Auswirkungen auf das restliche System hat.

Dann ist das aber nicht die Lösung...

Timo schrieb:
> Hmm... Ich denke ich werd das ganze mit CAN versuchen.

...denn ein Kurzschluß oder eine Fehlfunktion bei einem der Teilnehmer 
legt den Bus lahm.

Wirklich robust gegen Störungen ist in der Tat:

holger schrieb:
> Dann bleibt dir doch nur noch Ethernet.

von Timo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmmmm.... OK, überzeugt^^
Über einen Kurzschluss auf der Bus-Leitung hatte ich garnicht 
nachgedacht. Ich meinte eigentlich einen Kurzschluss der 
Versorgungsspannung - hier sollte nicht das ganze System lahmgelegt 
werden. Aber an die Busleitungen hab ich hierbei nicht gedacht.... Das 
hab ich wohl unglücklich formuliert ;)

Ich denke ich nehme dann doch RS485 und werde dann wohl doch für jeden 
Teilnehmer einen eigenen Transceiver verwenden und auf der Platine 
einfach etwas Platz für weitere Transceiver vorsehen.

Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom 
Raspi hängen? Also... Ungefähr so:
1
Raspi                   Transceiver 1
2
+------+               +-------------+
3
|   RX | ---+--|>|---- | TX          |
4
|   TX | -+-|--------- | RX          |
5
+------+  | |          +-------------+
6
          | |
7
          | |           Transceiver 2
8
          | |          +-------------+
9
          | +----|>|-- | TX          |
10
          +-|--------- | RX          |
11
          | |          +-------------+
12
          .....

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom
> Raspi hängen?

Nein, nicht ohne weiteres. TxData köntest du zwar ev. parallel an alle 
senden, das kommt auf das Protokoll an ob das geht (Adressierung). Die 
RxData kannst du aber nicht miteinander verbinden. Wenn du aber sowieso 
eine Platine machst, kannst du die Transceiver einzeln mit je einem 
Enablesignal schalten, oder, wenn sie keines haben, über abschaltbare 
Treiber anbinden. Mehrere empfangsbereite Uarts brauchst du allerdings, 
wenn sich die Slaves spontan melden sollen, denn dann weisst du ja nicht 
wann was über RxData reinkommt.

Ich verwende in solchen Fällen ein Protokoll mit Slaveadresse und frage 
die Slaves ständig reihum ab. Nicht vergessen: auch Slaves abfragen, die 
nicht online sind, sie können ja online werden, und ebenso können Slaves 
sich verabschieden, das muss alles im Protokoll geregelt sein!

Georg

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom
> Raspi hängen?

Nicht direkt, aber über ein AND-Gatter mit einem Eingang pro Tranceiver. 
So ein Monster-Gatter kann man natürlich aus mehreren normal kleinen 
zusammensetzen. Multi-Master geht damit schlecht, aber mit einem echten 
RS-485-Bus geht's auch nicht einfacher.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> wenn sich die Slaves spontan melden sollen,

Was bei RS485 sowieso nicht wirklich angenehm ist. Der Zirkus, den man 
sich mit Arbitrierung einhandelt, denn muss man erst einmal zuverlässig 
in den Griff kriegen.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Kann ich denn mehrere RS485 Transceiver einfach parallel an den UART vom
> Raspi hängen? Also... Ungefähr so:

Im Prinzip schon - wenn man immer nur einen Transceiver aktiviert. Da 
aktive Transmitter Strom fressen, und das nicht zu knapp, wär das 
vielleicht ohnehin sinnvoller. Viele Transceiver-Bausteine haben 
entsprechende Rx/Tx-Enables.

Einen einzelnen Master alle infragekommenden Slaves reihum abklappern zu 
lassen ist jedenfalls deutlich einfacher, als zu versuchen, von der 
grünen Wiese weg einen Multimaster-RS485 in Sterntopologie einzurichten.

: Bearbeitet durch User
von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Mit dem LIN-Bus lässt sich sowas realisieren, allerdings muss der Master 
die Slaves pollen, weil die sich nicht selbständig melden dürfen. LIN 
ist grob gesagt so eine Mischung von UART und I2C.
Max. Kabellänge bei 19.2kbps sind 40 Meter.

: Bearbeitet durch User
von Meister E. (edson)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Timo schrieb:
>> Das ganze sollte mit möglichst wenig Komponenten machbar sein.
>
> USB Hub und ein paar FT4232H 4x-UART Module, die man an RS422 oder RS485
> Treiber anschließt.
>
> Vorteil: Viele Busse, Störungen bleiben auf einzelnen Bus begrenzt,
> sendende Ereignisse erzeugen weniger Kollisionen.

Das war auch mein erster Gedanke. Wenn der zentrale Knoten der Master 
sein soll und Teilnehmer nicht direkt miteinander kommunizieren braucht 
man im Prinzip gar keinen Bus. Es reicht, wenn der Master soviele 
Peer-to-Peer Verbindungen ermöglicht wie man Teilnehmer hat.
Dein Ansatz mit USB-Hub und seriellen Wandlern ist komfortabel und 
einfach erweiterbar. Ich würds so machen, zumal:

A. K. schrieb:
> Einen einzelnen Master alle infragekommenden Slaves reihum abklappern zu
> lassen ist jedenfalls deutlich einfacher, als zu versuchen, von der
> grünen Wiese weg einen Multimaster-RS485 in Sterntopologie einzurichten.

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
Timo schrieb:
> Allerdings sollten
> die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort
> Daten an den Server schicken können.

Das bedeutet Multi-Master. Und das ist mit CAN wesentlich einfacher zu 
realisieren als mit RS485.

Selbst wenn Du nur 2 Geräte am RS485 hast (Raspi und Transceiver) hast 
Du ein Master/Slave System. Der Transceiver darf (eigendlich) nicht 
selbstständig Daten an den Master schicken, weil dieser zur selben Zeit 
den Slave ansprechen könnte.

Gruß, Stefan

von rmu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich würd

* RS485 nehmen, mehrere Transceiver ICs verwenden, ein UART
* Transmit Enable "zu fuss" über IOs, ein Schieberegister oder einen 
Demux ansteuern
* Telegramme mit definierter Maximallänge verschicken
* Slaves haben eine "Adresse"
* Master pollt Slaves
* jeder Slave schickt immer genau eine (oder evt. keine bei Broadcasts) 
Antwort

natürlich brauchts da noch einiges an Software, z.B. muss der Master 
herausfinden können, welcher Slave an welchem Transceiver hängt etc...

Um out of band reagieren zu können brauchts eine eigene 
"Interrupt"-Leitung, die dann einen Reihum-Poll auslöst. Evt. als RS422 
Differenzsignal übertragen.

Vielleicht ist CAN doch einfacher ;)

von Baendiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan K. schrieb:
> Das bedeutet Multi-Master. Und das ist mit CAN wesentlich einfacher zu
> realisieren als mit RS485.
> Selbst wenn Du nur 2 Geräte am RS485 hast (Raspi und Transceiver) hast
> Du ein Master/Slave System. Der Transceiver darf (eigendlich) nicht
> selbstständig Daten an den Master schicken, weil dieser zur selben Zeit
> den Slave ansprechen könnte.

Bei einem Stern mit vielen Transceivern kann man dann auch RS422 mit 4 
Adern also Vollduplex benutzen.

von Matthias K. (mkeller)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Kurzschlüsse oder Kabelbrüche nur auf den jeweiligen Teilnehmer 
beschränkt sein soll, könntest du auch CAN und mehrere AMIS-42770 
Bausteine nehmen. Du musst aber dabei auf das Delay der AMIS-42770 
Bausteine achten, denn das verringert deine maximale Buslänge. Durch CAN 
hast du ohne Softwareentwicklung ein Multimaster bzw. ein master-loses / 
dezentrales System.

Ansonsten: Ethernet. Beim Stromverbrauch kenne ich mich leider zu wenig 
aus.

Andere Idee: Alle Sensoren und Aktoren mit einer eigenen I2C 
Schnittstelle bedienen. Da sollten 25m auch kein Problem sein, sofern du 
keine stark gestörte Umgebung hast.

Der ATxmega64 hat schonmal 4x I2C. Oder du nimmst ein PCA9518 also ein 
I2C Hub

: Bearbeitet durch User
von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Man nehme pro Client einen RS-422-Tranceiver, 4 Datenadern und ein UART. 
Wenn der Pi zuwenig UARTs hat, kann man einen uC mit z.B 6 UARTs davor 
schalten. Wenn das nicht reicht, kann man mehrere uC kaskadieren. Damit 
dürfen Master und alle Clients jederzeit senden und das "Protokoll" legt 
nur den Datenrahmen fest.

Die Stromversorgung der Clients kann zentral über je einen High Side 
Switch erfolgen, der den Kurzschluss-Strom begrenzt. Je nachdem wie 
viele Client-Kurzschlüsse man gleichzeitig erlauben will, muss das 
zentrale Netzteil evt. etwas kräftiger sein (aber s.u). Die 3.3V/5V 
werden sowieso Client-seitig geregelt.

Bleibt noch, die RS-422-Pins des Masters (und evt. der Clients) gegen 
direkte Kurzschlüsse gegen die Betriebsspannung zu schützen. 12 Volt 
vertragen die meisten Tranceiver, von TI gibt es auch welche, die 48 
Volt vertragen. Man kann die Pins auch mit relativ kleinen TVS schützen, 
wenn der Master die Client-Versorgung überwacht und rechtzeitig 
abschaltet.

Diese Konfiguration ist nicht nur fehlertolerant sondern auch beliebig 
schnell bzw. nur von der Rechenleistung des Masters begrenzt. Man kann 
die Punkt-zu-Punkt Datenleitungen ja beliebig terminieren, von garnicht 
für langsam, kurz und stromsparend bis korrekt an beiden Enden.

Was hab' ich noch vergessen?

von Baendiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
eagle user schrieb:
> Was hab' ich noch vergessen?

Welcher Mikrocontroller hat mehr als 4 UARTs? Ich denke ich wuerde eher 
die Lösung mit einem USB Hub und vielen USB RS422 Wandlern vorschlagen.

von Baendiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt sogar fertige Module:
http://www.mouser.de/Search/m_ProductDetail.aspx?FTDI%2FUSB-COM422-PLUS4%2F&qs=nswjyC6mNJp%252b9v404rWEGg%3D%3D
Ich hab zwar eben nur schnell geguckt aber die RS422 Anschlüsse sollten 
Vollduplex unterstützen.

von Michael K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und wieder wird das Rad erfunden ...

Timo schrieb:
> Allerdings sollten
> die Sub-Platinen bei bestimmten Ereignissen auch von sich aus sofort
> Daten an den Server schicken können.

Nur alleine durch diese Forderung nagelst Du Dich auf eine Punkt zu 
Punkt Verbindung bzw. auf Multimaster Betrieb fest.
Für menschliche Bedienung reichen 300ms zwischen Aktion und Reaktion 
Deines Systems damit man keine Verzögerung spürt.

Reichen würde Dir wahrscheinlich ein adressierter 2Draht Bus wie LIN 
oder DALI um Power + Daten zu übermitteln.

Auch mit RS485 sind beliebig gemischte Bus / Stern Verkabelungen kein 
Problem wenn die Datenrate niedrig genug ist.
Entweder unterminiert oder mit komplexer (RC) Terminierung.
Auf Slave Seite begrenzt man per Hardware die maximale Zeit die ein 
Treiber auf senden stehen kann und verwendet den Watchdog gegen 
Softwarehänger.

Wenn fehlerhafte Slaves so häufg vorkommen das ein Busbetrieb nicht mehr 
möglich ist dann sollte man dringend die Designfehler beheben statt 
Systeme mit Maximalverkabelung zu bauen.

Mit einer 100ms Pollingrate alle Slaves lesen / schreiben reicht für 
eine flüssig bedienbare Sensor / Aktor Installation.
Ab welchem Timing bei Raspi + Linux die 'Echtzeit' Probleme anfangen 
kann ich nicht einschätzen.
Zur Not ein Master am USB Port des Raspi der gegenüber dem Bus das harte 
Timing macht.

von eagle user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Baendiger schrieb:
> eagle user schrieb:
>> Was hab' ich noch vergessen?
>
> Welcher Mikrocontroller hat mehr als 4 UARTs? Ich denke ich wuerde eher
> die Lösung mit einem USB Hub und vielen USB RS422 Wandlern vorschlagen.

Der STM32F091 (LQFP-64) hat 8, ist aber EMV-mäßig eher mäßig, die 
STM32L47x sind besser und haben 6 UARTs. Und das sind nur die, die ich 
für mich ausgesucht habe.

Michael Knoelke schrieb:

> Mit einer 100ms Pollingrate alle Slaves lesen / schreiben reicht für
> eine flüssig bedienbare Sensor / Aktor Installation.

Mit einem echten Stern hast du aber Totzeiten im einstelligen ms Bereich 
und nur soviel Traffic wie wirklich nötig ist; immerhin baust du eine 
ziemlich ausgedehnte Antenne auf.

> Ab welchem Timing bei Raspi + Linux die 'Echtzeit' Probleme anfangen
> kann ich nicht einschätzen.

Ein Standard-Debian-Kernel hat 4ms Zeitscheiben. Die Taskwechselzeiten 
sind kurz verglichen mit der seriellen Übertragung, aber natürlich, die 
Masse macht's. Wir wissen ja nicht, wie schnell Daten von wie vielen 
Clients kommen. Was wirklich bremst, sind Massenspeicher, vor allem 
SD-Karten.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
eagle user schrieb:
> Wir wissen ja nicht, wie schnell Daten von wie vielen
> Clients kommen

Eigentlich schon, jedenfalls nach den ursprünglichen Wünschen des TO: 
wenn die Clients spontan senden können, ist es natürlich möglich, dass 
sämtliche Clients gleichzeitig Daten übertragen, und auf diesen worst 
case muss die Verarbeitung ausgelegt sein. Ich würde in so einem Fall 
für jeden Anschluss einen Slave-Prozessor vorsehen, der eine 
Client-Übertragung selbständig abwickeln und zwischenspeichern kann, 
dann skaliert die Übertragungskapazität mit der Anzahl der Clients.

Zur Sinnhaftigkeit dieser Forderung wurde schon genug gesagt.

Georg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.