Hej! Ich möchte unser "Anwesen" mit Microcontrollern selbst steuern. Ist ein alter Bauernhof, nichts dolles, aber weite Wege. Daher kommt nur ein CAN-Bus in Frage, richtig? Ich habe jetzt viel recherchiert und auch schon erste Erfahrungen mit der PIC Familie (16Fxxxx und 18Fxxxx) gemacht. Ich frage mich nun, wie man so einen CAN-Bus umsetzt. Es scheint eine komplizierte Angelegenheit zu sein. Habe jetzt gelesen wie das Protokoll, bzw. die Datenübertragung aufgebaut ist. Es gibt Transceiver, die noch hinter die uC Ausgänge zu hängen sind und dann läuft das. Aber wie? Hat da jemand vielleicht einen Link oder eine Anleitung wie man einen CAN-bus praktisch umsetzt? Was benötige ich? Wird der nur konfiguriert und ich lese mein Datenpaket ein? Ich brauche da einen Tritt in die richtige Richtung :-) Sam
Ob du einen CAN-Bus brauchst bzw. ob der sinnvoll ist, hängt hauptsächlich von einer Frage ob: Funktioniert das ganze als Single-Master oder brauchst du Multimaster? Geht das ganze als singlemaster, bist du mit der guten alten RS485 bestens bedient. Die Hardware wird einfacher und billiger. D.h. irgendwo steht ein Chef-mikrocontroller, der alles steuert. Sendet Steuerbefehle, fragt Sensorwerte ab etc. Scheint mir für Hausautomation völlig ausreichend. Multimaster mit RS485 ist sehr aufwändig, haben sich schon einige dran verhoben. CAN ist "moderner", es steckt allerdings auch eine ganz andere Philosophie dahinter.
Samuel Simmeck schrieb: > Daher kommt nur > ein CAN-Bus in Frage, richtig? # RS485/422 oder LIN, wenn die Datenmengen nicht allzu groß sind. # CAN und LIN bieten aber eine Fehlererkennung. Bei RS485/422 muss man sich da selber kümmern(Protokoll ausdenken...). Samuel Simmeck schrieb: > Es gibt Transceiver, die noch hinter die uC Ausgänge zu > hängen sind und dann läuft das. Aber wie? # Es gibt spezielle CAN-Controller wie z.B. den MCP2515 oder Nachfolger, die hängt man über SPI an den µC. Oder man nimmt direkt CAN-Fähige µC. # LIN kann eigentlich jeder µC, wenn er eine Anständige UART drin hat. # RS485/422 ist nix anderes als Serielle Schnittstelle, Senden und Empfangen auf Doppelader. Geht halt nur Halbduplex. Kann jeder µC mit Uart. Dann braucht man noch Bustreiber. # MCP2551 für CAN, der kommt an den 2515 dran. # RS485 gibt es z.B. SNsn75176, MAX485... direkt n den µC # Lin-Bus Treiber ATA6620N, aber schwer zu bekommen(selber friemeln??). auch direkt an den µC. mfg mf
Samuel Simmeck schrieb: > Es scheint eine komplizierte Angelegenheit zu sein. Nur wenn man es mit Stacks wie CANopen implementiert, oder mit den 8 Bytes Inhalt nicht auskommt. Wenn man CAN als Methode versteht, 0-8 Bytes mit selbstgewählten IDs ins Netz zu schicken und zu empfangen, dann ist es sogar ziemlich einfach.
> Ist ein alter Bauernhof, nichts dolles, aber weite Wege. Daher > kommt nur ein CAN-Bus in Frage, richtig? Nein, du brauchst eine physikalische Realisierung (aka Bustreiber) welche fuer eine groessere Entfernung geeignet ist. Das koennte z.B RS485 oder RS422 sein. Und du koenntest darauf ein bestimmtes Protokoll fahren. Eine der Moeglichkeiten waere CAN. Es gibt aber erstmal keinen bestimmten Grund genau CAN zu verwenden. CAN hat nur den Vorteil das du Microcontroller kaufen kannst wo schon einiges an der Realisierung des Protokolls in Hardware verbaut ist. Ausserdem koenntest du dir voll coole (und megateure) Busanalyzer kaufen wenn dein Bus hustet. Aber du kannst dir auch was ganz eigenes ausdenken. Letztlich stellt sich aber die Frage was willst du ueberhaubt an Daten ueber den Bus schicken. Brauchst du einen Bus weil es irgendwie cool ist, oder steht da irgendeine sinnvolle Aufgabe dahinter? Olaf
crazy horse schrieb: > Chef-mikrocontroller Chef-mikrocontroller klingt gut. So habe ich das vor. Es reicht völlig aus, wenn ein uC Befehle an die anderen leitet. Es reicht auch aus, wenn jeder slave nur empfänger ist... für's erste. Auch die RS485/422 klingt erstmal super. 1200m max. Reichweite reicht aus. Wie setzte ich das um? Ich programmiere vornehmlich in C. Das liegt mir besser. Gibt es irgendwo einen Plan? So etwas wie "Meine erste serielle Schnittstelle - Aufbau und Programmierung"? Danke, Sam
Olaf schrieb: > Letztlich stellt sich aber die Frage was willst du ueberhaubt an Daten > ueber den Bus schicken. Brauchst du einen Bus weil es irgendwie cool > ist, oder steht da irgendeine sinnvolle Aufgabe dahinter? Naja. Den Bus brauche ich um 1.) nicht so viele Leitungen zu verlegen 2.) etwas dabei zu lernen Im Prinzip würde es aber ausreichen, wenn die Datenpakete von vielleicht 7 oder 8 Bit vom Master gesendet und von den Slaves empfangen werden. Ich habe eben ein Problem mit der Reichweite und gelesen, dass man bei "normaler" serieller Datenübertragung eine Reichweite von max. 10 Metern hinbekommt. Das heißt von µC zu µC. (Mit speziellen kapazitäsarmen bis zu 50m) Das würde mich stark einschränken.
Samuel Simmeck schrieb: > "normaler" serieller Datenübertragung eine Reichweite von max. 10 Metern > hinbekommt. Stimmt nur bei RS232, wie man es vom PC kennt (kannte). RS485 ist die gleiche Schnittstellenart, nur differenziell mit anderen Transceivern. Da geht viel mehr.
> Ich habe eben ein Problem mit der Reichweite und gelesen, dass man > bei "normaler" serieller Datenübertragung eine Reichweite von > max. 10 Metern hinbekommt. Das heißt von µC zu µC. (Mit > speziellen kapazitäsarmen bis zu 50m) Naja, ich sag mal du hast eher ein Problem damit keine Ahnung von Hardware zu haben. :-) Aus zuverlassigkeitsgruenden bietet es sich schon an differentiell, also RS422 zu uebertragen. Und weil Kabel ein Kostenfaktor darstellen bietet es sich meist auch an beide Datenrichtungen auf einem Kabelpaar zu uebertragen. Also RS485. Ausserdem ist es ja nicht so das ein RS485 Treiber teuer waere. Allerdings wenn du wirklich Kabel zwischen verschiedenen Haeusern verlegen willst dann ist es dringend anzuraten das ganze potentialfrei zu machen. Oder du musst die Bustreiber sockeln weil du sie nach jedem Gewitter wechseln musst. :-) Olaf
Samuel Simmeck schrieb: > Auch die RS485/422 klingt erstmal super. 1200m max. Reichweite reicht > aus. Auch da brauchst du aber genau wie bei CAN einen Transceiver an jedem Teilnehmer. Samuel Simmeck schrieb: > Im Prinzip würde es aber ausreichen, wenn die Datenpakete von vielleicht > 7 oder 8 Bit vom Master gesendet und von den Slaves empfangen werden. Wie oft? Wieviele Pakete? Wieviele Slaves? > Ich habe eben ein Problem mit der Reichweite und gelesen, dass man bei > "normaler" serieller Datenübertragung eine Reichweite von max. 10 Metern > hinbekommt. Das heißt von µC zu µC. (Mit speziellen kapazitäsarmen bis > zu 50m) > > Das würde mich stark einschränken. Es hängt maßgeblich von der Bitrate ab. Siehe http://de.wikipedia.org/wiki/RS-232
crazy horse schrieb: > Geht das ganze als singlemaster, bist du mit der guten alten RS485 > bestens bedient. Die Hardware wird einfacher und billiger. CAN-Hardware ist auch spottbillig. Aber die Software ist bei RS485 erheblich komplizierter, um jeden Scheiß mußt Du Dich selber kümmern. Bei CAN stellt man einfach nur eine Nachricht in den Sendepuffer und wenn die fertig ist, kriegt man einen Interrupt. Obs Retrys, Kollisionen, CRC-Fehler usw. gab, interessiert einen nicht. Und der Empfänger kriegt auch nen Interrupt, daß eine Nachricht empfangen wurde. Man braucht kein aufwendiges Protokoll, wie bei RS485. Jeder sendet einfach drauf los, wenn er was zu sagen hat. Und die CAN-Hardware kümmert sich von alleine drum, daß es richtig beim Empfänger ankommt. Nur bei total gestörter Verbindung zählen die Errorcounter hoch und bei Überschreitung eines Limits gibts dann auch nen Interrupt, daß die Verbindung gestört ist. Peter
Ein Master, viele Slaves bei großen Entfernungen? möglichst einfaches Protokoll? Wie wäre es mit DMX (via RS485)? Es gibt zwar keine Prüfsummen, aber viel einfacher und flotter geht es nicht... VG, Hendrik
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.