Wann fährt welcher BUS?

Wenn Du genau hinsehen würdest, sähest Du, daß all diese Systeme ihre 
indviduellen Vor- und Nachteile haben, und es daher auf die Anwendung 
ankommt, welche Variante ausgewählt wird.

Parameter sind unter anderem Geschwindigkeit, Aufwand, 
Übertragungslänge, Multimasterfähigkeit und letztlich auch der Preis der 
Komponenten.

Mal gewinnt der eine, mal der andere, aber keiner davon taugt, um 
universell in allen Szenarios verwendet zu werden.

USB beispielsweise kann sehr schnell werden, ist aber nur auf 
logischer Ebene ein Bus, physikalisch ist das immer eine 
Punkt-zu-Punkt-Verbindung. Die maximale Übertragunglänge ist recht stark 
beschränkt, der zu treibende Aufwand ist enorm, und multimasterfähig ist 
das ganze erst recht nicht.

BUS schrieb:
> Wo liegen die konkreten Vorteile einer Verbindung gegenüber den anderen,

Das schreit nach einer Tabelle. Haben wir noch keine im Wiki?

Zu USB hat Rufus ja schon was geschrieben.

Stefan U. schrieb:
> Wozu? Brauche ich nicht.

Egoist ist ein Scheißberuf.

MfG Paul

BUS schrieb:
> Hallo,
>
> sagt mal, I2C, SPI, UART, USB, CAN sind doch alles irgendwie
> Nahstrecken-Kommunikations-BUS-Verbindungen.
>
> Warum setzt sich nicht eine davon gegenüber allen anderen durch?
>
> Wo liegen die konkreten Vorteile einer Verbindung gegenüber den anderen,
> dass es offenbar für jede von ihnen einen Anwendungsfall gibt...?

Hört sich mal wieder nach einem Referat an.

Arduino F. schrieb:
> z.B. TokenRing

Token Ring (IEEE 802.5) ist kein allgemeiner Begriff, sondern steht für 
eine ganz bestimmte LAN Technik, entwickelt von IBM. Der allgemeine 
Begriff dafür ist Token Passing.

Dieter F. schrieb:
>> Token Passing
>
> Und ich dachte immer der heißt "Toten Ring" :-)

It passed away.

Mit Sicherheit eine Schulaufgabe :-)
Wer sich tatsächlich damit beschäftigt, weiss auch sehr schnell um die 
Vor- und Nachteile Bescheid.
Andererseits gibt es ja immer wieder mal Leute, die I2C als Hausbus 
aufbauen (wollen). Dem fehlen (neben physikalischer Uneignung, die man 
mit Hilfskrücken durchaus ein Stück weit übertünchen kann) dennoch 
wichtige Eigenschaften für diese Aufgabe.

Na ja, ganz so ist es ja nicht. Im PC Bereich hat sich Ethernet 
durchgesetzt und im gesamten Fahrzeugbereich ist CAN weit vorne.
Vielleicht gibt es ja irgendwann mal Ethernet_embedded? Wer weiß das 
schon?

Es ist auch nicht immer das "beste System" der Gewinner. Denken wir mal 
an die Videorekorder, von allen Systemen hat VHS am Ende gesiegt, obwohl 
es das schlechteste System war. Die Kassetten waren halt eine DM 
günstiger (obwohl das an der Spiellänge gemessen und der Qualität, gegen 
Betamax, auch nicht stimmt).
VHS=4,99 DM und Betamax=6,30 DM.
So ist das eben.

Dieter F. schrieb:
> God shave the Queen :-)

,8,1

GanzHintenImBus schrieb:
> I2C:
> ...
> Recht störempfindlich, weil kein aktiver High-Pegel, empfindlch auf
> Kapazitäten.

Nö, I2C ist erheblich unempfindlicher als SPI.
Und bei hohen Leitungskapazitäten paßt sich die Datenrate automatisch 
an.
Ich hatte mal versehentlich an SDA/SCL jeweils 100nF angelötet, ging 
immer noch ohne Datenfehler. Ich hatte mich nur gewundert, warum es 
langsamer wurde.
Bei SPI reichen schon 20cm Flachkabel, damit es Fehler gibt.

GanzHintenImBus schrieb:
> Ein Bus, aber pro Gerät ein Chipselect.
> Relativ simpel, aber jedes Gerät braucht ein Chipselect.

Allgemein, ja. Immer, nein.

>UART:
Eigentlich war das mal RS232 und für größere Strecken gedacht. ist ein
Asynchrones Protokoll und daher gegenüber Laufzeiten immun. Daher gute
Reichweite.
Voll Bidirektional.
Niedrige bis mittlere Datenrate (so 9,6kBd-2MBd oder mehr)
Punkt - zu - punkt.
2 Leitungen.
Aber hoher Aufwand nötig - Oft ein Quarz zum Beispiel.


Ist so nicht korrekt. Ein UART ist weder RS232, noch ein protokol, noch 
Punkt zu punkt.
Ein UART ist ein Serializer, der arbeitet. Erst mit einem RS232 Treiber 
wird es zum RS232, mit einem RS485 Treiber wird es zum RS485, mit einem 
RS422 Treiber zu einem RS422. Mit einem schnellen Treiber kann es auch 
1MBit machen, und auch mehrere hundert Meter. Der Quarz oder aehnlich 
ist bei allen Kommunikationsbausteinen notwendig.

>SPI:
Synchron, sehr schnell.
Sehr empfindlich auf Verzögerungen und daher nur für kurze Strecken
geeignet.

Das ist so auch nicht richtig. Der Clock ist ja dabei. Solange der Clock 
bei einem stabilen Datensignal kommt gibt es keine Probleme. Ich muss 
mich nicht an ein Baubrate halten, und kann mir zwischen nachfolgenden 
Bit irgendwelche Zeit nehmen. Es ist nur deshalb nur fuer kurze 
Distanzen wenn man's ohne Treiber verwendet. Ich kann SPI mit RS232, 
RS422 oder RS485 Treiber versehen und habe deren Reichweite. Gleichfalls 
kann ich ein UART, ohne Treiber auch nur auf kurze Distanzen verwenden. 
Dies weil, "keine Treiber" halt nicht so viel taugt.

GanzHintenImBus schrieb:
> Und I2C passt nicht seine Datenrate an. Wie kommst du denn auf dieses
> dünne Brett?

Das steht so in der Spezifikation. Der Master muß mitlauschen, wann auf 
SCL der High-Pegel erreicht wird und wartet solange. Nennt sich 
Clock-Stretching. Kann man sehr schön mit dem Oszi sehen.
Am besten haben die alten 8051-I2C von Philips/NXP den Standard 
eingehalten. Damit hatte ich das auch mit den 100nF getestet.
Bei den ARM-Cortex LPCxxxx von NXP habe ich das noch nicht geprüft.

Es gibt leider auch Implementationen anderer Hersteller, die nicht 
standard konform sind, aber da kann der I2C ja nichts dafür.

TrollHunter schrieb:
> Freundin ist grad schon 2,5 Stunden unterwegs für ne Strecke von 7 km,
> bloß weil irgendwo ein Blatt hochkant auf der Straße liegt.

Wenn sie dann ankommt, ist ihre Parität bestimmt ungerade.
;)

MfG Paul

Zu den frueheren Tagen des Ethernet. Vor 30 Jahren gab es Arcnet, mit 
2.5 MBit, Ethernet auf Koax mit 10MBit, und Tokenring mit 16 MBit. Die 
Zahlen taeuschen. Mehrfach.

Tokenring war von IBM, lief natuerlich nur auf einem PS/2 PC, und war 
sauteuer. IBM eben. IBM hatte grad den PC verschlafen und wollte im 
Premium Level einsteigen. Die grossen Firmen waren traditionell IBM 
Kunden, und haben den PC als Spielzeug verstanden, fuer Sekretaerinnen. 
Die haben dann auch IBM PCs gekauft als die langsam kamen. Die 
Ausrichtung auf die Premiumlinie, PS/2 war fuer den Tokenring 
unguenstig, denn er wurde von der PC Welt nicht adoptiert, war 
wahrscheinlich auch patentiert, nicht offen. Der PC von IBM, der PS/2, 
war technisch ueberlegen, der Tokenring auch, war aber aus 
marktpolitischen Gruenden zu teuer. Der Tokenring hatte zwei 
geschlossene Ringe, der eine ging links rum, der andere ging rechts rum, 
die Stationen waren geometrisch in Serie. Wenn eines der Kabel ausfiel, 
konfiguriert sich der Bus um und arbeitete weiter. Offensichtlich war 
das nicht das Killer-Feature, das der Markt unbedingt gebraucht haette. 
Und die 16MBit auch nicht, da per Zahl nur 1.6 mal schneller wie 
Ethernet. In Realitaet konnte der dank des Tokens auch auf 100% 
ausgelastet werden. Aber diese Bandbreite wurde damals eh nicht 
gebraucht, sodass das nicht weiter auffiel.

Arcnet hatte zwar nur 2.5MBit, war aber ein kooperativer Bus mit Token, 
das per Software rumging, und konnte die 2.5MBit auch bis 100% Last 
bringen, also mehrere Stationen konnten gleichzeitig Daten drueber 
lassen, und den Bus bis quasi 100% belegen. Er war auch nicht teuer. Die 
busarbitrierung wurde von einem chipset erledigt. Und da waren 4 buffer 
zu 1KByte, die konnten wahlweise einzeln und dynamisch als Rx- oder 
Tx-Buffer verwendet werden. Die Uebertragung war auch per hardware 
gehandshaket, dh der Sender wusste auch gleich, ob die Meldung auf der 
anderen Seite ankam. Auch hier wurde die benutzbare Bandbreite von 
2.5MBit nicht wirklich gebraucht, das fiel bei den PC's nicht weiter 
auf. Arcnet wurde, und wird moeglicherweise immer noch fuer Busse 
verwendet, die zuverlaessig die ganze Bandbreite bringen muessen.

Ethernet als 10Base2, mit Koax, hatte zwar 10MBit, brachte die aber 
nicht. Denn das Protokoll war CD/CSMA, Carrier detect, multiple access. 
Die Verbindungsaufnahme war unguenstig. Jeder darf mal senden und wenn's 
nicht geklappt hat wird nach einer Zufallszeit nochmals probiert. Dh die 
10MBit gingen sehr schnell bei mehr als einer Station in die Knie. Aber 
die 10MBit klangen bessen, und Ethernet hatte wohl das bessere 
Marketing.

Arcnet und Tokenring waren beide deterministisch, und somit Echtzeit 
tauglich, wahrend es ethernet nicht war.

Heisst die mit Abstand schlechteste Loesung gewann. schade. Es hat sich 
aber weiter entwickelt. Ein Nachteil, alle Stationen muessen ueber 
switsches angegschlossen werden und dise machen im Wesentlichen eine 
Punkt zu Punkt verbindung. Sind aber auch Single Point of Failure. 
Heisst wenn der Switch ausfaellt, faellt das Netzwerk aus. Das war bei 
den anderen systemen nicht so. Beim urspruenglichen Ethernet auch nicht. 
Dort waren die Stationen an einem Kabel, und benoetigten keinen 
Koordinator.

Oh D. schrieb:
> Vor 30 Jahren gab es Arcnet,

Arcnet gibts in ein paar Industrie-Nischen auch heute noch.

> Die grossen Firmen waren traditionell IBM
> Kunden, und haben den PC als Spielzeug verstanden, fuer Sekretaerinnen.
> Die haben dann auch IBM PCs gekauft als die langsam kamen.

Da spielten auch IBMs Mainframes mit hinein. Nämlich deren Terminals. 
Die Mainframes konnten Token Ring von Haus aus, Ethernet aber bloss ums 
Eck. Ob nun per Programm auf dem PC oder als reines Terminal, Token Ring 
war da die naheliegende Lösung.

Token Ring gab es nicht nur für PS/2 mit Microchannel, sondern auch für 
andere PC-Hardware, ISA-Bus inklusive.

> PS/2 war fuer den Tokenring
> unguenstig, denn er wurde von der PC Welt nicht adoptiert,

Daumenregel damals war: Wenn IBM "A" sagt macht der Rest der Welt 
grundsätzlich "B". IBM wollte den Markt unter Kontrolle haben, die 
anderen wollen genau das vermeiden. Eine Technik, der sich IBM 
strategisch widmete, konnte schon allein dadurch ein Problem bekommen.

> Der Tokenring hatte zwei
> geschlossene Ringe, der eine ging links rum, der andere ging rechts rum,

Du verwechselst das mit FDDI. Da war das so (und bei SSA), nicht aber 
beim Token Ring.

Token Ring hatte nur einen Ring, und der war in der üblichen Verkabelung 
nur topologisch ein Ring, physikalisch aber ein Stern, soweit es die 
angeschlossenen Endgeräte betrifft. Wenn da eine Node abschaltete, dann 
schaltete der Port im Konzentrator ab und der Ring war wieder 
geschlossen.

Eine defekte Node, oder eine mit falscher Bitrate (4 vs 16), legte den 
Ring still und die Suche ging los.

Stefan U. schrieb:
> Sicher? Also mein Laptop kommuniziert täglich über WiFi,

1:0 für dich, Stefan. Meiner auch. Aber ich hatte Kabel im Kopf. Und 
dennoch, das Protokoll dahinter (also hinter WiFi) IP V4/V6.

F. F. schrieb:
> Aber ich hatte Kabel im Kopf.

Das hört sich nicht gesund an...
Hast Du denn wenigstens einen BNC-Anschluß dafür?

MfG Paul

Ist aber mal wieder ein schöner Thread. Ohne diese ständige Polemik (bis 
jetzt) und man kann mit einem Schmunzeln sehen, dass andere auch schon 
all die Anfänge (BNC) hinter sich haben (und wohl auch schon so alt 
sind), wie man selbst.

Ebenso finde ich es toll, dass hier dann, neben einem ordentlichem 
Wissen, auch die Erfahrungen mit gepostet werden.
Vielen Dank dafür, lieber Peter Dannegger.

Auch wenn hier oft viel Mist ist und der Zoff nach wenigen Beiträgen 
wieder los geht, für solche Beiträge lohnt es sich.

Was haltet ihr von One-Wire? Gerade im Heimautomationsbereich würde der 
doch für alle Anwendungen (die ich mir im Moment vorstellen kann) doch 
völlig reichen.


Welcher "Busfahrer", der sich gut mit allen Bussen auskennt, wäre denn 
bereit mal ein Wiki aufzusetzen?
Alle Vorzüge und Nachteile, speziell auf unser Hobby (bei vielen ja auch 
Beruf) bezogen. Auch eine Spalte für persönliche Erfahrungen wäre sehr 
gut.

Auch wenn der TO dort viele negative Einträge bekommen hat, ich finde es 
toll was danach alles geschrieben wurde.
Das hat den Thread wenigstens für mich sehr interessant gemacht.

THOR schrieb:
> aber ich halte es da mit der weisen Lebensregel Nummer drei:
>
> https://tools.ietf.org/html/rfc1925

Ist auch immer wieder lustig, wenn Anfänger meinen, bei 2 Tasks mit 
jeweils 1% CPU-Load könnte man einfach 2 MCs vernetzen, damit die nur zu 
1% ausgelastet sind.

Wolf-Stefan schrieb:
> Einen Anfang gibt es doch schon:

Jau, danke für den Hinweis.

Ich hatte mal ein tolles Buch über sämtliche Busse. Leider gibt es das 
nicht mehr und der, der es sich ausgeliehen hatte, konnte es wohl besser 
gebrauchen und gab es nicht mehr zurück. :-(

In der Verlinkung auf "Hausbus" steht ja doch auch schon eine Menge.

Müsste man vielleicht mal umbenennen.

n0a schrieb:
> USB Typ C könnte bald, auch im µC-Bereich, diese Vereinheitlichung
> bringen.

Nur das USB Typ C kein Bus ist sondern die Steckverbindung.
Es verbleibt immer noch der USB Bus

Leider bin ich mit den Bussen nicht so tief vertraut wie die meisten 
anderen hier. Daher frage ich mal vorsichtig, auch auf die Gefahr hin 
ausgelacht zu werden.
Könnte man nicht einen relativ einfachen Bus, wie One-Wire in einem µC 
integrieren, dass man quasi auf Softwareebene ein One-Wire Device 
schafft?

Ich frage das aus bestimmten Grund, nur würde das den Thread zu sehr in 
eine andere Richtung leiten.

F. F. schrieb:
> Was haltet ihr von One-Wire? Gerade im Heimautomationsbereich würde der
> doch für alle Anwendungen (die ich mir im Moment vorstellen kann) doch
> völlig reichen.

Ich bin noch nirgends einem µC begegnet, der einen 1W-Slave in Hardware 
implementiert, oder zumindest spürbar dabei assistiert. Mag sein, dass 
Dallas/Maxim sowas hat, aber sonst? Ohne Unterstützung durch Hardware 
ist die Implementierung eines Slave eine Echtzeit-Aufgabe der etwas 
knackigeren Sorte und nicht immer mit anderen Aufgaben des µC 
verträglich.

Und wenn man eine Lösung dazu nicht nur im eigenen Garten vergräbt, 
sondern sie sich zu einer Community entwickeln sollte, dann könnte es 
sein, dass man sich mit irgendwelchem Patent/Lizenz-Mist rumärgern muss.

Beitrag "1-Wire Slave auf AVR"
http://www.fhemwiki.de/wiki/1-Wire_Emulation_per_ATTiny
https://www.tm3d.de/index.php/1-wire-device-mit-avr

Danke!

... aber ist dann doch noch was draus geworden.

So einen minimal Bus für die ganz kleinen Tinys (ATTiny10), ähnlich OW, 
das wäre was. Hat so was schon jemand geschrieben?

Birgit schrieb:
> Da liest man die überschrift und denkt sich, ah eine interessante
> Diskussion über die Vor und Nachteile verschiedener Bussysteme..

Warum sollte man allgemeine Fakten diskutieren? Wenn es um eine 
bestimmte Anwendung (Hausbus, Trolleybus) ginge, wäre das was anderes. 
So aber reicht ein Verweis aufs Wiki.

F. F. schrieb:
> OW

Ich habe spontan 0W gelesen und mich gefragt, wie du einen wired-Bus 
ohne Kabel hinbekommen willst. :-)

S. R. schrieb:
> Ich habe spontan 0W gelesen und mich gefragt, wie du einen wired-Bus
> ohne Kabel hinbekommen willst. :-)

:-)
Darüber müssen wir unbedingt diskutieren. ;-)