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...?
>Warum setzt sich nicht eine davon gegenüber allen anderen durch?
Weil jede für einen anderen Anwendungsfall ist.
Und CAN geht durchaus auch mal ein paar Meter weiter;)
Jedes der genannten Protokolle hat andere Vorteile und Nachteile. Man wählt nach Anwendungsfall. Die vor- und Nachteile der Varianten kannst du z.B. bei Wikipedia nachlesen.
BUS schrieb: > sagt mal, I2C, SPI, UART, USB, CAN sind doch alles irgendwie > Nahstrecken-Kommunikations-BUS-Verbindungen. Es gibt verschiedene Arten von Hämmern, http://selbermachen.de/werkzeuge/drinnen/handwerkzeuge/hammer-arten-im-ueberblick-formen-und-einsatzgebiete warum setzt sich da nicht einer durch?
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.
BUS schrieb: > sagt mal, I2C, SPI, UART, USB, CAN sind doch alles irgendwie > Nahstrecken-Kommunikations-BUS-Verbindungen. Es gibt ja auch noch eine Welt neben dem genannten. z.B. TokenRing Ist nicht wirklich "Bus", aber hat auch so seine speziellen Vor- und Nachteile. Und lässt sich recht einfach mit Hilfe einer UART abhandeln.
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.
:
Bearbeitet durch User
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.
BUS schrieb: > sagt mal, I2C, SPI, UART, USB, CAN sind doch alles irgendwie > Nahstrecken-Kommunikations-BUS-Verbindungen. Der Haken ist nur, dass jedes dieser Bussystem unter Nahstrecke etwas anderes versteht. Für USB ist bei 5 m, spätestens bei 15 m Ende der Fahnenstange, CAN mit 10 kBit/s kann durchaus mal 5km weit reichen. Und was hat UART eigentlich mit Bus zu tun? Das ist ein Schnittstellenbaustein, der sich um das Senden und Empfangen von asynchronen, seriellen Daten kümmer und dem ist das ziemlich egal, ob da RS485 auf 1200m oder sonstwas mit gemacht wird. Was verstehst du unter Nahstrecken-Kommunikation?
A. K. schrieb: > Token Passing Und ich dachte immer der heißt "Toten Ring" :-) - wie dumm von mir :-)
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.
> Im PC Bereich hat sich Ethernet durchgesetzt
Sicher? Also mein Laptop kommuniziert täglich über WiFi, Bluetooth,
433Mhz (Maus), USB und I2C. Möglicherweise ist auch SPI dabei.
Ethernet nutze ich nur, wenn Wifi nicht funktioniert. Ok Wifi ist eine
Variante von Ethernet. Aber worauf ich hinaus wollte ist, dass Ethernet
noch lange nicht die einzige gängige Schnittstelle am PC ist.
Was ich gelten lassen würde ist, dass sich Ethernet gegenüber Token Ring
durchgesetzt hat.
Eventuell könnte man auch sagen, dass sich Ethernet für die
Kommunikation zwischen PC's durchgesetzt hat. Aber da interessiert dann
eher das darüber liegende Protokoll (z.B. IP). Jeder, der einen Internet
Anschluss nutzt, fährt IP über eine völlig andere Leitung als Ethernet.
Wenn man mal die Anzahl der Netzwerk-Teilnehmer berücksichtigt, könnte
man sogar Kackfrech sagen, dass DSL sich gegenüber Ethernet durchgesetzt
habe.
Stefan U. schrieb: > Also mein Laptop kommuniziert täglich über WiFi, Bluetooth, > 433Mhz (Maus), USB und I2C. Möglicherweise ist auch SPI dabei. Wobei das meiste davon Point-to-Point-Verbindungen sind. Als BUS verstehe ich Leitungen, an denen parallel mehrere Teilnehmer hängen. Das ist in deinen Beispielen eigentlich nur bei I²C und SPI der Fall.
Ergänzung: Auch Ethernet (RJ45) ist nur Punkt zu Punkt. LAN über Koax war ein Bus. Da waren mehrere Rechner am gleichen Koax angeschlossen (über T-Stücke).
Tja, dafür gibt es gute Gründe: 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. Beispielhafte Anwendung: Verbindung von Platinen untereinander. SPI: Synchron, sehr schnell. Sehr empfindlich auf Verzögerungen und daher nur für kurze Strecken geeignet. Full Duplex. Hohe Datenrate (z.B. 100kBd - 100MBd) Ein Bus, aber pro Gerät ein Chipselect. Relativ simpel, aber jedes Gerät braucht ein Chipselect. Anwendung: Anbindung schneller Peripherie wie ADC oder Speicher. I2C: Synchron, eher langsam, man kann aber viele Geräte zusammenhängen mit wenig Aufwand. Ist ein Bus mit Adressen. 100kBd bis 1MBd, aber nur half duplex. Recht störempfindlich, weil kein aktiver High-Pegel, empfindlch auf Kapazitäten. Elektrisch billig und simpel. Typische Andwendung: Anbinden von viel langsamer Peripherie an einen µC. Aber manchmal auch in Kabelgebundener Peripherie wie Tastaturen oder in HDMI enthalten. Also wir I2C niemals die UART und erst recht nicht die SPI ersetzen, weil zu langsam. SPI nie UART und I2C, wegen Aufwand und Reichweite. UART niemals I2C und die SPI weil nur Punkt zu Punkt. Nur Beispiele - es gibt mehr Gründe als nur das. Geh einfach davon aus: Wenn sich jemand Gedenken macht und einen neuen Bus erfindet, hat er meistens einen Grund dafür ;-)
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.
Peter D. schrieb: > Nö, I2C ist erheblich unempfindlicher als SPI. Das hängt davon ab. Von vielen Faktoren: - Geschwindigkeit - Aufbau von Master und Slave Jeder macht so seine eigenen Erfahrungen. Meine, und die der Kollegen ist die, dass I2C schon öfter Probleme gemacht hat als die SPI. Fakt ist folgendes: Der HIGH-Zustand bei einer SPI ist recht niederohmig (z.B. 50Ohm), weil es eine Push-Pull-Stufe ist. Da zieht ein Transistor gegen VCC. Der High-Zustand bei I2C ist hochohmig, da ist nur ein Widerstand drin. Entsprechend lässt sich dieser durch externe Quellen (kapazitive Kopplung zum Beispiel) leichter beeinflussen. Und I2C passt nicht seine Datenrate an. Wie kommst du denn auf dieses dünne Brett? Ich habe bereits mehrere I2C-Master Implementierungen hinter mir (z.B. PIC, auch bei STM32 kenne ich das im Detail) und keiner der Controller passt seine Datenrate an. Die muss der Programmierer angeben ;-) Mit 100n wird das nicht klappen, denn das ergibt mit 1k Pullup eine Zeitkonstante von 100µs. Bei einer Taktfrequenz von 100kHz KANN dar gar nicht mehr zuverlässig funktionieren, denn der Takt ist nur High für 5µs.
F. F. schrieb: > Na ja, ganz so ist es ja nicht. Im PC Bereich hat sich Ethernet > durchgesetzt Naja. > und im gesamten Fahrzeugbereich ist CAN weit vorne. > Vielleicht gibt es ja irgendwann mal Ethernet_embedded? Wer weiß das > schon? Hust, Ethernet ist längst im Embedded Bereich angekommen und gerade auf dem Sprung groß im Auto einzusteigen als Automotive Ethernet oder auch 100Base-T1. Das wird nur CAN so schnell nicht ersetzen, es werden die Datenraten kaum irgendwo benötigt, Ethernet ist nur Punkt-zu-Punkt, man braucht dickere Controller dafür, der Aufwand auf der Leiterplatte ist größer. Der Hype ist gefühlt viel größer als die Realität hergibt.
Bei uns (Bremen) fährt grad keiner. 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. Sorry, fürs OT.
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.
:
Bearbeitet durch User
Peter D. schrieb: > 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. Stimmt, da hast du recht! Danke für die Korrektur! Man sollte die SPEC auch mal WIRKLICH lesen, und nicht nur solange implementieren bis es läuft :-)
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.
:
Bearbeitet durch User
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
> Hast Du denn wenigstens einen BNC-Anschluß dafür?
BNC ist von gestern - USB 3.0 oder HDMI muss es sein :-)
Ich habe noch einen altmodischen Stecker mit Schraubverschluss im Nacken, wie bei der Matrix.
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.
holger schrieb: > Und CAN geht durchaus auch mal ein paar Meter weiter;) USB auch, aber ich halte es da mit der weisen Lebensregel Nummer drei: https://tools.ietf.org/html/rfc1925
USB Typ C könnte bald, auch im µC-Bereich, diese Vereinheitlichung bringen.
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.
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. Nicht viel. Der softwareseitige Aufwand, allein schon um, verschiedene Busteilnehmer zu identifizieren ist enorm. Außerdem ist das Timing ohne Oszilloskop schwer zu kontrollieren. Von der Einordnung her liegt onewire m.E. in der Nähe von I2C. Für ein paar Temperatursensoren im Gehäuse ist es o.k. Für alles was über Stecker und Kabel geht, würde ich mir was anderes suchen. (Oder kenn jemand bidirektionale Optokoppler, um den ESD-Schutz zu gewährleisten?) Wolf
F. F. schrieb: > Welcher "Busfahrer", der sich gut mit allen Bussen auskennt, wäre denn > bereit mal ein Wiki aufzusetzen? Einen Anfang gibt es doch schon: https://www.mikrocontroller.net/articles/Bus
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
geil sind wieder die ersten 10 Antworten :-) Köstlich dieses Forum Da liest man die überschrift und denkt sich, ah eine interessante Diskussion über die Vor und Nachteile verschiedener Bussysteme..aber wie in diesem Forum üblich nur dämliche Antworten.. Alles hat vor und Nachteile, benutz Google, lies doch nach etc bb Ist schon wieder Freitag bla bla bla Zu geil!!
ach aj und das obligatorische "Mit Sicherheit eine Schulaufgabe :-)" zum Kringeln
So einen minimal Bus für die ganz kleinen Tinys (ATTiny10), ähnlich OW, das wäre was. Hat so was schon jemand geschrieben?
F. F. schrieb: > Na ja, ganz so ist es ja nicht. Im PC Bereich hat sich Ethernet > durchgesetzt und im gesamten Fahrzeugbereich ist CAN weit vorne. Im PC-Bereich hat sich vieles durchgesetzt, wo Daten übertragen werden: PCI, Bluetooth, Ethernet, SPI, I2C, USB, RS232, ... Da ist Ethernet nur ein Baustein. Genauso sieht es im Fahrzeugbereich aus: CAN, FlexRay, LIN, TTCAN, SPI, I2C, MOST, Ethernet, ... Auch hier ist CAN nur ein Baustein. Sowohl im Fahrzeugbereich als auch im PC-Bereich kommt es drauf an, wo und wie tief man hineinschaut. Für viele Anwendungen ist weder eine wahnsinnig hohe Übertragungsrate noch eine absolut sichere Datenübertragung noch Echtzeitfähigkeit in irgend einer Form wichtig. Man wählt den Bus, der ausreichend ist, sowohl im Bereich der Datenübertragung, als auch im Preis sowie im Implementierungsaufwand. n0a schrieb: > USB Typ C könnte bald, auch im µC-Bereich, diese Vereinheitlichung > bringen. Mit Sicherheit nicht! Es handelt sich lediglich um ein Steckertyp. Und USB wird sich niemals allgemein gegenüber anderen Bussen durchsetzen: viel zu kompliziert, viel zu hoher Aufwand, viel zu teuer. Sowas nimmt man nur, wenn man es wirklich braucht. Ansonsten gibt es 1000 andere Möglichkeiten, die ausreichend sind. Und in Großserie wird niemand etwas einbauen, was er nicht braucht aber bezahlen muss.
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. ;-)
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.