Hallo Zusammen,
Bei
http://cool-emerald.blogspot.com/2009/10/multidrop-network-for-rs232.html
fand ich die RS232-Schaltung des Bild-Anhangs.
(Bitmap etwas umgezeichnet, Quelle im Bild erwähnt)
- 2 MASTER und 1 SLAVE.
- HIER: 3x ATMEGA-48/88, @USART I/O-Level, @5V Vcc.
- Beide MASTER können zum SLAVE senden.
- Sendet/antwortet der SLAVE: Dann empfangen es BEIDE MASTER.
FRAGE DAZU:
Seht Ihr eine Möglichkeit (Dioden / R),
dass AUCH MASTER-zu-MASTER reden können?
- Egal wäre es, wenn der Slave mithört.
- Egal wäre es, wenn "Sender @TX" eigenes Echo hören.
Türlich ist Arbitrierung nötig, heute erssma die Hardware,
und ich danke Euch für Hinweise.
Hannes schrieb:> Siehe Anhang (Auszug aus mc 4/1983 - mc-Netzwerk).
Hier wird dann auch die Unterscheidung zwischen Initiator und Target
unnötig. Ein einfacher 1-Draht Bus, auf dem jeder mit jedem reden kann.
Im ersten Posting gibts noch den Nachteil, das die Master kollidieren
können, was bei 1-Draht vermieden werden kann.
Hermann Kokoschka schrieb:> FRAGE DAZU:> Seht Ihr eine Möglichkeit (Dioden / R),> dass AUCH MASTER-zu-MASTER reden können?
Klemm alles auf 1 Leitung mit 1 Pullup. Dann hören alle, was alle reden.
Du musst in deinem Bild da nur die rote gepunktete Linie mit der blauen
gepunkteten Linie verbinden...
Matthias S. schrieb:> Im ersten Posting gibts noch den Nachteil, das die Master kollidieren> können, was bei 1-Draht vermieden werden kann.
... ebenfalls vermieden werden muss.
Lothar M. schrieb:> Matthias S. schrieb:>> Im ersten Posting gibts noch den Nachteil, das die Master kollidieren>> können, was bei 1-Draht vermieden werden kann.> ... ebenfalls vermieden werden muss.
Im Vorteil ist, wer lesen kann ...
Anhang: Auszug aus dem schon zitierten mc-Artikel
Hannes schrieb:> Anhang: Auszug aus dem schon zitierten mc-Artikel
Ja. Passt doch. Da steht nur, dass der Frame kaputt ist und die Daten
korrupt, wenn 2 Teilnehmer gleichzeitig senden. Und man wird sich bei
der Umsetzung wundern wie komplex und fehlerbehaftet diese "interne
Logikprüfung" sein kann.
> Im Vorteil ist, wer lesen kann ...
Wie steht es direkt über jeder Texteingabebox?
Dort steht: Siehe Bildformate.
Und dort siehe speziell den Abschnitt "Nie_wieder_BMP!"
Lothar M. schrieb:> Ja. Passt doch. Da steht nur, dass der Frame kaputt ist und die Daten> korrupt, wenn 2 Teilnehmer gleichzeitig senden. Und man wird sich bei> der Umsetzung wundern wie komplex und fehlerbehaftet diese "interne> Logikprüfung" sein kann.
Genau. Der Frame ist nämlich nicht zwingend kaputt und schon garnicht
für jeden der vielen Mitleser (insbesondere die kollidierenden Master
selber) gleichermaßen.
Man muss schon einiges an Hirnschmalz aufwenden, um ein wirklich
zuverlässiges Protokoll für solch einen OneWire-UART-Bus zu entwerfen,
der obendrein die Peers nicht besonders anstrengt.
Aber: Es ist definitiv möglich, das zu tun! Man muss es nur wollen und
können.
Ist der Bus jemals fertig entwickelt worden? Ich sehe da schon einige
Probleme, vor allem wenn die Pins an normale UARTs gehen.
Klein war ja immer superhektisch..
.
Abdul K. schrieb:> Ist der Bus jemals fertig entwickelt worden?
Welches soll DER Bus sein? Fakt ist jedenfalls, dass es unzählige
funktionierende Implementierungen von Bussen gibt, die auf dem Konzept
von OC-Style-gekoppelten UARTs aufsetzen.
Also scheint es eine ganze Menge von Leuten zu geben, die in der Lage
sind, das Problem hinreichend zu durchdenken und ein entsprechendes
Protokoll zu designen...
Lothar M. schrieb:> Wie steht es direkt über jeder Texteingabebox.> Dort steht: Siehe Bildformate.> Und dort siehe speziell den Abschnitt "Nie_wieder_BMP!"
Mea culpa - tatsächlich wollte ich aus dem PDF ein PNG erzeugen.
Typische Fehlleistung, vermutlich dem Kalk und der Hitze geschuldet ...
Hermann Kokoschka schrieb:> Türlich ist Arbitrierung nötig, heute erssma die Hardware,> und ich danke Euch für Hinweise.
Sowohl der CAN- als auch der LIN-Bus sind bereits erfunden und davor gab
es bereits RS485.
232_NET.JPG
(46 KB)
