Forum: Mikrocontroller und Digitale Elektronik Das Ding mit den Bussystemen


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 Hallo23467 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin. Ich bin neu dabei was Bussysteme angeht.

Da gibt es ja dutzende Protokolle. Wie sieht das in der Praxis 
eigentlich aus, muss man dabei genau wissen wie die alle Funktionieren 
oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und 
hierfür CAN" und wendet dann einfach Methoden aus Libs an?

MFG

von Stefan L. (stefan_l134)


Bewertung
-1 lesenswert
nicht lesenswert
Beides richtig, würde ich sagen. Wenn man weiß wie die Busse 
funktionieren, kann man auch leicht sagen, wann welcher Bus sinn macht. 
Selber programmieren tut das am Ende wohl kaum jemand, da werden 
üblicherweise fertige Bibliotheken verwendet.

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Stefan L. schrieb:
> Selber programmieren tut das am Ende wohl kaum jemand, da werden
> üblicherweise fertige Bibliotheken verwendet.
Üblicherweise werden dafür zuallererst fertige Module in den Controllern 
verwendet.

Denn beim I²C und beim SPI könnte man sich noch noch mit Herumzerren an 
den Portpins behelfen, aber zumindest der SPI wird dadurch nicht 
schnell. Und man kann während der Übertragung nichts anderes tun.

Und wenn ein µC keinen CAN hat, dann programmiert man den sich nicht so 
einfach her. Sondern man muss extern einen Baustein anschließen, der mit 
einem Bus angesteuert wird, den der µC hat.

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
Hallo23467 schrieb:
> "Ah hierfür benutzt man I2C und hierfür CAN"

Im Groben läuft das so, Ja.
Aber das kann man nur aus dem Bauch heraus entscheiden, wenn mann einen 
groben Überblick der Bussysteme hat. Und dafür muss man nicht "genau 
wissen wie die alle Funktionieren" sondern zumindest wie auf 
Konzeptebene funktionieren.

Das Bussystem ergibt sich aber eigentlich aus den Anforderungen heraus 
und nicht umgekehrt.
Ist alles auf einer Platine, oder verteilt, welche Geschwindigkeiten 
werden gefordert und dann vor allem: Welche fertig kaufbaren Komponenten 
gibt es für deinen Anwendungsfall.
Ach und falls Hobby: Gibt es fertige, frei verfügbare Bibliotheken 
dafür.

von Schlaumaier (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Wenn nicht das Projekt zwingend den Bus vorschreibt, (z.b. durch eine 
Zusatzplatine entscheidet) muss man eine Kosten/Nutzenanalyse machen.

Klingt schlimmer als  es ist.

Ich weiß das z.b. für meine Projekte ein ARDUINO ausreicht. Also schaue 
ich welche Bussysteme der Prozessor (ATMEL) kann. Beim Arduino sind es 
2.

Also einfach die passende Libs ziehen, für 90% aller Hardware gibt es 
eine.
Installieren bzw. einbinden, und das war es.  Lass dich nicht von den 
Experden verwirren. Libs sind dafür da, Zeit zu sparen und solange sie 
in den Speicher des Chip passen, nutze Sie. Du hast immerhin den ganzen 
Speicher bezahlt. ;)

Bei einen anderen Projekt kann es sein das die Entscheidung anders 
ausfällt.

Ein Arduino ist weder ein Allheilmittel noch der schnellste auf diesen 
Planeten. ;) Aber 1.50 Euro als fertige Platine mit Usb-Anschluss und 
Co. soll erst mal ein anderer bringen ;)

Grundsätzlich gilt. Eine gute Planung spart Geld, Zeit und vor allen 
Dingen nerven.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Hallo23467 schrieb:
> Moin. Ich bin neu dabei was Bussysteme angeht.

Du meinst wohl Feldbusse. Dann sag das auch. Es gibt nämlich auch eine 
ganze Menge Bussysteme, die keine Feldbusse sind.

> Da gibt es ja dutzende Protokolle. Wie sieht das in der Praxis
> eigentlich aus, muss man dabei genau wissen wie die alle Funktionieren
> oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und
> hierfür CAN" und wendet dann einfach Methoden aus Libs an?

Du meine Güte, hier geht ja alles durcheinander. Die Auswahl eines 
geeigneten Feldbusses. Protokolle. Und dann noch Software.

Verschiedene Feldbusse haben verschiedene Eigenschaften. Und sind 
deswegen auch jeweils für verschiedene Aufgabenstellungen besser bzw. 
überhaupt geeignet. Man muß die Eigenschaften kennen und seine 
Anforderungen, um eine Auswahl zu treffen.

Ein Bus ist in erster Linie erstmal Hardware. Wenn dein Controller kein 
CAN Interface hat, dann kannst du offensichtlich auch keinen CAN-Bus 
damit betreiben. Damit hast du jetzt schon die zweite Einschränkung bei 
deiner Auswahl.

Die Software schließlich implementiert in der Tat das (bzw. ein) 
Protokoll für den Bus. Für kompliziertere Sachen wie CAN oder LIN wird 
man bevorzugt auf eine fertige Library setzen. Für einfaches Zeug wie 
I²C braucht man das eher nicht. Da ist das Protokoll (wenn man es denn 
so nennen will) im wesentlichen spezifisch für das Gerät am anderen 
Ende.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Merkmale, anhand derer sich Bussysteme unterscheiden lassen sind

parallel vs seriell:
werden mehrere Datenleitungen benutzt oder werden Bits nacheinander 
übertragen?

Differentiell oder Single-Ended?
Werden zur Datenübertragung 2 Leitungen verwendet und der Empfänger 
misst die Spannung zwischen diesen 2 Leitungen oder ist es nur Leitung, 
die gegen GND gemessen wird?

Full-Duplex, Halb-Duplex?
Kann gleichzeitig empfangen und gesendet werden oder immer nur 
abwechseln?

Master-Slave, Multi-Master?
Erfolgt der Schreibzugriff auf den Bus nur auf Befehl von einer 
zentralen Stelle (Master-Slave) oder haben Busteilnehmer selbst die 
Möglichkeit, auf den Bus zu schreiben?


Das sind so die ganz großen Unterschiede. Zur Einordnung eines neuen Bus 
ist es immer hilfreich, diese Kategorisierung zu machen, weil damit auch 
wesentliche Eigenschaften des Bus gerklärt sind.

Parallel braucht mehr Leitungen. Weil alle Signale gleichzeitig am Ziel 
sein müssen gibt es Probleme bei längeren Strecken und oder höheren 
Geschwindigkeiten.
Differentiell hat einen viel höheren Störabstand als Single Ended.
Für Full-Duplex braucht man mehrere Leitungen oder spezielle Tricks, um 
das mit einer Leitung zu machen. Für Halb-Duplex irgendeine Koordination 
des Zugriffs.
Wenn ein Bus Multi-Master ist braucht er irgendwelche Mechanismen, um 
Kollisionen zu behandeln. (wenn zufällig 2 gleichzeitig anfangen zu 
senden).

von Hallo23467 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Axel S. schrieb:

> Du meine Güte, hier geht ja alles durcheinander. Die Auswahl eines
> geeigneten Feldbusses. Protokolle. Und dann noch Software.

Nur so als Tipp: Du schreibst das Selbe wie alle Anderen, nur mit 
ekelhafter Attitüde. Dein Post wiederholt die vor dir, deinen hättest du 
dir komplett sparen können. Aber du musstet natürlich etwas dazu 
schreiben und damit es irgendwie anders klingt noch mit dieser Art und 
Weise.

Bringt nix.

MFG.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Noch eine Unterscheidung wäre synchron vs. asynchron

Bei synchron gibt es eine Taktleitung, die ansagt wann neue Daten da 
sind oder auf den Bus gelegt werden müssen, z.B. beim Parallel-Port, bei 
GPIB, I2C, SPI.

Asynchron gibt es keinen Takt, der Sender legt die Bits nacheinander auf 
die Leitung und es gibt ein einzuhaltendes Timing. (RS232, RS485, CAN, 
LIN)

von Hallo23467 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Tilo

Ja genau. So ist es. Das muss man natürlich alles bedenken, nur wird man 
ja sicher Libs dazu nutzen und das Protokoll nicht neu schreiben. JEder 
Chef würde ja am Rad drehen, wenn man pausenlos das Rad neu erfindet.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo23467 schrieb:
> @Tilo
>
> Ja genau. So ist es. Das muss man natürlich alles bedenken, nur wird man
> ja sicher Libs dazu nutzen und das Protokoll nicht neu schreiben. JEder
> Chef würde ja am Rad drehen, wenn man pausenlos das Rad neu erfindet.

Ja, aber das sind ganz unterschiedliche Ebenen!

Der Bus, also wie er elektrisch funktioniert, welches Zugriffsverfahren 
benutzt wird, alle Unterscheidungsmerkmale von oben, sind es, die 
bestimmen wofür sich ein Bus eignet. (Lange/Kurze Entfernung, 
schnell/langsam...)

Wenn man dann tatsächlich einen bestimmten Bus benutzen will, braucht 
man die notwendige Hardware, die an die Leitung angeschlossen werden 
kann.
Das sind z.B. Leitungstreiber und -Empfänger, bei RS485 braucht man 
einen Treiber, der die 2 differentiellen Signalleitungen mit ordentlich 
Spannung treibt und einen Empfänger, der aus der Differenzspannung 
wieder ein digitales Signal macht.
Hardware ist aber auch oft in Silizium gegossene Logik. Ein UART bei 
seriellen Protokollen kümmert sich um das getaktete Rausschieben und 
Einlesen von Bits. Ein CAN-Controller kümmert sich um den Buszugriff, 
mögliche Kollisionen und prüft die Checksumme.

Damit man von der Software aus die Hardware benutzen kann verwendet man 
dann oft Bibliotheken.
Bei einfacheren Protokollen ist es manchmal so, dass nicht zwingend eine 
Bibliothek notwendig ist. SPI z.B. ist technisch so simpel, dass man 
auch direkt die Register Schreiben/Lesen kann, über die die Hardware 
angesteuert wird.

von Hallo234578 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:

> Ja, aber das sind ganz unterschiedliche Ebenen!

Eben.

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
In der Praxis:
1.  Wofür brauche ich den Bus? --> Was kommt in Frage?
2a Hat meine Hardware davon schon irgendwas an Bord? Falls nicht: Was 
brauche ich zusätzlich, kann ich es in Software machen?
2b Gibt es dafür fertige Bibliotheken?

Und dann kommt das abwägen der Vor- und Nachteile, letztlich eine 
Entscheidung.
Und natürlich wird man auch berücksichtigen, womit man bereits 
Erfahrungen hat und was an dieser Stelle üblicherweise verwendet wird.

Es gibt hier im Forum etliche Beispiele, wo jemand einen ungeeigneten 
Bus verwendet hat und sich vom Forum dann Hilfe versprochen hat.
Jüngstes Beispiel im Forum war imho, wo jemand mit I2C Daten über 15 
Meter übertragen hat und dann Störungen bekam, sobald ein Motor 
eingeschaltet wurde.
Tja, Frage 1!

Wenn du noch unsicher bist, klassifiziere halt mal die üblichen 
Verdächtigen.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich läuft es anders herum. Man bekommt eine Aufgabe (oder möchte 
etwas machen) und überlegt sich, was man kennt (z.B. Tasten, Display) 
und was man nicht kennt (100 Byte jede Sekunde zwischen 5 Geräten 
austauschen, 1MB-EEprom anschließen). Und dann schaut man halt beim 
Auftraggeber oder bei ähnlichen Projekten, wie die das machen. Und wenn 
es damit Problem gibt, schaut man, was es sonst noch so gibt.


Wer (auf dem PCB) ein SO-8 EEPROM mit 1MB anschließen will, oder einen 
Lagesensor, der findet als Schnittstelle quasi nur I2C und SPI. Der 
Fragt sich nicht, ob CAN, RS232 oder Ethernet nicht auch gehen.

Wenn I2C (um beim Beispiel zu bleiben) ausreicht, dann nimmt man das. 
Oder SPI. Wenn man 4 ICs braucht und die Adressierung noch passt, und 
Portpins knap sind, nimmt man I2C, wenn man mehr Geschwindigkeit 
braucht, SPI. Das alles aber im Vorfeld, bevor man das erste Layout 
macht.

Sich busse einfach mal so anschauen, ist wie Klavierspielen auf einem 
Keyboard ohne Strom. Ja, mit Erfahrung OK, ohne Erfahrung eher nutzlos.

von Tilo R. (joey5337) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
A. S. schrieb:
> Sich busse einfach mal so anschauen, ist wie Klavierspielen auf einem
> Keyboard ohne Strom. Ja, mit Erfahrung OK, ohne Erfahrung eher nutzlos.

Das sehe ich anders.
Ich denke SPI, I2C, RS232, RS485 und CAN sollte man sich schon mal grob 
angeschaut haben. Wenn man dann mal irgendwas anderem begegnet kann man 
das vergleichend einordnen.

SPI und I2C werfe ich dabei mal in einen Topf (der Unterschied ja 
hauptsächlich die zusätzliche Adressierung und Leitungszahl). 
Single-Ended, kleine Pegel. Am Besten auf einer Platine bleiben, 
definitiv keine großen Strecken.

RS232 hat viel höhere Pegel und geht deswegen weiter. Und hat nur 2 
Kommunikationspartner. Es gibt aber auch RS232 mit kleinen Pegeln, kann 
praktisch sein.

RS485 hat differentielle Pegel, ist noch störsicherer, kann ggf. mehr 
Teilnehmer, man muss sich aber um den Buszugriff kümmern.

CAN hat auch differentielle Pegel, legt aber auch das 
Buszugriffsverfahren und die Kodierung fest. Und semantisch diskutiert 
man dann nicht mehr über Sender und Empfänger sondern über Botschaften 
die auf den Bus gelegt werden. (Imho ein wichtiger, oft nicht 
verstandener Punkt)

von Timo N. (tnn85)


Bewertung
-1 lesenswert
nicht lesenswert
Finde es immer witzig: Der Bus, der gar nicht genannt wird, der am 
häufigsten verwendet wird und von dem die wenigstens Ahnung haben wie er 
funktioniert: USB

von WerWieWas (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Timo N. schrieb:
> Finde es immer witzig: Der Bus, der gar nicht genannt wird, der am
> häufigsten verwendet wird und von dem die wenigstens Ahnung haben wie er
> funktioniert: USB

Ja schon :) Bei USB läuft i.d.R. fast alles über Libs und Frameworks. 
Nur Freaks oder Idioten (oder beides) meinen immer wieder, man kann das 
doch vieel besser als der uC Hersteller oder die Zulieferer 
implementieren.

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Ich denke SPI, I2C, RS232, RS485 und CAN sollte man sich schon mal grob
> angeschaut haben. Wenn man dann mal irgendwas anderem begegnet kann man
> das vergleichend einordnen.

Stimme dem zu, wobei ich für RS232/485 folgende Unterteilung machen 
würde:
Zuerst die Grundlage: UART
Dann die physikalische Ebene: RS232  RS422  RS485 / (HART)
Dann das Protokoll: Profibus, Modbus, etc.

Die etablierten Bussysteme geben eigentlich immer das Protokoll und die 
physikalische Ebene vor.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
WerWieWas schrieb:
> Bei USB läuft i.d.R. fast alles über Libs und Frameworks.

Wobei der Niklas G hier einen tollen Artikel samt C++ Beispiel dazu 
verfasst hat. Und W.S. hat eine kompakte Implementierung in C 
geschrieben, die mir persönlich das "aha" (so geht das) Erlebnis 
brachte.

von WerWieWas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Wobei der Niklas G hier einen tollen Artikel samt C++ Beispiel dazu
> verfasst hat. Und W.S. hat eine kompakte Implementierung in C
> geschrieben, die mir persönlich das "aha" (so geht das) Erlebnis
> brachte.

Das ist schon für diejenigen, die das dann auch so genau wissen wollen. 
Den meisten reicht es wahrscheinlich einfach zu wissen, wie das ganze 
grob funktioniert (Endpoints etc.).

Ist aber nur meine Meinung ;)
Wenn ich mit der Grundeinstellung, jedes Subsystem, Betriebssystem usw. 
bis aufs letzte Bit verstehen zu wollen entwickeln würde, würde das 
Produkt vermutlich in zig
Jahren nicht fertig sein.
Genau dafür wurden HALs entwickelt, genau deshalb gibt es Frameworks und 
Libs. Um immer wieder kehrende, oft auch normierte Vorgänge nicht jedes 
Mal neu implementieren zu müssen.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Hallo23467 schrieb:
> oder sagt man tatsächlich einfach "Ah hierfür benutzt man I2C und
> hierfür CAN" und wendet dann einfach Methoden aus Libs an?

noch ein Bus ohne I2C ohne CAN
https://de.wikipedia.org/wiki/Europe_Card_Bus#

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Also einfach die passende Libs ziehen, für 90% aller Hardware gibt es
> eine. Installieren bzw. einbinden, und das war es.  Lass dich nicht von
> den Experden verwirren. Libs sind dafür da, Zeit zu sparen und solange
> sie in den Speicher des Chip passen, nutze Sie.

Hmm, merkwürdig, bei 50% meiner Projekte kann ich die Libs nicht so 
verwenden, sie kollidieren mit Ressourcenbelegung, lassen sich nicht 
simultan mit anderen verwenden, oder sind schlicht umfangreicher als 
benötigt.

Nur Mal ein Beispiel: ATmega328 bedient LCD Glas, das erzwingt alle 2ms 
einen Interrupt der nicht zeitverschoben werden darf. Dazu muss man aber 
sekündlich ein DS18S20 (OneWire) oder TSIC306 (Zacwire) auslesen, deren 
Auslesevorgang länger als 2ms benôtigt. Da ist ganz schnell Ende mit 
vorgefertigten Libs. Die sind eher für Laien.

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.

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