Hi ich möchte einige Sensoren mit möglichst wenig Aufwand an einem CAT5e kabel betreiben. Da kam mir die Idee, einfach die RX/TX Leitung des AVR, TX Evtl über einen Impedanzwandler direkt zu nutzen. Die Baudrate kann dabei bei 1200 Baud o.ä. beleibig gering sein, sie sensoren werden alle 5 minuten abgefragt... Die AVRs haben ja am Eingang einen Schmitt-Trigger, dh der Pegel muss nicht ganz auf 0V abfallen um als 0 Interpretiert zu werden, und muss auch nicht ganz VCC sein um als 1 erkannt zu werden RS232 kann bei 2400 Baud wohl schon 900m überbrücken. Dann müsste es mit entsprechenden Pullups und Transistoren ja kein Problem mit UART sein?? Ich weis dafür gibts RS485, nur da habe ich noch einen weiteren IC, und weitere Kosten. Hat jemand schonmal sowas gemacht??
Du brauchst trotzdem eine Art Bustreiber, damit du das überhaupt als Bus nutzen kannst. Am einfachsten ist es CAN zu verwenden, das macht die Arbitrierung vollautomatisch in Hardware (d.h. wenn mehrere gleichzeitig senden kommt die höher-prioritäre Nachricht garantiert an, danach die nächste, etc.). Weitere Fehlerkontrollmechanismen gibts gratis dazu. Du brauchst nur einen CAN-fähigen Mikrocontroller und einen externen CAN-Transceiver (gibts in DIP8 oder kleiner, minimaler Beschaltungsaufwand). Leitungslänge bis 6.7km bei 10kBit/Sec. Da der CAN-Controller die ganze Bus-Logik in Hardeware macht, ist der Software-Aufwand minimal, im Gegensatz zur Selbst-Bastel-Lösung mit RS232 oder RS485.
Naja die sensoren sprechen nicht ungefragt... Also der Controller sendet eine ID (3 bytes+crc) auf der TX leitung, der entsprechende Sensor antwortet etc. Daher benötige ich keine kontrolle, das nicht mehrere gleichzeitig reden etc.
Dr. Sommer schrieb: > und einen externen CAN-Transceiver Bei manchen uC noch nicht mal den z.B. LPC11C-Reihe Wenn er aber nur einen Master hat, spricht auch nichts gegen RS485. Der Master kann ganz gediegen alle Slaves abklappern. Bei dem langsamen Refresh von 5 Minuten kann er auch noch zyklisch überprüfen ob neue Sensoren dazugekommen sind indem er z.B. alle Adressen in seinem Protokoll abklappert.
Bei CAN könnten halt alle Sensoren ihre Nachrichten verschicken wann sie gerade Lust haben. Hätte aber auch den Nachteil dass Du evtl. eine Art Synchronisationsmechanismus benötigst. Wie gesagt, RS485 würde sich hier auch anbieten. Und die Treiber sind nicht gerade groß.
Basti schrieb: > Daher benötige ich keine kontrolle, das nicht mehrere > gleichzeitig reden etc. Stimmt, aber einen Bustreiber brauchst du auch so. Und da kannst du auch gleich einen CAN-Transceiver nehmen, die sind bei Reichelt sogar billiger. Babbel schrieb: > Bei manchen uC noch nicht mal den z.B. LPC11C-Reihe Noch besser. Babbel schrieb: > Wenn er aber nur einen Master hat, spricht auch nichts gegen RS485. Aber auch nichts gegen CAN. Nur dass CAN praktischerweise auch gleich eine CRC mitberechnet und nach ID's filtern kann etc. Auch wenn man das nicht unbedingt braucht, schaden tut es nicht... Babbel schrieb: > Hätte aber auch den Nachteil dass Du evtl. eine Art > Synchronisationsmechanismus benötigst. Ist kein Problem. Manche CAN-Controller (zB die im STM32) können sogar dafür sorgen dass man zB die ADC-Wandlung der Sensor-Werte auf allen Knoten in genau der selben µs startet, auch wenn der Controller zum Zeitpunkt der Nachrichtenankunft beschäftigt war und nicht sofort die Wandlung starten konnte. CAN bietet hier eigentlich nur Vorteile, bei geringerem Aufwand.
Man merkt das wir hier im Land der Autobauer sind weil so viele mit
ihrem komischen CAN kommen. :)
Wenn es billig werden soll probiere folgendes:
Lös Dich vom UART, denn dafür brauchst Du einen Quarz, der RC-Oszillator
ist zu ungenau als das der zuverlässig funktionieren würde.
Definiere ein simples Protokoll, welches die Bits als kurze und lange
Impulse darstellt. Zum Beispiel 0 => 1-10 ms; 1=> 20-30 ms
Schau nach ob Dein Microcontroller auf normalen GPIOs "Open Collector"
oder so was kann, wenn nicht, dann nimm eine Diode, schalte die so, dass
der Portpin die Busleitung nur nach unten ziehen kann. Ziehe dann die
Busleitung per Widerstand nach oben.
VCC-----------+--------> Bus VCC
R
GPIO O--|<----+--------> Bus Daten
GPIO I--------+
GND-------------------> Bus GND
GPIO O wird immer als Ausgang betrieben und ist normalerweise auf high.
Willst Du Daten schicken, so setzt Du den für die entsprechende Zeit auf
low.
GPIO I wird immer als Eingang betrieben, da siehst die eingehenden
Daten.
Was Du jetzt machen kannst ist einen Master und einige Slaves. Der
Master schickt erst die Adresse des Sensors den er abfragen will, und
liest dann die Bits ein die der Sensor schickt.
Der Sensor wartet einfach auf eine Pause, gefolgt von seiner Adresse,
und schickt dann seine Daten. Auf Wunsch kannst Du sogar noch
Kollisionsdetektion machen.
Das ist alles relativ gemurkst (ähnlich wie CAN) und geht natürlich nur
sehr langsam, aber dafür ist das um Größenordnungen billiger als CAN. Du
brauchst nur eine Diode per Station und irgendwo im Bus einen
Widerstand. Plus Du kannst Dir den Quarz sparen.
>>nur da habe ich noch einen weiteren IC, und weitere Kosten. >CAN >RS485 >LIN oder K-Line BC337 als Treiber der schaltet bis 1A
Christian Berger schrieb: > weil so viele mit > ihrem komischen CAN kommen. :) Guter Witz, dein Vorschlag ist ja überhaupt nicht komisch :-D Christian Berger schrieb: > Das ist alles relativ gemurkst (ähnlich wie CAN) und geht natürlich nur > sehr langsam, aber dafür ist das um Größenordnungen billiger als CAN. Um 1.10€, das kostet nämlich ein CAN Transceiver. Diese Ferengi-Lösung erfordert Prozessorzeit zur Behandlung jedes einzelnen Bits, zur Berechnung von Checksummen etc, ist lahm, kompliziert zu Programmieren und vermutlich deswegen fehleranfällig - wenn einem das die 1.10€ wert ist... CAN ist alles andere als gemurkst, sondern fehlersicher, (vergleichsweise) schnell, und etabliert.
Dr. Sommer schrieb: >> sehr langsam, aber dafür ist das um Größenordnungen billiger als CAN. > Um 1.10€, das kostet nämlich ein CAN Transceiver. Ähm, das läuft mit jedem 80 cent µC. Während ich bei CAN einen µC brauche der CAN kann... was bei weitem nicht jeder ist. Außerdem brauche ich für CAN einen Quarz weil da der Takt ziemlich gut definiert sein muss. Plus in der simpelsten Variante braucht das sogar noch weniger Code als die Ansteuerung des CAN Controllers auf dem STM32. Also simpel und billig ist CAN in aller Regel nicht, und das wollte der Basti.
Christian Berger schrieb: > Ähm, das läuft mit jedem 80 cent µC. Während ich bei CAN einen µC > brauche der CAN kann... was bei weitem nicht jeder ist. Außerdem brauche > ich für CAN einen Quarz weil da der Takt ziemlich gut definiert sein > muss. Tja stimmt wenn man 10.000 davon herstellen will zählen die paar Cent natürlich. Christian Berger schrieb: > Plus in der simpelsten Variante braucht das sogar noch weniger Code als > die Ansteuerung des CAN Controllers auf dem STM32. Da wär ich mir nicht so sicher - und die simpelste Variante bringt natürlich nichts da keine Fehlerkontrolle etc.
Nimm I2C mit sehr langsamem Clock und werde glücklich ;) Braucht im Notfall nicht mal externe Bustreiber/Hardware.
CAN ist bei weitem nicht nur im Automobil im Einsatz. Wer Lust hat schaue bei http://www.can-cia.org CAN in Automation vorbei. Das Protokoll wir auch in der Gebäudeautomatisierung mit langen Leitungslängen verwendet. Anderes Beispiel: Tiefseebohranlagen mit mehreren Km Leitungslänge. Dort sogar mit CANopen oben drauf. Der LPC11xx mit integriertem CAN Transceiver spezifiziert: Clock generation: 12 MHz internal RC oscillator trimmed to 1 % accuracy that can optionally be used as a system clock. Damit kann man CAN bei niedrigen Bitraten durchaus betrieben, Höhere Genauigkeit benötigt man nur bei hohen Bitraten. Manche High Speed Transceiver nach 1198-2 beschränken die minimale Bitrate, dass müsste noch geprüft werden. Noch ein Hinweis. Bei langen Leitungen würde ich nicht auf die Datensicherung verzichten, je nach Anwendung ist vielleicht sogar eine galvanische Trennung der Knoten zu empfehlen. Heinz
Basti schrieb: > Hat jemand schonmal sowas gemacht?? Was soll man darauf sinnvoll antworten ohne nähere Angaben?: Wieviele Sensoren, welcher Art (Schalter, Widerstand, Sensor mit "Intelligenz", sprechen die schon ein Protokoll, hängen die auch noch an einer selber getrickten Schaltung/MC,...) soll es robust sein oder darf auch mal ein falscher Wert ankommen, soll das später erweitert werden, wie lang soll der Bus werden, Stromversorgung der Sensoren über den Bus oder separat, soll das eine einmalige Aktion werden, gehts dir um den Lerneffekt, kennst du dich mit RS232/I2C,CAN,... schon aus, .... Such dir oben aus den bisherigen Antworten aus, was am besten für deinen Zweck passt.
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.