mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welches Protokoll kann mehrere Daten-Empfänger haben?


Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Community,

möchte eine Reihe von Sensoren betreiben und deren Werte gleichzeitig 
von mehreren Mikrocontrolern bzw. Raspberry Pi ausgewertet werden. Das 
soll auch weiter funktionieren wenn einer dieser Empfänger abgekoppelt 
wird (also Weiterreichen der Daten geht nicht).

Es braucht also ein Protokoll wo die Sensoren Daten einspeisen können 
und die "Empfänger" alle Daten auch sehen können.

Hätte ich ein Ethernet-Netzwerk könnte man dafür sicherlich z.B. das 
Mosquitto Protokoll verwenden, aber das ist in dem Fall wie Kanonen auf 
Spatzen.
Kann eines der üblichen Hardwareprotokolle wie I2c, Uart oder SPi dazu 
bewegt werden, sich so zu verhalten, indem man auf bidirektionale 
Kommunikation verzichtet?
Eventuell mit CAN (damit hab ich am wenigsten Erfahrung)?

Schon mal viele Dank für Vorschläge!

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das alles drahtgebunden stattfindet, kann man je nach Entfernung 
z.B. UART oder RS485 benutzen, aber es muss sichergestellt werden, das 
es keine Kollisionen gibt, bzw die Sender sich inaktiv (hochohmig) 
schalten, wenn sie fertig mit der Sendung sind.
Zu Vermeidung von Kollisionen muss also der Sender vorher reinhören, ob 
sich gerade kein anderer Sender auf dem Bus befindet und er muss auch 
während der Übertragung prüfen, das kein anderer zufällig gerade 
gleichzeitig mit ihm angefangen hat - da würde nur Müll rauskommen. Es 
wäre evtl. sogar sinnvoll, wenn ein wenig Zufall mit reinspielt. Also 
das z.B. nicht alle Sender das gleiche Intervall nach einer Sendung 
eines anderen benutzen, um selber loszutröten.

Autor: dunno.. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein bussystem wäre schon sinnvoll. Can ist genau so konzipiert und 
gedacht.

Spi und i2c könnte man auch hinbiegen, wenn es nen master geben soll..

Einfacher für dich und billiger wird aber mqtt auf fertigen controllern, 
da du sonst ja keine anforderungen nennst..

Autor: Base64 U. (6964fcd710b8d77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
von was hängst du am ehersten ab?

begrenzten Ressourcen am µC oder Kabel zur verbindung? Ethernet würde 
sich ja schon mal ganz gut an bieten für osi 1+2

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Oh, noch was: CAN hat einen Grossteil der o.a. Anforderungen in Hardware 
gegossen, ist aber nicht unbedingt das einfachste Bussystem. Allerdings 
robust und mit vielen Features. Empfänger kannst du immer so viele 
haben, wie du willst, die Sender müssen sich abstimmen.

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> indem man auf bidirektionale
> Kommunikation verzichtet?

Davon ist dringend abzuraten denn dann gibt es keine Bestätigungen, und 
folglich keine Kenntnis darüber ob überhaupt irgendetwas irgendwo 
angekommen ist.

Georg

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das hängt auch stark von der Bedeutung der Daten für Dich oder die 
Funktion der Geschichte ab.
Hier laufen seit einigen Jahren mehrere temperatur/Feuchtesensoren in 
den Zimmern. Übertragung mit RFM02 auf 433MHz.
Die Sensoren senden alle 2 Minuten von einem freilaufenden Timer 
gesteuert. Damit gibt es merkliche Toleranzen der 2 Minuten, die hier 
aber von Vorteil sind: es stören sich nicht dauerhaft Sensoren weil sie 
zur gleichen Zeit senden.

Ganz praktisch: die Daten als solche in diesem Abstand sind unwichtig 
für mich, es dürfen also Pakete ausfallen. Am Tag kommen von den rund 
700 Sendungen ca. 1% nicht an, also 5-7 fehlen, maximal 2 
hintereinander.
Habe ich nur am Anfang kontrolliert.
Prinzipeöö kann man das auch über UART oder SPI schicken wenn man nur 
Sensor TX und Empfänger RX benutzt. Mehrere RX an einem TX ist kein 
Problem, es ist eben auch Fire-and-Forget. Der Sensor sendet seine 
Dazen, ob die Ankommen ist ihm egal. Nachteil bei diesen Kabellösungen: 
man muß Leitungslängen und Treberleistungen beachten und ein 
ausgefallenes Gerät legt u.U. das ganze System lahm wenn er die Leitung 
"festhält".
Aktuelle Sachen bei mir WLAN mit ESP8266 und MQTT, Mosquitto läuft auf 
einem RasPi. Meine Liste sagt, es sind im Moment 13 aktive ESP8266 in 
meinem WLAN, dazu noch ein Sensor und 3 PIR-Sensoren, die sich nur 
anmelden wenn sie was loswerden wollen.

Es hängt meiner Meinung nach also hauptsächlich von der Anwendung ab, 
wie zuverlässig es real sein muß, wieviel Aufwand für Kabel und Hardware 
man reinstecken will oder muß.

Meine Versionen decken meine EInzelanwendung komplett und sicher ab, das 
muß nicht bei Dir zutreffen.
FrontEnd ist FHEM, läuft auch auf dem RasPi.

Gruß aus Berlin
Michael

Autor: H.Joachim S. (crazyhorse)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Matthias S. schrieb:
> ist aber nicht unbedingt das einfachste Bussystem

Eigentlich schon. Ok, man sollte CAN-Hardware verwenden und nicht 
versuchen, dass in Software nachzubilden. Ansonsten ist das doch sehr 
einfach zu handhaben.

Autor: Wolfgang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
georg schrieb:
> Davon ist dringend abzuraten denn dann gibt es keine Bestätigungen, und
> folglich keine Kenntnis darüber ob überhaupt irgendetwas irgendwo
> angekommen ist.

Dann muss sich eben jeder Empfänger an seinen zehn Fingern abzählen, ob 
er alles mitbekommen hat. Dafür muss der Sender seine Pakete nur mit 
einer Paketnummer versehen. Ob es auf vollständigen Empfang der 
Messdaten überhaupt ankommt, weiß hier keiner.
FEC hilft, damit der Empfänger keine falschen Daten versteht.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Hilfreichen Antworten!

Wolfgang schrieb:
> Dann muss sich eben jeder Empfänger an seinen zehn Fingern abzählen, ob
> er alles mitbekommen hat. Dafür muss der Sender seine Pakete nur mit
> einer Paketnummer versehen. Ob es auf vollständigen Empfang der
> Messdaten überhaupt ankommt, weiß hier keiner.
> FEC hilft, damit der Empfänger keine falschen Daten versteht.

Richtig, das ist auch der Plan.


Base64 U. schrieb:
> von was hängst du am ehersten ab?
>
> begrenzten Ressourcen am µC oder Kabel zur verbindung? Ethernet würde
> sich ja schon mal ganz gut an bieten für osi 1+2

Eigentlich wollte ich eben das relativ starre und dicke Ethernet-Kabel 
vermeiden, weil manche der Sensoren sehr klein sind und die Abstände zu 
den auswertenden Einheiten, auch nur etwa 50-100cm..
Allerdings fällt mir grad wieder ein dass man über Ethernet ja auch 
Stromversorgung betreiben kann (der allerneuste Raspi unterstützt das 
mit einem Adapter), d.h. ich bräuchte sonst keine Leitungen.
Außerdem dürfte ich bei den Abständen und geringen Datenraten 
wahrscheinlich auf Schirmung verzichten können.


dunno.. schrieb:
> Spi und i2c könnte man auch hinbiegen, wenn es nen master geben soll..
Es soll ja mehrere "Master" geben, wobei die nicht senden müssen.

dunno.. schrieb:
> Einfacher für dich und billiger wird aber mqtt auf fertigen controllern,
> da du sonst ja keine anforderungen nennst..

Was für controler meinst du da genau? mqtt ist soweit ich das kenne, ja 
ein Softwareprotokoll das auf einer, anderweitig bereitgestellten, 
bidirektionalen Datenverbindung basiert.


Matthias S. schrieb:
> Oh, noch was: CAN hat einen Grossteil der o.a. Anforderungen in Hardware
> gegossen, ist aber nicht unbedingt das einfachste Bussystem. Allerdings
> robust und mit vielen Features. Empfänger kannst du immer so viele
> haben, wie du willst, die Sender müssen sich abstimmen.
Das klingt schon mal recht gut.
Mit Abstimmen meinst du auch diese Kollisionserkennung?


Hmm, schätze ich werde wohl beides evaluieren müssen. Fange aber mit dem 
vereinfachten Ethernet an.

: Bearbeitet durch User
Autor: Patrick C. (pcrom)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vielleicht :
- Multi-master i2c
- LIN (bin nicht sicher davon aber bestudiere das mal)

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN ist dafür ideal, weil die Hardware das Protokoll übernimmt, d.h. die 
Software wird besonders einfach.
Es gibt ja auch viele MCs mit CAN intern.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Eigentlich wollte ich eben das relativ starre und dicke
> Ethernet-Kabel vermeiden

Ich glaube du hast die Koaxialen Netzwerkkabel nicht kennen gelernt. 
Oder Token-Ring. Sonst wärst du für den heutigen Stand der Technik 
dankbarer.

Die heute üblichen Netzwerkkabel sind genial praktisch und zuverlässig. 
Das muss man mal sagen.

Ich habe in meiner Wohnung flache weiße Kabel unauffällig an die weißen 
Wände geklebt. Die passen auch ganz locker zwischen Türen und Rahmen 
durch (ohne Bohren). Früher (als ich noch schön war, in den 90er Jahren) 
hätten die Leute für solche Kabel ein Vermögen ausgegeben. Heute bekommt 
man sie für ca 1 € pro Meter.

ich stimme allerdings den Vor-Postern zu, dass für deinen Fall CAN oder 
als billigere Alternative RS485 wahrscheinlich vorteilhafter ist. Dafür 
kannst du die selben Kabel verwenden.

: Bearbeitet durch User
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auch CAN nehmen. Man braucht keinen Master am Bus und man muss 
sich auch nicht um das Zeitregime (Kollisionen) kümmern, das macht der 
CAN-controller im MC selbst. Und über die ID-Filter kann man am 
Empfänger auch gut einstellen, welche Nachrichten man überhaupt sehen 
bzw. darauf reagieren will.

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine andere Frage, speziell an einen Multi Master Bus waere die Buslast.
- 10% ist trivial, da kann man sich Retries leisten
- 50% ist eher nicht trivial, da muss man sich Muehe geben um Retries zu 
vermeiden
- 90% ist aufwendig.

Fuer bis zu 100% Buslast sollte man einen Bus verwenden, der dafuer 
zugeschnitten wurde. zB Arcnet. Der zieht 2.5MBit mit fast 100% 
Auslastung durch.

Fuer weitere Ideen sollte man sich die Stoerart und -haeufigkeit 
ueberlegen, und allenfalls optimieren.

A propos Koax, die gibt's auch mit 1mm Durchmesser.

: Bearbeitet durch User
Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitronen F. schrieb:
> Eine andere Frage, speziell an einen Multi Master Bus waere die Buslast.
> - 10% ist trivial, da kann man sich Retries leisten
> - 50% ist eher nicht trivial, da muss man sich Muehe geben um Retries zu
> vermeiden
> - 90% ist aufwendig.

Beim CAN-Bus sind 100% kein Problem (Collision Avoidance).

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es von mehreren Sendern NUR in eine Richtung geht, kann man sich 
per RS485 eine fest ans Timing gebundene Übertragung stricken.
Als Grundgedanke mal das DMX-Protokoll:
512 Kanäle werden sequentiell übertragen. Allerdings bei DMX von einem 
Sender. Wobei es auch hier "Merger" gibt, die Daten einfügen. Und genau 
so kann es funktionieren. Aber: Das Signal muss durchgeschleift werden 
und kann nicht nur angeklemmt werden.

Ich würde aber das "Weiterreichen" sowieso in Erwägung ziehen. Es 
vereinfacht die Sache, weil das Timing des Signals nicht von 
verschiedenen Sendern beeinflusst wird. Und das Signal wird immer wieder 
erneuert und somit am Ende der Kette nicht schlechter.
Wenn ein Sender abgekoppelt werden soll, kann man dies tun. Man muss 
eben die Leitung überbrücken und darf diese nicht unterbrechen.
Also wenn der Sender abgekoppelt wird, wird eben "Data In" mit "Data 
Out" gebrückt bzw. einfach die Leitungen zusammengesteckt.

Der erste Teilnehmer in der Kette sendet das Signal wie bei DMX, 
beginnend mit einem BREAK zur Erkennung des Startwertes.
Das Signal läuft in den nächsten Teilnehmer hinein. Dieser hat eine 
zugewiesene Adresse (einfachst per DIP-Switch).
Er liest den gesamten Datenblock maximal möglicher Teilnehmer (bei DMX 
512 Stück) ein, legt seine eignen Daten an die ihm mit der Adresse 
zugewiesenen Stelle rein und sendet das komplette Datenpaket weiter.

Jeder Teilnehmer kann nun auch bei Bedarf alle Daten der anderen 
Teilnehmer sehen.

Es ist einfach und man kommt mit einer UART aus.
Da die Daten weitergereicht werden, müsste man nicht einmal zwingend 
RS485 nehmen, sondern könnte sogar bei kurzen Wegen direkt das Signal 
der UART (TTL) nehmen.

Nur eben wie gesagt: Der "Bus" wird beim Entnehmen oder Abschalten eines 
Teilnehmers unterbrochen.
Wenn es nur ums Abschalten geht, könnte man ein direktes Durchschleifen 
des Signals auch elektronisch bewerkstelligen, wenn ein Teilnehmer 
keinen Saft hat. Dazu muss dieser nur im Betrieb aktiv das Signal für 
sich unterbrechen und an UART-In bzw. Out legen. Kostet im Zweifelsfall 
ein paar Transistoren oder wenns ganz Low-Tech sein kann, auch nur 2 
Relais-Wechselkontakte.
Kein großes Ding.

Ansonsten: CAN

Gruß



Jeder Sender muss nun das Timing verfolgen.

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN Bus hat eine kleine Payload von vielleicht 6 bytes, waehrend Arcnet 
512 oder 1k aufs Mal kann. Die Anbindung an einen Controller ist 
allerdings unterschiedlich

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Zitronen F. schrieb:
> CAN Bus hat eine kleine Payload von vielleicht 6 bytes

Ist jetzt kein echtes Problem, man sendet einfach mehrere Pakete 
hintereinander. Es gibt diverse CAN-Bootloader, die so funktionieren.

Die CAN-Controller haben oft auch große Puffer. Z.B. beim AT90CAN128 
kann man von den 15 Message Objekten 8 als Empfangspuffer konfigurieren, 
d.h. man kann 8 Pakete a 8 Byte = 64 Byte hintereinander rausrotzen, 
ohne das der Empfänger in den Interrupt springen muß. Man hat also eine 
sehr geringe Interruptlast.
Eine UART wäre da schon längst übergelaufen.

Autor: Eric B. (beric)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Alex G. schrieb:

> Es soll ja mehrere "Master" geben, wobei die nicht senden müssen.

Wie sollen die Master denn Master sein wenn sie deren Slaves nichts 
sagen dürfen?

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Funk?
Dann Suchtipp: RF24Mesh

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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