welchen RS485 Treiber für Multimaster?

>Hi, wenn ich mit RS485 Multimaster nutzen will kann ich doch keinen
>normalen MAX485 nehmen, oder?
Doch. Eigentlich sind  doch alle RS485-Netzwerke Mulimaster.
Es kommt dabei auf die Software an und das Datenverkehrsaufkommen an.

>Soweit ich das verstanden habe steigen die normalen Treiber aus, wenn zwei 
>versuchen, gleichzeitig zu senden.
Was meinst du mit "aussteigen"?
Wenn ein Treiber eine logische "1" sendet und ein anderer eine logische 
"0", dann kommt es zu einem Kurzschluss auf dem Bus.

CAN-Transceiver erkennen sowas.

STK500-Besitzer schrieb:
> Doch. Eigentlich sind  doch alle RS485-Netzwerke Mulimaster.
Eigentlich nicht, RS485 ist in seiner Grundform Single Master

STK500-Besitzer schrieb:
> Was meinst du mit "aussteigen"?
> Wenn ein Treiber eine logische "1" sendet und ein anderer eine logische
> "0", dann kommt es zu einem Kurzschluss auf dem Bus.
Eben. Soweit ich weiß schalten normale Treiberbausteine dann ab. Es gibt 
aber welche mit Fault Protect
>
> CAN-Transceiver erkennen sowas.

CAN funktioniert etwas anders. Bei CAN gibt es nur Sink Treiber und 
einen PullUp Widerstand. Da gibt es keinen Kurzschluss. RS485 hat 
Push/Pull Treiber.

Bitte korrigiert mich, wenn ich falsch liege. Aber soweit ich weiß 
müsste das stimmen.

Ein RS485-Driver kann normal bis 32 Receiver treiben (also den eigenen 
Receiver im Transceiver + 31 andere). Es gibt aber auch Bausteine mit 
erweiterte Spezif. (z.B. von Maxim) mit max 128 Receivern.
Bei CAN-Transc. kann (wie oben erwähnt) immer einer ein dominantes 0-Bit 
auf die Leitung legen, ähnlich einer einfache OpenColector-Struktur.
Das ist auch das Prinzip, weshalb CAN die bitweise Arbitrierung machen 
kann. (Jeder Driver sendet seine dominate 0-Pegel jedes Adr-Bits) und 
derjenige Driver "gewinnt", bei dem das MSB 0 ist (bzw die meisten 
oberen Bits 0 sind) )
Somit könnte man auch gut ein eigenes Netzwerk sich bauen, mit 
CAN-Transceivern anstatt mit RS485-Transceivern.

A. K. schrieb:
> Für
> Bus-Arbitrierung per Konflikt/Kollision sind sie nicht vorgesehen.

Es gibt z.B. den MAX3430 mit Fault-Protected. Da steht explizit dabei 
"Multimaster RS-485 Networks"

Ich habe sogar ein Projekt gefunden, das ein Protokoll dafür 
implementiert

http://ulan.sourceforge.net/index.php?page=1

Mir ist klar, dass die Treiber eine Kollision nicht erkennen können. Das 
muss die Software machen.

Aber ein MAX485 oder LTC485 hat meines Wissens kein "normales" Fault 
Protect. Im Fall eines Kurzschlusses bei einer Kollision schalten diese 
Treiber afaik komplett ab.

Es geht also nicht darum, dass die Treiber eine Kollision erkennen 
sondern nur darum, dass die Treiber eine Kollision verkraften ohne 
abzuschalten. Das Erkennen muss ausschließlich die Software machen.

>Das Erkennen muss ausschließlich die Software machen.
Aber das gibt extreme Probleme (bzw ist das Erkennen fast unmöglich), da 
der Spannungspegel auf der Leitung dann nicht genau definiert ist. Bzw 
müsste über viele Bits hinweg jeder Sender seine eigens gesendeten Bits 
vergleichen... und das während der langen Zeit der Kurzschlüsse...  das 
ist nicht praktikabel

>Nein, das Erkennen ist nicht allzu schwierig. Der CRC ist kaputt.
Dann sind während dieser ganzen ProtokollZeit Kurzschlüsse auf dem Bus 
!!! U.U. mit sehr grossen Strömen.
Auch könnte es sein dass verschiedene Receiver verschiedene Werte lesen, 
so dass im Extremfall (wenn rel. kurzes Protokoll) sogar ein Receiver 
kein Fehler feststellt, und andere Receiver doch einen Fehler 
feststellen.

>CAN ist leider Muell. Die Packetlaenge ist nur 6 Byte, was fuer
>Automobildaten passend sein mag, aber fuer viele Anwendungen eher mager
>ist.

Man muss ja nicht das ganze Protokoll und die damit verbundenen 
Controller verwenden, sondern kann sich die Sache selber bauen.
Beim CAN-Transceivern wird nicht zwischen Senden und Empfangen 
umgeschaltet wie beim RS485-Transceivern. Da muss man dann "nur" das 
gesendete Byte mit dem empfangenen vergleichen und entsprechend 
reagieren: Bei Gleichheit kann man weiter senden, bei Ungleichheit war 
jemand anders auch auf dem Bus unterwegs...

Die Idee, einen CAN Transceiver statt RS485 zu verwenden ist schon keine 
schlechte Idee, hat aber einen Haken. Man hat sein eigenes Format 
kreiert und kann keine anderen Geräte verwenden, die RS485 Transceiver 
haben

Wenn man von der dominanten-0-Bit-Detections-Möglichkeit (u.a. bei CAN 
Transceivern) profitieren will, schafft man aber keine so hohe 
Übertragungsraten, weil jedes Bit so lange geschaltet sein muss, dass es 
überall auf der Leitung ansteht. (Deswegen ist CAN auch rel. langsam)

Ich ziehe RS485 halt CAN vor, weil dafür keine speziellen Controller 
nötig sind. Jeder Mikrocontroller, der 9 Bits verarbeiten kann, ist in 
der Lage das zu nutzen.

Wenn er jetzt noch einen IRQ bei gesetztem neunten Bit auslöst hat man 
schon die halbe Miete.

Für eigene Projekte in einem geschlossenen Umfeld würde ich vielleicht 
sogar CAN Transceiver einsetzten, aber es gibt auch das eine oder andere 
Modul, das ich gerne verwenden würde.

>Ich ziehe RS485 halt CAN vor, weil dafür keine speziellen Controller
>nötig sind.
Für CAN-Transc.  -wie auch f. RS485Transc.-  sind keine speziellen 
Controller nötig

MCUA schrieb:
> Für CAN-Transc.  -wie auch f. RS485Transc.-  sind keine speziellen
> Controller nötig

Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller, 
Protokoll.

Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht 
Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn 
CAN, dann das volle Programm

>Für CAN-Transc.  -wie auch f. RS485Transc.-  sind keine speziellen
>Controller nötig

Was ich auch die ganze Zeit vermitteln möchte...

>Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht
>Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn
>CAN, dann das volle Programm

Blödsinn!

>Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller,
>Protokoll.

Falsche Einstellung.

STK500-Besitzer schrieb:
> Falsche Einstellung.

Ich möchte mal Wikipedia zitieren

> CAN ist als ISO 11898 international standardisiert und definiert die Layer 1 
(physikalische Schicht) und 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell.

Meine Einstellung interessiert in der realen Welt da draußen keinen. 
Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein 
eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände 
nicht viel.

Es funktioniert, keine Frage. Aber funktionieren allein reicht nicht 
immer

Achso, willst du vielleicht darauf hinaus, das CAN Protokoll in Software 
zu emulieren?

>Meine Einstellung interessiert in der realen Welt da draußen keinen.
>Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein
>eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände
>nicht viel.

Auf der RS485 benutzt du also ein standardisiertes Protokoll?
Wenn ich mir das Protocol2000 von Kramer (im Bereich der 
Video-Kreuzschienen relativ verbreitet) ansehe, dann ist es mit 4 Bytes 
sehr beschränkt.
Für die Anwendung reicht es alle Mal.

Viel Erfolg!

Das es für RS485 kein Standard Protokoll gibt weißt du so gut wie ich. 
Aber das kann man ja selbst anpassen.

Wenn man einen CAN Controller nimmt und irgendwelche CAN Devices 
anschließen will hat man eben seinen Standard, auf dem alles Basiert

Aber wenn du einen CAN Transceiver einfach an einen UART klemmst hast du 
gar nichts. Willst du CAN Geräte anschließen musst du das komplette CAN 
Protokoll selbst stricken und wenn du RS485 Geräte anschließen willst 
kommst du auch nicht weit

Was willst Du?
Auf der einen Seite, vorhandene 'normale' Geräte mit RS485 
Schnittstellen ansteuern und auf der anderen Seite ein spezielles, 
kollisionsfestes Interface verwenden? Das paßt doch nicht zusammen!

>Wenn ich einen CAN Transceiver direkt an einen UART klebe und mein
>eigenes Protokoll stricke bringt mir das außerhalb meiner vier Wände
>nicht viel.

Das bringt immerhin soviel, dass Deine eigenen Geräte funktioniern.

Tropenhitze schrieb:
> Auf der einen Seite, vorhandene 'normale' Geräte mit RS485
> Schnittstellen ansteuern und auf der anderen Seite ein spezielles,
> kollisionsfestes Interface verwenden? Das paßt doch nicht zusammen!

Wieso ein spezielles? Ich will lediglich einen RS485 Transceiver 
verwenden, der Multimasterkommunikation erlaubt. Ich kann aber immer 
noch Geräte anschließen, die normale Treiber verwenden. Die senden ja 
nur, wenn sie aufgefordert wurden.

H.joachim Seifert schrieb:
> JEDER RS485-Transceiver ermöglicht Multimaster

Nur, wenn sichergestellt ist, dass keine zwei Master gleichzeitig 
senden. Sobald das passiert bekommt man mit normalen Transceivern ein 
Problem. Deshalb gibt es ja z.B. den MAX3430. Dort steht auch explizit

> Multimaster RS-485 Networks

Also um das mal zusammenzufassen. Entweder man hat normale Transceiver 
und stellt per Software/Protokoll sicher, dass immer nur einer sendet. 
Dh alle Teilnehmer handeln vorher aus, wer als nächstes senden darf.

Oder man verwendet Fault Protected Transceiver und kann eine 
Software-Kollisionserkennung nutzen. Also einfach Daten senden und auf 
ein ACK des Empfängers warten. Folgt das nicht kam es zu einer 
Kollision.

Letzteres dürfte effizienter sein, weil vor jeder Arbitrierung kein 
zusätzlicher Overhead nötig ist.

>Deshalb gibt es ja z.B. den MAX3430.

Hast Du denn auch Repeater mit diesem MORITZ?
Diese müßten das 'böse' Spiel ja auch mitmachen.

Da mit 128 Devices an einem Bus mehr als ausreichen und ich auch keine 
10km überbrücken will sehe ich noch keine Notwendigkeit für einen 
Repeater

Und ich bin mir sicher, dass es etwas entsprechendes gibt.

(wurde zwar schon von anderen erläutert)

>> Für CAN-Transc.  -wie auch f. RS485Transc.-  sind keine speziellen
>> Controller nötig

>Jain. Für mich ist CAN das Gesamtpaket, also Transceiver, Controller,
>Protokoll.

>Einen CAN Transceiver als RS485 Verschnitt zu missbrauchen ist nicht
>Brot und nicht Fleisch. Man werkelt da nur in seiner eigenen Welt. Wenn
>CAN, dann das volle Programm

tschuldigung, aber "Jain" ist Humbug. Als Entwickler weisst du doch 
(oder nicht ?), dass es auf eine binäre Frage nur "JA" oder "NEIN" gibt. 
Also was soll das Gerede?

ENTWEDER der Transceiver kanns ODER er kanns nicht. Fertig.
Seit wann muss ein IC (oder Transceiver) Brot oder Fleisch sein ? Dann 
musst du ins Lebensmittelgeschäft gehen !
Ein CAN Transceiver ist genau so ein Transceiver wie ein RS485 
Transceiver oder ein XXXX-Transceiver. Der hat (genau wie andere auch) 
genau spezif. Eigenschaften. Und wenn die passen, dann kann den nehmen. 
Deswegen gibts den ja.

---------
Aber wenn du ein COMPLETT FERTIGES (Feld)Bussystem kaufen oder nachbauen 
willst, musst du dich sowiso an DIESE Spezif. halten , und dann ist 
deine ganze Fragerei nach einem Treiber o.ä. sowiso hinfällig.

>Repeater auf einem bidirektionalen Bus ist schwierig.

Eigentlich nicht:
forums.futura-sciences.com/.../42449d1206434081-reemmeteur-rs485-bidirec 
tionnel-repeteur-rs485.pdf

Blöder Link; hier die Datei.