uC mit USART über CAN-Transceiver vernetzen?

Lutz Gast #916063
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Sven S. Persönliche Seite #916107
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan E. #916123
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". ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lutz Gast #916215
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...)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Willivonbienemaya .. #919491
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 ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
stepp64 Gast #919683
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 Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren