Moin moin Community, da bin ich wieder mit einer weiteren Wissensfrage. Nach wie vor lese ich mich noch in sämtliche Themen vun uCs ein und bin grade bei dem Thema der BUS-Systeme. Wie so einige BUS-Systeme funktionieren konnte ich mir gut erarbeiten, wo alle was gutes für sich haben. Allerdings würde ich mich im Ernstfall schwer tun das richtige Bussystem für eine Anwendung (welche auch immer) auszuwählen. Deswegen suche ich nun seit ein paar Stunden eine Übersicht. Werde allerdings nicht wirklich fündig. Was mir weiterhelfen würde wäre eine Auflistung sämtlicher Bussystemen die mit den AVR uCs möglich sind. (Alte nicht mehr gebräuchliche mal ausgeschlossen) Da könnte ich mir dann zumindest jedes Bussystem erarbeiten und dann meine eigenen Schlussfolgerungen ziehen. Wirklich schön wäre natürlich eine kleine Tabelle mit den Bussystemen und deren Vor- und Nachteilen sowie Funktionsweise. (Nur wenn es sowas gibt. Möchte mich ja auch nicht unbedingt ins gemachte Nest setzen.) Kann mir da irgendwer weiterhelfen? Gruß
Schau mal auf Bus - dort gibt es einen Link zu http://www.maximintegrated.com/app-notes/index.mvp/id/3438 - und auf Hausbus.
Christian O. schrieb: > Moin moin Community, > > da bin ich wieder mit einer weiteren Wissensfrage. > Nach wie vor lese ich mich noch in sämtliche Themen vun uCs ein und bin > grade bei dem Thema der BUS-Systeme. Woran man sieht: Eine so theoretische Herangehensweise an das Problem, bringt eigentlich wenig. Wer mal ein wenig mit "Bussystemen" in der Praxis gearbeitet hat, der stellt solche Fragen nicht. > Wie so einige BUS-Systeme funktionieren konnte ich mir gut erarbeiten, > wo alle was gutes für sich haben. Zum Beispiel? "Bussysteme" ist ein wenig allgemein gehalten. Darunter kann man sich alles und nichts vorstellen. > Allerdings würde ich mich im Ernstfall schwer tun das richtige Bussystem > für eine Anwendung (welche auch immer) auszuwählen. Glaubst du du hast da die freie Auswahl? Das ist immer von den Umständen abhängig und von deinen Ressourcen. Niemand stellt sich hin und kann hier unter 50 Systemen auswählen. Vor allem: Um was geht es hier? Parallele Busse? Auf der Platine? Im Feld? Zum Verbinden von was? So ein allgemeines Geschwurbel von "Bussystemen" bringt doch nichts. gruß cyblord
Christian O. schrieb: > (Alte nicht mehr gebräuchliche mal > ausgeschlossen) Das wird schwer, selbst GPIB/IEEE488 ist oft noch im Einsatz. Wieviel 100 Busse möchtest Du denn genannt haben?
Oftmals definiert sich ein Bus vor allem über die höheren Protokollebenen und die physikalische Verbindung ist entweder nicht definiert oder entspricht einem bestimmten anderen "Bussystem". Beispiel wäre hier Profibus. gruß cyblord
Ok bevor ich hier zerpflückt werde: Ich habe bereits praktische Erfahrung in einigen Systemen aufgrund meines Berufes (Produktionsautomation etc...) Dazu gehörten bisher Profibus, Interbus, ASIBus, Can-Bus, Profinet. Allerdings beschränkte sich das ganze bisher in soweit, dass ich z.B. Profibuskompatible Baugruppen (Siemens S7, Phoenix SPS, Servosteuerungen,...) miteinander verband, das Netzwerk einrichte und das gesammte zum Laufen brachte. Die Auswahl des Systems entfällt da in den meisten Fällen, da dies vom Konzern vorgegeben wird. Auch leichte Programmierefahrungen für AVRs habe ich bereits (Es beschränkt sich nicht nur auf die Theorie) Nun bin ich halt da angekommen mich mit der Kommunikation mehreren AVRs / uCs zu beschäftigen. Ich möchte keine Auflistung von allen hunderten Systemen die es so gibt. Die gängigsten oder (wie drücke ich es aus ohne das es falsch rüber kommt) die am häufigsten verwendeten im AVR-Bereich reichen aus. Dazu gehören ja , wie ich hier lesen konnte, I²C, SPI, CAN, RS485,... Da weiss ich nun nicht ob ich welche übersehen habe oder ob dies nun alle sind. Sollte ich noch welche nicht kennen werde ich mich darüber dann auch informieren und mich (auch praktisch) einarbeiten um später "wenn ich dann eine größere Anwendung aufbaue" besser entscheiden zu können welches System am besten geeignet ist. Ich möchte nur kurze Infos was es da denn alles gibt oder ob ich mit den weiter oben beschriebenen Systemen/Protokollen alle Bereiche abdecken könnte. Es kann hier ja auch keiner Entscheiden was ich jetzt brauche, da es noch keine Anwendung gibt in der ich mich auf ein System festlegen muss. Gruß
:
Bearbeitet durch User
Patrick schrieb: > Schau mal auf Bus - dort gibt es einen Link zu > http://www.maximintegrated.com/app-notes/index.mvp/id/3438 - und auf > Hausbus. Oh hab deinen Beitrag scheinbar anfänglich übersehen. Der zweite Link ist in etwa das was ich gesucht hatte. Vielen Dank ;-) Gruß
Nunja, du hast am AVR Typischerweise 4 Bussysteme: Den Parallelen Bus, da der aber zu viele Recourcen (Pins) Verschlingt lassen wir den ma aussen vor. dann hast du den gebräuchlichsten: UART. den kann man mit Trancievern leicht zu RS232 oder RS485 wandeln. Dann ist der I²C Vorhanden, welcher bei Atmel aus Lizenzrechtlichen Gründen TWI heisst. Außerdem hast du einen recht schnellen Bus mit dem SPI an nahezu jedem Controller. Der am einfachsten nutzbare ist der UART. Der ist wie der I²C ein 2(+1) Draht bus. Aber er ist per se bidirektional, I²C hat eine starre Master Slave Struktur. Multi-Master gibt es zwar auch, ist aber nicht mehr soo trivial. Vorteil I²C: Ich kann bis zu 127 Devices an einen Strang hängen, es gibt viele Sachen schon fertig (Vor allem Sensorik) Nachteil: Wenn ein Teilnehmer aussteigt kann das das gesamte System ausschalten. Der uart ist per se ein 2 Teilnehmer Bus. Mittels RS485 Transcievern kann man den aber auch auf viele Devices erweitern. das ist also ein weites Feld wie du siehst. Da kann man Problemlos Stundenlang philosophieren.
Da er sich in uCs einarbeitet und nach Bussystemen vom AVR fragte, denke ich er meint die built-in-Module wie: SPI, I2C/TWI, I2S, UART, CAN, LIN und USB. USB ist primär ja zur Kommunikation mit dem PC, SPI/I2C/I2S für Kommunikation zwischen 2+ Bauteilen auf der selben Platine und UART, CAN, LIN für alles, wo man mehr oder weniger lange Strecken per Kabel zurück legen muss. Meines wissens kann man im Allgemeinen SPI schneller als I2C betreiben (I2S ist ja speziell für Audio), doch das wars ansich schon, was ich so weiß. Sprich, wenn ich die freie Auswahl habe, würde ich eher I2C nehmen, da nur 2 Leitungen und durch die Adressierung braucht man auch keine /CS Leitungen. Daher, speziell für die "Langstreckenbusse", würde mich die Antwort auch mal interessieren. Ich glaube, das CAN mehr als 2 "Geräte" miteinander verbinden kann, wohingegen das UART nicht kann. Aber was kann CAN anders als LIN?
Ah sehr gut, Das ist schonmal ein wenig Stoff mit dem ich mich jetzt beschäftigen kann. Vielen Dank soweit. Ich werde mich jetzt von Zeit zu Zeit in die Systeme einarbeiten und eventuell mal eine kleine Übersicht gestalten, die ich dann hier zur Verfügung stellen würde. (Nur insofern Interesse besteht) Was sind denn eure persönlichen Erfahrungen in den oben genannten Systemen, welche bevorzugt ihr für welche Art von Anwendung? Gruß
Für den Anfang würde ich mich im Hobbybereich an die Standardbusse je nach Aufgabe halten: µC zu PC: USB, RS232 µC zu Sensor = I2C, SPI µC zu µC = CAN, RS232 oder RS485
Michael Skropski schrieb: > Aber was kann CAN anders als LIN? - Höhere Datenrate - Arbitrierung (d.h. Kollisionsvermeidung) ist bereits auf dem physical layer abgedeckt. Anders gesagt: der Bus sorgt selbst dafür, dass sich die Frames nicht in die Quere kommen. Bei LIN musst du dich selbst darum kümmern. - Differentielle Übertragung, dadurch deutlich geringere Störungen Max
Ah. Ok. Ich hab bisher eher Kommunikation auf der selben Platine benutzt. Da stelle ich mir auch oft die Frage, ob ich z.B. einen DAC, dem ich ca 10 mal die Sekunde neue Werte schicke, mit SPI oder I2C nehmen sollte (sofern andere Ansprüche bedient wurden). Es wird weder ein Multimastersystem, noch wird eine hohe Datenbandbreite gebraucht. Mir ist I2C irgendwie sympathischer, aber ich hab den Eindruck, dass SPI verbreiteter ist.
:
Bearbeitet durch User
SPI ist einfacher, braucht aber mehr Leitungen. Vergleiche Master + 4 Slaves, bidirektionale Übertragung. SPI: MOSI,MISO,SCK, CS1-4 = 7 Portpins I²C: 2 Portpins Aber I²C ist halt etwas komplexer mit Adressierung, Start/Stop Bedingung usw. gruß cyblord
Max G. schrieb: > Michael Skropski schrieb: >> Aber was kann CAN anders als LIN? > - Höhere Datenrate > - Arbitrierung (d.h. Kollisionsvermeidung) ist bereits auf dem physical > layer abgedeckt. Anders gesagt: der Bus sorgt selbst dafür, dass sich > die Frames nicht in die Quere kommen. Bei LIN musst du dich selbst darum > kümmern. > - Differentielle Übertragung, dadurch deutlich geringere Störungen > > Max So als Verständnisfrage: Wie genau sorgt denn der BUS für die Kollisionsvermeidung. Das müsste doch auch über eine Art von Handshake funktionieren oder denke ich da in die falsche Richtung? Gruß
Christian O. schrieb: > Wie genau sorgt denn der BUS für die Kollisionsvermeidung. Das müsste > doch auch über eine Art von Handshake funktionieren oder denke ich da in > die falsche Richtung? http://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Detection
Jedes Bussystem hat seine Vor- und Nachteile, so dass man für eine bestimmte Aufgabe das bestmögliche Bussystem auswählen sollte. Meisten ist man allerdings dadurch beschränkt, welche Bussysteme für diese Anwendung in dieser Situation zu Verfügung stehen. Prinzipiell stehen immer alle zur Verfügung, allerdings sollte Aufwand und Nutzen in einem guten Verhältnis stehen. Man kann nicht z.B. generell sagen, dass I2C besser ist als SPI. Das hängt von der Aufgabe und den Randbedingungen ab. Solche Randbedingungen sind z.B. Datenübertragungsrate, Anzahl der verwendbaren Pins, Stromverbrauch, Übertragungssicherheit, Datenübertragungsmedium, Datenübertragungsstrecke, Single-Master oder Multimaster, Menge der zu übertragenden Informationen, Fehlerrate und vieles mehr. Viele Leute verwenden lieber einen Zweidrahtbus (I2C) als einen Vierdrahtbus, weil sie dadurch Pins sparen. Ich frage an dieser Stelle immer, wofür sie diese Pins sparen. Man bekommt nicht anteilig sein Geld für ein MC oder ein anderes Gerät wieder, wenn man einige Funktionen nicht verwendet. Hier einige Beispiele: Ich persönlich finde I2C eine der größten Kathastropen, die es bei Bussystemen gibt. Ein Netzwerk mit zwei oder drei Teilnehmern geht richtig gut, aber ein Netzwerk mit acht oder mehr Teilnehmern funktioniert sehr schlecht, wenn die acht ICs von verschiedenen Herstellern sind, da die Spec für I2C etwas schwammig geschrieben ist. SPI verbraucht eine Menge Pins, wenn man viele Teilnehmer hat, aber auch dafür gibt es geschickte Lösungen. CAN ist nicht in jedem Controller verfügbar und setzt eine genaue und stabile Taktfrequenz voraus. UART hat eine niedrige Übertragungsrate und braucht einen genauen und stabilen Takt. Außerdem können nur zwei Teilnehmer miteinander sprechen, aber auch dafür gibt es Lösungen. UART ist auch heute noch genau das richtige für viele Anwendungen. Es gibt noch viele weiter Beispiele. Einige davon werden dir vielleicht begegnen.
kaplic schrieb: > UART hat eine niedrige Übertragungsrate und braucht einen genauen und > stabilen Takt. Außerdem können nur zwei Teilnehmer miteinander sprechen, > aber auch dafür gibt es Lösungen. Mit UARTs ist das wie mit Beton - es kommt drauf an, was man draus macht. UART hat mit Bus-System nicht viel zu tun und ist mit nichten auf zwei Teilnehmer begrenzt. Ein Bus wird daraus erst mit passenden Treibern. RS485 z.B. wird vom µC-UART mit Daten versorgt. Dort dürfen IMHO bis zu 32 Teilnehmer auf dem Bus hängen.
Beitrag #5068000 wurde von einem Moderator gelöscht.
Beitrag #5068010 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.