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.
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.
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". ;-)
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...)
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 ;-)
@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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.