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.
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.
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.
