www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik welchen RS485 Treiber für Multimaster?


Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, wenn ich mit RS485 Multimaster nutzen will kann ich doch keinen 
normalen MAX485 nehmen, oder? Soweit ich das verstanden habe steigen die 
normalen Treiber aus, wenn zwei versuchen, gleichzeitig zu senden.

Muss man einen Treiber mit Fault Protect nehmen?

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens Schwarzhans schrieb:

> Eigentlich nicht, RS485 ist in seiner Grundform Single Master

Sie sind durchaus Multi-Master tauglich. Wenn konfliktfrei. Für 
Bus-Arbitrierung per Konflikt/Kollision sind sie nicht vorgesehen. 
CAN-Trensceiver sind es.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens Schwarzhans schrieb:

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

Soweit nichts Neues. RS485-Transceiver sind m.W. alle irgendwie gegen 
Kollisionen abgesichert, und sei es thermisch. Der Knackpunkt bei 
Transceivern für Multimaster mit Kollision als Quasi-Normalzustand ist, 
ob die Beteiligten die Kollision auch sicher erkennen können, und zwar 
alle in gleicher Weise.

Ich kann mir zwar spezielle RS485-Transceiver oder Zusatzbeschaltungen 
vorstellen, die eine Kollision sicher erkennen und signalisieren, aber 
die üblichen Transceiver allein tun dies nicht, auch nicht dieser MAXe. 
Je nach Leitungslänge/dicke können Streithähne an entfernten Enden der 
Leitung zu unterschiedlichem Ergebnis kommen.

Daher meine obige Aussage, die für diesen MAXe ebenso zutrifft wie für 
den ollen SN75176: Multimaster geht, aber Kollisionen als 
Arbitrationsmechanismus sind problematisch. Es gibt jedoch Verfahren wie 
Token Passing, bei denen Kollisionen nur als eher seltener Nebeneffekt 
bei Tokenverlust auftreten, allerdings ist das in der Praxis recht 
komplex. Auch das im verlinkten Projekt verwendete Verfahren betont die 
Notwendigkeit, Kollisionen möglichst zu vermeiden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Illustration: Der Kurzschluss/Kollisionsstrom dieses MAXe liegt bei 
bis zu 250mA und die Schwellspannung in der Grössenordnung von 100mV. 
Ein Leitungswiderstand von einigen Zehntel Ohm kann also im Konfliktfall 
bereits dazu führen, dass beide Seiten sich als Gewinner sehen und keine 
Kollision erkennen.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das Erkennen ist nicht allzu schwierig. Der CRC ist kaputt. 
Nochmals.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für neue Projekte würde ich im Moment ausschliesslich CAN verwenden.
Die ganzen Klimmzüge, die bei RS485 nötig sind, kann man sich getrost 
schenken. Braucht niemand.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H.joachim Seifert schrieb:
> Für neue Projekte würde ich im Moment ausschliesslich CAN verwenden.
> Die ganzen Klimmzüge, die bei RS485 nötig sind, kann man sich getrost
> schenken. Braucht niemand.

Hm. Gibt es CAN eigentlich potentialfrei?

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN ist leider Muell. Die Packetlaenge ist nur 6 Byte, was fuer 
Automobildaten passend sein mag, aber fuer viele Anwendungen eher mager 
ist.
Da RS485 Treiber einen Innenwiderstand haben, ist ein Kurzschlussstrom 
nicht allzu gross. Ein Kurzschluss ist immer moeglich und muss daher 
tolerierbar sein.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm. Ich habe CAN bislang immer erfolgreich umgangen. Echt nur 6 Byte? 
Das ist wirklich dürftig.

Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten?

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:

> Hm. Ich habe CAN bislang immer erfolgreich umgangen. Echt nur 6 Byte?
> Das ist wirklich dürftig.

Es sind nicht 6 sondern 8 Bytes. Plus einer 29-Bit Adresse in der sich 
ggf. auch noch etwas Daten unterbingen lassen (z.B. Zeile/Spalte bei 
LCD-Daten) wenn man die Adressstruktur selber definiert.

CAN ist ein Steuerbus, kein Interface für Massenspeicher. Was mich nicht 
daran gehindert hat, den Inhalt eines 512KB Protokollspeichers darüber 
zu übertragen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:

> Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten?

Indem man den Transceiver vom Controller potentialtrennt. Nicht anders 
als bei RS485, nur eine Leitung weniger (kein driver enable nötig).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey noch Was schrieb:

> Da RS485 Treiber einen Innenwiderstand haben, ist ein Kurzschlussstrom
> nicht allzu gross.

Die Hersteller der Transceiver scheinen sich dabei auf einen Maximalwert 
von 250mA geeinigt zu haben.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann auch die höheren Layer von typischer RS485 Vernetzung nutzen, 
d.h. UART, und dies mit CAN Transceivern kombinieren. Damit sind 
Kollisionen sauber definiert und man erspart sich das etwas fieselige 
Timing von driver enable und inter packet gap. Wer unbedingt 
RS485-Multimaster fahren will, der sollte diese Variante ebenfalls 
betrachten.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar. Wenn man feste Vorgaben darüber hat, mit welchen Fertiggeräten 
sich das kombinieren lassen muss, dann erübrigt sich jede Diskussion 
über physikalische Übertragungstechnik, Betriebsart und Protokolle, denn 
dann definieren diese Geräte die Technik und der Rest vom Netz muss sich 
dran halten.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: STK500-Besitzer (Gast)
Datum:

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

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

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, willst du vielleicht darauf hinaus, das CAN Protokoll in Software 
zu emulieren?

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versteh dich immer noch nicht.
JEDER RS485-Transceiver ermöglicht Multimaster.
Es gibt aber zur selben Zeit nur einen einzigen Sender auf der Leitung. 
Welcher das wann ist, musst du irgendwie selbst per Software 
ausklamüsern.
Und dafür gibts verschiedene Ansätze.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens Schwarzhans schrieb:
> 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.

Was irgendwelche Synchronität voraussetzt und das ist das Problem. 
Sobald das Netzwerk relativ groß wird, 'sehen' sich die Transceiver 
nicht mehr 'rechtzeitig', und daher...


>
> 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.


... ist dies effizienter! Diese Erkennung brauch man eh. Einfacher CRC 
reicht völlig.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Abdul K. schrieb:
>
>> Also, geht das? 100V Potentialdifferenz zwischen zwei Geräten?
>
> Indem man den Transceiver vom Controller potentialtrennt. Nicht anders
> als bei RS485, nur eine Leitung weniger (kein driver enable nötig).

Ich meinte eigentlich eine Trennung per Übertrager und 
gleichspannungsfreien Code, also FM bzw. Manchester. Geht das bei CAN? 
Ich vermute es geht nicht.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jens Schwarzhans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Repeater auf einem bidirektionalen Bus ist schwierig.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Repeater auf einem bidirektionalen Bus ist schwierig.

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

Autor: Tropenhitze (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Blöder Link; hier die Datei.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.