www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik uC mit USART über CAN-Transceiver vernetzen?


Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ohne jetzt CAN vs RS485 zu diskutieren eine rein physikalisch/praktische 
Frage: Kann man zum Vernetzen von uCs über knapp 100 m mit USART statt 
eines RS485-Treibers (z.B. SN75176A oder MAX485) einfach einen 
CAN-Treiber (z.B. PCA82C250) nutzen? Also nicht CAN, sondern nur die 
Schnittstellenbausteine dazu. Irgendwo habe ich noch im Hinterkopf, daß 
die CAN-Treiber ein deutlich besseres weißnichmehr (evtl. 
Eingangswiderstand) haben und daher in Bussystemen stabiler sind. 
Differenziell und mit 5V arbeiten sie auch.

Soll ein ziemlich langsamer Bus mit extrem wenig Datenverkehr 
(Minihausbus) werden, so daß ich Single Master vs Multimaster schon 
irgendwie hinkriege und sei es, daß ein Slave den Bus "ärgert" und der 
Master daraufhin jeden Slave fragt, ob er was mitzuteilen hat.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Geht
2. PCA82C250 -> PCA82C251 (robuster)
3. Abschlusswiderstände!

Martin

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das will ich auch so machen mit einem PCA82C250. Den 251 gibt es 
bei R nur in SMD. Allerdings verkraftet der auf dem Bus höhere 
Spannungen (24V). Ich probier es aber erst mal mit dem 250er in DIL.

Ich hab mir hier im Forum erklären lassen das die CAN Treiber besser mit 
Kollisionen zurecht kommen wie RS485. Deshalb habe ich meine Schaltung 
auf CAN geändert. Ich hab aber auch nicht vor einen CAN-Kontroller zu 
benutzen, sondern wollte mein Protokoll selber schreiben, da ich nur mit 
9600 Baud übertrage und nur so einmal in der Sekunde max. 10 Bytes 
sende.

Sofern der BUS frei ist gibt der CAN Treiber an RX das aus, was du an TX 
rein schiebst. Du vergleichst also nach dem senden eines Bytes einfach 
des gerade empfangene Byte mit dem gesendeten. Sind sie gleich, kannst 
du das nächste senden. Sind sie unterschiedlich, musst du das Byte noch 
mal senden. So will ich es zumindest programmieren. Hoffe das geht so.

Plane am Anfang und am Ende des Busses 120 Ohm Abschlußwiderstände 
zwischen CANH und CANL mit ein. Und keine langen Stichleitungen. Am 
besten den Bus immer durchschleifen durch die Geräte.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven Stefan wrote:

> Du vergleichst also nach dem senden eines Bytes einfach
> des gerade empfangene Byte mit dem gesendeten. Sind sie gleich, kannst
> du das nächste senden. Sind sie unterschiedlich, musst du das Byte noch
> mal senden. So will ich es zumindest programmieren. Hoffe das geht so.

Na ja, ganz so einfach geht das natürlich nicht, denn wenn zwei 
gleichzeitig versuchen zu senden, kommt es so zu einer 
"Endlos-Kollision". ;-)

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sven,

danke für die Info. Das mit den Kollisionen war der Vorteil gegenüber 
RS485 (glaube ich zumindest).

Bei Kollision einfach nochmal senden glaube ich aber auch nicht, daß es 
was wird. Eine Kollision ist ja auch nur erkennbar, wenn eine dominante 
0 eine rezessive 1 "runterholt" (diese Arbitrierungsgeschichte halt). 
Eine Null gewinnt immer, da sie niederohmig ist und einen sehr 
hochohmigen Treiber mit 1 (high) auf Null runterzieht (also wie ein 
pull-up-Widerstand oder sagen wir mal lieber, daß ich es so verstanden 
habe und daher nachvollziehen kann).
Diese Arbitrierung (prüfen, ob gesendete 1 auch eine 1 auf dem Bus 
ergibt) braucht man dann m. E. wohl nur machen, wenn auch ein Bit mit 1 
gesendet wurde, da eine Null durch einen anderen nicht auf 1 gebracht 
werden kann. Erkennt ein uC diesen Fall für sich, muß er sofort aufhören 
zu senden.  Diese Prüfung explitzit per uC für jedes Bit dürfte aber 
ziemlich Rechenzeit kosten und daher auch die Baudrate absenken, ganz 
besonders, wenn der uC noch etwas anderes zu tun hat. Ist mir aber wie 
beschrieben diesmal ziemlich egal.
Beim nächsten kleinen Projekt (evtl. nur 2 uC verbinden) werde ich 
vielleicht aber mal CAN "komplett" ausprobieren, da das wohl die Zukunft 
bzw. eigentlich wohl schon Gegenwart ist und in größeren und schnelleren 
Projekten mit Abstand erste Wahl sein dürfte.
Aber für meine ca. 25 geplanten Rauch- und Bewegungsmelder sind das pro 
Stück 3 Euro mehr für den MCP2515, also ca. 75 Euro (und dann ist das 
Datenblatt auch noch sowas von buggy ...). Da quäle ich mich diesmal 
lieber mit einem eigenen Protokoll rum (und hoffe, daß ich DIESEN Bus 
niemals erweitern will...)

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz wrote:
> Beim nächsten kleinen Projekt (evtl. nur 2 uC verbinden) werde ich
> vielleicht aber mal CAN "komplett" ausprobieren, da das wohl die Zukunft
> bzw. eigentlich wohl schon Gegenwart ist und in größeren und schnelleren
> Projekten mit Abstand erste Wahl sein dürfte.

CAN ist seit 25 Jahren Gegenwart. Man brauch da nicht mehr von Zukunft 
sprechen, auch wenn er immer noch gut ist ;-)

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lutz> Nach deiner Methode müsstest du dann aber die UART in Software 
programmieren. Ich hatte eigentlich vor, die Hardware UART des µC zu 
benutzen. Dann würde der Kontroller ein komplettes Byte rausschieben und 
erst danach feststellen können, ob dieses Byte fehlerfrei übertragen 
wurde. Gab es einen Fehler, dann ist das komplette Byte zu verwerfen und 
neu zu senden.

Derzeit bin ich aber mit meinem Projekt noch nicht so weit, dass ich 
mich an das Protokoll wagen kann. Ich denke da warten noch viele 
Probleme auf mich, welche ich im Moment noch nicht sehe.

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.