Es gibt CAN mit fertigen Bauteilen u. Bibliotheken. RS485 ist ohne Protokoll; SPI u. I²C/TWI nicht wirklich Multimaster und auch nur für kurze Leitungslängen; 1-Wire nur Master/Slave; UART ist nur Schnittstelle; und sonst? Was gibt es für Multimaster-Bussen im Einsatz für µC ohne all zu exotisch zu werden? Ich habe sonst nur PJON (Padded Jittering Operative Network) gefunden. https://github.com/gioblu/PJON Was meint ihr dazu? Und sonst? Ist CAN mehr oder weniger das einzige?
Warum ist 485 ohne Protokoll? Das muss man da halt selber programmieren.
Manfred H. schrieb: > I²C/TWI nicht wirklich Multimaster Wenns richtig implementiert ist, ist auch I²C ein Multimaster. > auch nur für kurze Leitungslängen das ist wahr.
Manfred H. schrieb: > Was gibt es für Multimaster-Bussen im Einsatz für µC ohne all zu > exotisch zu werden? CAN Manfred H. schrieb: > ... I²C/TWI ... und auch nur für kurze Leitungslängen; Stimmt, bei hundert Metern ist deutlich Schluss, so NXP. http://www.nxp.com/documents/application_note/AN10658.pdf
Poster schrieb: > Warum ist 485 ohne Protokoll? > Das muss man da halt selber programmieren. Ja, eben... Wenn's nicht sein muss und was fertiges gibt... Ist nicht so einfach, sich um Kollision, Übertragungsfehler, etc. selbst zu kümmern.
Manfred H. schrieb: > Ja, eben... Wenn's nicht sein muss und was fertiges gibt... Ist nicht so > einfach, sich um Kollision, Übertragungsfehler, etc. selbst zu kümmern. Naja, man muss ja nicht alles selbst neu erfinden. Du kannst RS485 nehmen und darüber IP-Pakete senden. TCP kümmert sich dann um Prüfsumme und Paketverluste. Normal lauschen die Stationen bevor sie anfangen zu senden. Wenn 2 Stationen wirklich gleichzeitig anfangen zu senden gibts ne Kollision, darum kümmert sich dann auch das TCP.
Manfred H. schrieb: > Was gibt es für Multimaster-Bussen im Einsatz für µC ohne all zu > exotisch zu werden? Exotisch in Bezug auf Reichweite, Datenübertragungsrate oder was meinst du?
Man kann mit zB 485 auch Multimaster betreiben ohne Kollisionen, dann muss man eben ein Token (Fähnchen) umgehen lassen. Welche Station auch immer das Token hat, darf senden. Nachher geht das Token an den naechsten weiter. Zu loesenden Probleme : Wie kommen neue Stationen ans Netzwerk & was geschieht wenn das Token verloren geht, dh Regeneration eines Tokens, wenn zB die Station mit dem Token abgeschaltet, ausgezogen wird. Ist aber machbar. Die Performance eines Token Netzwerkes ist bei hoeherer Buslast besser wie die Performance eine kollisionsbasierten Netzwerkes. Dh ein Tokennetzwerk kann bis fast 100% ausgelastet werden. Ethernet war damals die schlechtere Wahl gegenueber den Tokennetzwerken. Das jetzige Ethernet ist ja ein Punkt-zu-Punkt Netzwerk und hat diese Nachteile korrigiert.
:
Bearbeitet durch User
CAN ohne ein darüber gelegtes Protokoll ist auch nicht sicher, was die Sicherheit der Datenübertragung angeht. Im Prinzip ist es nur Broadcast. Ich halte die Frage des TO für wenig durchdacht. DEN Multimaster Bus gibt es nicht. Es wäre hilfreich, wenn die Randbedingungen genannt würden.
Manfred H. schrieb: > Was gibt es für Multimaster-Bussen im Einsatz für µC ohne all zu > exotisch zu werden? Profibus, wenn man mit der Baudrate auf dem Teppich bleibt.
>RS485 ist ohne Protokoll; SPI u. I²C/TWI nicht wirklich Multimaster und >auch nur für kurze Leitungslängen; SPI ist sozusagen auch ohne Protokoll. Man kann auf jegliche Arten Multimaster implementieren.
Gerd E. schrieb: > Du kannst RS485 nehmen und darüber IP-Pakete senden. TCP kümmert sich > dann um Prüfsumme und Paketverluste. > > Normal lauschen die Stationen bevor sie anfangen zu senden. Wenn 2 > Stationen wirklich gleichzeitig anfangen zu senden gibts ne Kollision, > darum kümmert sich dann auch das TCP. Ich glaube nicht, daß TCP mit Kollisionen vernünftig umgeht. Wenn zwei Teilnehmer gleichzeitig ein Datenpaket senden, wird bei beiden TCP irgendwann merken, daß die Daten nicht angekommen sind, und das Paket wiederholen. Und zwar bei beiden gleichzeitig; die nächste Kollision ist also garantiert. Was bei RS-485 fehlt, ist eine explizite Kollisionserkennung. Die Hardware leistet das einfach nicht (im Gegensatz zu z.B. Ethernet, CAN, ISDN-S0, etc.). Die beiden beteiligten Sender merken nichts von der Kollision und können daher nicht vernünftig reagieren. Man muß also bei RS-485 das Senderecht immer ausdrücklich vergeben, z.B. durch ein Master-Slave-Protokoll oder Token-Ring.
Das Kollisionsrecovery funktioniert anders bei den Bussen, die das koennen. Wenn eine Kollision erkannt wird, zB bei 10base2 Ethernet, warten beide Stationen eine Zufallszeit ab, bevor sie es nochmals probieren. Deswegen kann man auch die Sendezeit nicht vollaufbrauchen. Tokenring ist uebrigens was anderes. Der wurde damls von IBM entwickelt, und da durch Patente geschuetzt, zu proprietaer, zu teuer. Da waren alle Stationen als ring angeschlossen. Es waren 4 Leitungen, die pro modul anzuschliessen waren. Zwei eingaenge, zwei ausgaenge. Der eine Ring ging links rum, der andere Ring rechts herum, jeweils als Sender/Empfaenger Paar. Jede Station kannte den Nachbarn. Wenn eine Meldung nicht quitiert wurde, wurde angenommen, dass diese Richtung unterbrochen war, und die Meldung nochmals in die andere Richtung geschickt. Ein Hardware tokenbus war das Arcnet. Hatte leider nur 5MBit waehrend Ethernet als 10Base2 schon 10MBit konnte. Unter Last war er aber besser. Die 5MBit konnten ausgenutzt werden. Pech gehabt, Marketing Bla-Bla.
:
Bearbeitet durch User
Ich finde CAN unschlagbar einfach, da fast alles die Hardware macht: - Nachricht in Sendepuffer stellen, Interrupt: Nachricht wurde erfolgreich gesendet. - Empfangsinterrupt: Nachricht aus Empfangspuffer lesen. Man muß nur noch die höheren Protokollschichten in SW implementieren.
>Wenn eine Kollision erkannt wird, zB bei 10base2 Ethernet, >warten beide Stationen eine Zufallszeit ab, bevor sie es nochmals >probieren. Deswegen kann man auch die Sendezeit nicht vollaufbrauchen. Das ist so ziemlich das schlechteste, was man hinsichtl. MultiMaster machen kann. Bei CAN ist die Geschwindigkeit, wegen der Arbitrierung, sehr von der benutzten Bus-Reichweite abhängig.
CAN ist eher fuer die Autoindustrie, optimiert fuer schnelle kurze Packete. 6 byte maximum. Einen Filetransfer moechte man eher nicht darueber machen. Auch keinen Videostream.
Die Firma Phytec hatte mal einen Multimaster-Bus im Angebot. Das Prinzip wurde in der (ich glaube) ELRAD beschrieben. Basierte auf RS485 Treibern, mit Kollisionserkennung, und Vermeidung (CSMA/CD), mit Prioritätensteuerung, Point to Point oder Broadcast. Buszugriff mit RS485-Pegeln und Arbitrierung über dominante/rezessive Pegelsteuerung. Viele Eigenschaften des CAN sind so auf einfacher UART-Technik realisiert worden. Damals noch 8051 aber bei allen Familien mit Multiprozessorcommunikationsbit (9. Datenbit) realisierbar. Wird wohl nicht mehr angeboten, nannte sich "µNET".
Oh D. schrieb: > CAN ist eher fuer die Autoindustrie, optimiert fuer schnelle kurze > Packete. 6 byte maximum. Einen Filetransfer moechte man eher nicht > darueber machen. Auch keinen Videostream. Und so bleibt die Frage: Was möchte der TO?
Danke für die vielen Antworten! Thomas W. schrieb: > Und so bleibt die Frage: Was möchte der TO? Mit möglichst wenig SW-Aufwand 3-20 AVR's über 50-200m verteilt in einer Art Hausautomatisierung alle paar Zehntel-Sekunden bis Minuten kurze Nachrichten austauschen. Da scheint CAN wohl am geeignetsten zu sein.
Bei den ganzen Begriffen (CAN, I²C/TWI, UART, RS485, usw.) bringst du einiges durcheinander. So kann man das nicht vergleichen. Zuerst solltest du die Schicht im OSI-Schichten-Modell klären. Befinden wir uns auf der physikalischen Ebene, auf der logischen Ebene usw. Dann fällt es auch leichter die Bussysteme miteinader zu vergleichen. Möglicherweise solltest du vorher den Begriff Protokoll in Verbindung mit dem Begriff Bussystem klären. Mir fallen bei Multi-Master-Bussystemen ein: CAN, VME, I²C, Profibus, Avalon Bus, PCI, LON, SafetyBUS p, RS485, ... Ein Multi-Master-System ist nur in den seltensten Fällen notwendig und es erleichtert die Kommunikation meistens nicht. Der Weg der Botschaften wird mit zunehmender Anzahl an Teilnehmern immer unübersichtlicher und weniger nachvollziehbar. Das macht die Fehlersuche nicht einfacher. Für deine Anwendung kann CAN sehr gut sein. CAN bringt auf jeden Fall eine Menge Overhead mit, ist aber dafür sehr störunanfällig. Beachten solltest du die Leitungslänge zusammen mit der Übertragungsrate (1Mbit/s geht nur bis 40m). Der CAN-Bus ist schon eine ganz ausgefuchste Sache mit all seinen Mechanismen (CSMA/CR, Arbitrierung, Identifier, Acknowledge, Bit-Stuffing usw.) Benutze den CAN-Bus in deinem Projekt. Das ist sehr interessant und da kannst du ordentlich was dazulernen.
Manfred H. schrieb: > ... über 50-200m verteilt .... > Da scheint CAN wohl am geeignetsten zu sein. Das setzt voraus, dass du mit den Einschränkungen für die Topologie eines CAN-Bus zurecht kommst.
Oh D. schrieb: > CAN ist eher fuer die Autoindustrie, optimiert fuer schnelle kurze > Packete. 6 byte maximum. Es sind 8. Und mit CAN-FD sind es 64. Als weiteres Buzzword für die Runde fällt mir noch Flexray ein. Edit: Hab die Anforderung überlesen, dazu passt Flexray dann eher nicht, nein.
:
Bearbeitet durch User
Hallo, ich frage mich immer wieder, warum die Leute immer auf die Idee kommen, einen Multimaster fähigen Bus verwenden zu müssen. Der TO will eine popelige Haussteuerung erstellen. Redet von geringem SW Aufwand und will dann einen Multimaster Bus einsetzen. Da hat er sich mit Kollisionen, Prioritäten, Timings, Adressarbitrierung und ,und ,und herumzuschlagen. Ein simpler UART basiertes Master-Slave Bus ist da um Größenordnungen einfacher und schneller erstellt. Und natürlich RS485 basiert. Wer sich einmal mit einem Multimaster Bus herumgeschlagen hat, der erkennt die Vorteile eines Master-Slave Systems. Also Manfred, lass die Idee von Multimaster sein und all ihr anderen spart euch die Energie darüber zu grübeln. Gruß gatsby
gatsby schrieb: > Da hat er sich > mit Kollisionen, Prioritäten, Timings, Adressarbitrierung und ,und ,und > herumzuschlagen. Schon mal was mit CAN gemacht? Multimaster ohne eines der o.g. Probleme. Ich benutze CAN bei mir als Hausbus seit > 10 Jahren ohne Probleme oder Ausfälle. Meine Baudrate ist 20kbaud. Damit sind auch lange Stichleitungen problemlos möglich. Ich finde CAN für die Anwendung des TO die ideale Lösung. Gruß, Stefan
Nosnibor schrieb: > Was bei RS-485 fehlt, ist eine explizite Kollisionserkennung. Die > Hardware leistet das einfach nicht Lass den Receiver immer an und schau nach was der Transmitter raushaut. Wenn RX != TX dann Kollision. Denn Rest macht CRC + Retransmission. Das alles mußt Du natürlich selber schreiben. Multimaster ist in den meisten Fällen nur Multi-Problem. Anstatt da selber drin herumzustochern verwende einen klassischen Master / Slave Bus oder lass dir die meiste Arbeit von z.B. CAN abnehmen.
Stefan K. schrieb: > gatsby schrieb: >> Da hat er sich >> mit Kollisionen, Prioritäten, Timings, Adressarbitrierung und ,und ,und >> herumzuschlagen. > > Schon mal was mit CAN gemacht? Multimaster ohne eines der o.g. Probleme. Kann ich nur bestätigen. Wer einmal CAN benutzt hat, möchte nie nie nie wieder das umständliche RS-485 haben. CAN ist codesparend und sorgenfrei.
Das Einzige, was mich bei CAN aufregt, ist der Name. Schon einmal nach CAN gegoogelt? ;-) Stefan
Manfred H. schrieb: > Mit möglichst wenig SW-Aufwand 3-20 AVR's über 50-200m verteilt in einer > Art Hausautomatisierung alle paar Zehntel-Sekunden bis Minuten kurze > Nachrichten austauschen. WLan mit ESP8266, billiger gehts nicht (< 2€ pro Knoten, Kabelkosten 0). Und dann jedes Protokoll, was man gut kann, HTML zum Beispiel oder UDP Broadcasts. Und alle PCs im Haus sind auch noch for free angeschlossen. MfG Klaus
Michael K. schrieb: > Lass den Receiver immer an und schau nach was der Transmitter raushaut. > Wenn RX != TX dann Kollision. Denn Rest macht CRC + Retransmission. Im Gegensatz zu anderen Bussen (Open Collector + Pullup o.ä.) ist das aber ein echter Kurzschluss von Sendern, garnicht gut für die Chips und technischer Totalmurks. Georg
Georg schrieb: > aber ein echter Kurzschluss von Sendern, garnicht gut für die Chips und > technischer Totalmurks. Kurzschluss ? Einen Empfänger auf Enable belassen ? Mit RS485 hast Du Dich mal länger als 20sek beschäftigt ? Kollision ist dort ein normaler Vorgang und die Treiber sind explizit dafür geeignet wie übrigens bei CAN auch. Georg schrieb: > technischen Totalmurks ...
Da gibt's jede Menge: Arcnet tokennet jedes System das CSMA implementiert
Georg schrieb: > technischer Totalmurks Aus Wikipedia: Gegenüber dem EIA-422-Standard besitzen die Sender durch einen integrierten Widerstand kurzschlussfeste Ausgangsstufen, so dass auch ein Gegensenden zweier Sender nicht zu Defekten führt.
>WLan mit ESP8266, billiger gehts nicht ... Funk ist unzuverlässig. >Im Gegensatz zu anderen Bussen (Open Collector + Pullup o.ä.) ist das >aber ein echter Kurzschluss von Sendern, garnicht gut für die Chips und >technischer Totalmurks. ja mit std. RS485 usw., wenn man will, kann man sich ja mit CAN-Transceivern ein eigenes System stricken.
Die RS-485 Treiber können sehr hohe Ströme liefern, das kann bis zum thermal Shutdown führen. Z.B. der MAX485 kann bis 250mA, da braucht man schon ein ausreichend starkes Netzteil, wenn dem MC nicht der Saft ausgehen soll. Beim CAN gibt es keine Kollision, es gewinnt immer der dominante Pegel. Daher können auch 2 Teilnehmer gleichzeitig senden. Blöd wirds nur, wenn 2 den gleichen ID senden, da dann beide denken, sie haben gewonnen. Das muß daher vermieden werden. Die CAN-Transceiver können auch hohe Spannungen ab, z.B. der TJA1050 -27..+40V. Man darf also versehentlich die 24V Versorgung an die Datenpins geben, ohne daß er die Hufe hochreißt.
Michael K. schrieb: > Lass den Receiver immer an und schau nach was der Transmitter raushaut. > Wenn RX != TX dann Kollision. Denn Rest macht CRC + Retransmission. Die Hardware garantiert mir aber nicht, daß ich eine Kollision sauber erkenne. Im Zweifelsfall ist immer mein eigener Sender näher (=niederohmiger) an meinem Empfänger als jeder andere, der gleichzeitig etwas anderes sendet. RX!=TX wird also meist nicht eintreten; die Kollision bleibt (von einem der beteiligten Sender) unbemerkt. Andere Systeme (z.B. CAN oder ISDN) garantieren, daß bei einer Kollision ein bestimmter Pegel "gewinnt", so daß damit auch gleich die Priorität geregelt ist. Das funktioniert aber auch nur, weil ein gemeinsamer Bittakt gegeben ist; RS-485 ist vollkommen asynchron, so daß von einer Kollision vielleicht nur Teile eines Bits betroffen sind.
ja, mehrere RS-485 -Driver aufeinander los zu lassen ist eigentlich
nicht erlaubt (es gibt allerd welche mit Strombegrenz. oä).
Es wird aber wohl immer unsaubere Lösung bleiben, das so zu verschalten
(bzw das SWtechn zu erlauben)
>RS-485 ist vollkommen asynchron, ..
RS-485 ist genauso nicht 'asynchron' wie CAN oder Sonstige.
Wenn das Timing zu knapp ist, wird man auch mit CAN-Transc. die
Kollision nicht erkennen.
Kann man nicht auch X.25 oder AX.25 einsetzen auf RS485?
MCUA schrieb: >>WLan mit ESP8266, billiger gehts nicht ... > Funk ist unzuverlässig. Du hast deinen Laptop, dein iPad immer am Kabel? Kein Wlan zu Hause? MfG Klaus
Manfred H. schrieb: > Und sonst? Ist CAN mehr oder weniger das einzige? Wenn du von Hausautomatisierung sprichst, darf KNX nicht fehlen - das kann auch Multimaster. Zum Selberbau ist CAN aber sicher die beste Variante. Die korrekte Übertragung wird vom Sender bereits geprüft (durch das Acknowledge des Empfängers). Bezüglich Topologie brauchst du dir keinen großen Kopf machen. Was ich in der Automobilindustrie schon alles an Topologien gesehen habe, hat mit einem "korrekt terminierten Bus ohne Stichleitungen" so viel zu tun wie eine Kuh mit dem Fliegen. Die laufen auch. Musst halt irgendwo zwei Terminierungswiderstände unterbringen. Das gibt zwar böse Reflektionen, die sind aber nicht schlimm. Eine niedrige Datenrate reicht dir ja, CAN sampelt m.W. bei 80% der Bitlänge, d.h. bis dahin sollte deine Reflektion abgeklungen sein. KNX läuft mit 9,6 kBit/s, und das reicht locker. Bei diesem Tempo kannst du 80µs Reflektion der Signalflanke verdauen, da war das Signal dann schon rund 16km unterwegs. Das sollte zum Abklingen reichen. Max
wirewound schrieb: > Kann man nicht auch X.25 oder AX.25 einsetzen auf RS485? Kann man selbstverständlich. Quelltexte sind PD. Ist sogar Multimaster fähig. Der Aufwand für ein sauberes L2 Protokoll wird übrigens gern unterschätzt. MCUA schrieb: > mehrere RS-485 -Driver aufeinander los zu lassen ist eigentlich > nicht erlaubt Gilt die Aussage auch, wenn die Norm etwas anderes sagt und im Datenblatt des Transceivers ausdrücklich steht, dass Kollisionen nicht schaden?
>> mehrere RS-485 -Driver aufeinander los zu lassen ist eigentlich >> nicht erlaubt >Gilt die Aussage auch, wenn die Norm etwas anderes sagt und im >Datenblatt des Transceivers ausdrücklich steht, dass Kollisionen nicht >schaden? Was sagt denn die Norm, was man lesen soll, wenn von 2 verbundenen Treibern einer 0 der andere 1 schreibt?
MCUA schrieb: > Was sagt denn die Norm, was man lesen soll, wenn von 2 verbundenen > Treibern einer 0 der andere 1 schreibt? Das ist Sache des Layer 2 und nicht Aufgabe des Layer 1. Der Layer 1 kann "Fehler entdeckt" melden, muss er aber nicht. Und was gelesen wird ist auch irrelevant. Ist es zufällig der richtige Wert, prima. Ist es Müll, wird es vom L2 entdeckt und es wird ein erneuter Versuch angefordert. Das Netz ist voll mit Beispielen zu diesem Thema.
Wenn ein Sender 1 sendet und der andere 0, gibt es keinen "richtigen" Wert für den Empfänger. Bei RS-485 haben wir dann einen Zustand, wo im schlimmsten Fall jeder Empfänger andere Daten sieht. Das ist für die höheren Schichten ...ungünstig, um es höflich auszudrücken. Natürlich kann man das Problem auf die höheren Schichten abwälzen. "Bei einer Kollision passiert eben Mist, Fehlererkennung gibt es nicht, kommt gefälligst damit klar". Für mich als Entwickler der Schicht 2 und höher ist die logische Konsequenz, daß Kollisionen nicht Bestandteil des Protokolls sein dürfen, basta. Also keine multimaster-Fähigkeit bei RS-485.
Klaus schrieb: > Du hast deinen Laptop, dein iPad immer am Kabel? Kein Wlan zu Hause? wenn mein laptop mal kein wlan hat ist das ziemlich egal. wenn dagegen der Lichtschalter oder der Rauchmelder nicht klappt ist das schon eher doof... Max G. schrieb: > Die korrekte Übertragung wird vom Sender bereits geprüft > (durch das Acknowledge des Empfängers). Wichtig: irgendeines Empfängers. Wenn irgendjemand die Nachricht empfängt quittiert er sie, das heißt aber nicht, dass die Nachricht ihr Ziel erreicht.
> Lichtschalter oder der Rauchmelder
Rauchmelder am WLAN ... aaahhhh. Dann kannst du die Huette auch gleich
abfackeln.
Lichtschalter am WLAN ... aaaahhh. ein WLAN Knoten zieht sicher 1 Watt.
um einen Kontakt, der ausserordentlich selten betaetigt wird, zu
uebertragen ?
Nosnibor schrieb: > Wenn ein Sender 1 sendet und der andere 0, gibt es keinen "richtigen" > Wert für den Empfänger. Bei RS-485 haben wir dann einen Zustand, wo im > schlimmsten Fall jeder Empfänger andere Daten sieht. Das ist für die > höheren Schichten ...ungünstig, um es höflich auszudrücken. > > Natürlich kann man das Problem auf die höheren Schichten abwälzen. "Bei > einer Kollision passiert eben Mist, Fehlererkennung gibt es nicht, kommt > gefälligst damit klar". Für mich als Entwickler der Schicht 2 und höher > ist die logische Konsequenz, daß Kollisionen nicht Bestandteil des > Protokolls sein dürfen, basta. Also keine multimaster-Fähigkeit bei > RS-485. SAE J1708 arbeitet mit RS-485 und ist auch für Multimaster geeignet. Der "Trick" ist dort, dass bei den Transceivern DI immer auf Low ist und nur DE zum Senden verwandt wird: DE High -> dominant -> DE Low -> rezessiv, Rest erledigen externe Pullups etc. http://www.ti.com/lit/an/snla038b/snla038b.pdf http://ww1.microchip.com/downloads/en/AppNotes/01230A.pdf
Oh D. schrieb: > Lichtschalter oder der Rauchmelder > > Rauchmelder am WLAN ... aaahhhh. Dann kannst du die Huette auch gleich > abfackeln. > > Lichtschalter am WLAN ... aaaahhh. ein WLAN Knoten zieht sicher 1 Watt. > um einen Kontakt, der ausserordentlich selten betaetigt wird, zu > uebertragen ? Na das sage ich doch, WLAN ist ungeeignet. Das heißt aber nicht, dass WLAN schlecht ist, es ist halt nur nichts für diesen Zweck.
Nosnibor schrieb: > Kollisionen nicht Bestandteil des Protokolls Fehler können immer passieren,damit muss dein Programm klarkommen. Es gibt keine 100% sichere Übertragung, auch nicht bei Single Master. Dafür hat man eben die höheren Protokoll Schichten. Und dafür, dass es funktioniert, gibt es viele Beispiele.
Michael K. schrieb: > Kurzschluss ? > Einen Empfänger auf Enable belassen ? > Mit RS485 hast Du Dich mal länger als 20sek beschäftigt ? Pöbelei ersetzt noch lange keine technischen Argumente. Was glaubst du denn, worin eine Kollision besteht, wenn nicht darin, dass 2 Sender gleichzeitig versuchen zu senden? Dazu muss man sich nicht 20 Sek mit RS485 beschäftigen, dafür genügt ganz normales logisches Denken. Und sofern man dazu überhaupt in der Lage ist, braucht man auch weniger als 20 Sekunden. Georg
>> Was sagt denn die Norm, was man lesen soll, wenn von 2 verbundenen >> Treibern einer 0 der andere 1 schreibt? >Das ist Sache des Layer 2 und nicht Aufgabe des Layer 1. Nö, das hast du nicht verstanden. Der SpannungsPegel ist überhaupt da nicht definiert (und nicht defninierbar), und damit das Ganze schon von vorn herein schlecht/falsch geplant. Und wenn irgentwas 'drüber' gelagertes das erkennen soll, kann das viel länger dauern, als wenn bereits auf Spannungs-Ebene eine Kollision detektiert wird (bsp mit dominantem Pegel).
Michael K. schrieb: > Nosnibor schrieb: >> Was bei RS-485 fehlt, ist eine explizite Kollisionserkennung. Die >> Hardware leistet das einfach nicht > > Lass den Receiver immer an und schau nach was der Transmitter raushaut. > Wenn RX != TX dann Kollision. Der Haken ist nur, das RS-485 nichtmal soetwas wie dominanten/rezessiven Buszustand kennt. Dadurch könnten beliebig undefinierte Buszustände auftreten, wenn zwei Busteilnehmer gegensinnig am Bus ziehen. Bei jedem Sender mag der Pegel noch als RX=TX erkannt werden, aber wie sieht das bei Busteilnehmern aus, die weiter weg liegen. Man muss also mindestens einen größeren Bereich mit ungültigen Pegeln auf dem Bus prüfen.
Michael K. schrieb: > Kollision ist dort ein normaler Vorgang und die Treiber sind explizit > dafür geeignet wie übrigens bei CAN auch. Der Unterschied ist nur, dass bei RS485 die Treiber zwar überleben, bei CAN aber, trotz Kollision, immer noch saubere Logikpegel auf dem Bus liegen, was man bei RS485 nicht behaupten kann.
>SAE J1708 arbeitet mit RS-485 und ist auch für Multimaster geeignet. >Der "Trick" ist dort, dass bei den Transceivern DI immer auf Low ist und >nur DE zum Senden verwandt wird: DE High -> dominant -> DE Low -> >rezessiv, Rest erledigen externe Pullups etc. hier ist bei rezessiv der Driver nur disabled!
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.