Hallo,
ich hab hier eine Anzahl Knoten die dicht beieinander liegen, also eine
zweidrahtanbindung wie mit CAN eigentlich nicht erforderlich ist, und
auch die 9600 Baud eines LIN Bus würden eigentlich reichen. Ca. 8
Teilnehmer.
Jetzt ist es aber so dass jeder bessere uC einen CAN-contoller intus
hat, und man dazu nur noch einen PHY braucht. CAN wäre aber eben ein
wenig übertrieben.
Aber was macht man wenn man LIN machen wollen würde? uC mit LIN hab ich
noch nicht gesehen. In Software implementieren?
Oder was würde man sonst so nehmen? Ein Zentraler Punkt (Master darf man
ja nicht mehr sagen), ca. 8 Teilnehmer am Bus, 9600 Baud würden reichen.
Ca. 2m max Abstand, aber durch die 8 Teilnehmer doch ca. 10m Kabel.
Was mir bei LIN nicht gefällt sind die Pull-Down-Treiber mit Pull-up-R
wie bei I2C. Dazu sind die Kabel fast ein wenig zu lang.
Was gäbe es sonst noch was ich bisher übersehen habe?
Ein zentraler uC mit 8 UARTs und davon sternförmig zu den Slaves? Wäre
eine Möglichkeit. Und ist leicht zu debuggen.
Aber gäbe es etwas was irgendwie "moderner", "eleganter", "up-to-date",
"ausbaufähig", etc. wäre? Nur um die vermuteten Argumente meiner
Kollegen vorweg zu nehmen.
Wäre schon schön wenn sich die Teilnehmer auch selbstständig beim
zentralen Punkt melden können, aber erforderlich ist das nicht
unbedingt.
Oder doch CAN auch wenn es fast ein wenig übertrieben ist?
rs485 und dann als Protokoll Modbus.
damit kannst du dann deine Unter Knoten auch einfach am PC testen.
und 9600 sind verdammt langsam (finde ich) sobald du funktionen wie
Firmware Update deiner Knoten brauchst wirst du über höhere Baudrate
nachdenken
:_)
Blume, bleib Gesund
asd schrieb:> CAN wäre aber eben ein> wenig übertrieben.
"Übertrieben" ist kein relevanter Gesichtspunkt, die Frage ist nur
welche Kosten ein Knoten verursacht. Der zusätzliche Draht für 2
Leitungen wird auch nicht gleich in den Ruin führen.
Georg
asd schrieb:> Ein zentraler uC mit 8 UARTs und davon sternförmig zu den Slaves?
Irgendwas passt da nicht: 2 Leitungen für CAN sind zu aufwendig, aber
2x8 separate nicht?
Bei 8 slaves ist die erste Frage, wie Du adressierst:
per Konfiguration (DIP, Adressen),
Per Steckplatz (Stecker),
per Daisy Chain
oder alle Devices sind unique (verschiedene Typen).
Rein seriell (Rx/Tx)geht auch alles: 1 Leitung insgesamt und alle TX per
Diode entkoppelt,
1 Leitung Daisy Chain, getrenntes RX/TX, 8 Doppelleitungen.
asd schrieb:> uC mit LIN hab ich> noch nicht gesehen. In Software implementieren?
So ist es. LIN ist quasi UART mit ner SW-Lib.
Auch RS-485 benötigt nen Haufen SW zum stabilen Arbeiten.
Den geringsten SW-Aufwand hat CAN.
Peter D. schrieb:> Den geringsten SW-Aufwand hat CAN.
Und auch auf HW Seite schaut es nicht schlecht aus. Transceiver dran und
fertig ist ein robuster Bus. In Einzelstückzahlen ist ein lin
transceiver wahrscheinlich nicht viel billiger, kann dafür aber nichts
besser.
Würde dir auch CAN empfehlen, die uC gibt's ab 1-2 Euro und die
Verdrahtung bei 8 Geräten ist auch praktischer, verdrillte Strippe und 2
Abschlusswiderstände. Wenn man einen 5V kompatiblen Controller nimmt,
braucht man nicht mal extra 3,3V als Versorgung mit einbauen. (z.B.
ATSAMC21E15A)
Edit: sehe gerade der ATSAMC21E15A hat sogar LIN mit drin
Ich würde CAN nur dann empfehlen, wenn Deine Anwendung entweder dem
Geist von CAN entspricht (Unique-Telegramme, die selten und priorisiert
sind etc.) oder Du Zugriff auf ein Protokoll hast und Erfahrung damit.
Oder wenn Du Dich aus privaten Gründen mit CAN beschäftigen willst.
Einfach so 1 Master und 8 gleiche Slave ist in "Roh-CAN" auch übles
gebastel. Und robust ist CAN im Vergleich z.B. zu 485 nicht, sobald die
Strecken länger werden.
CAN ist von der Entwicklung her definitiv am einfachsten, die Frage ist
ob du wirklich die paar Cent für die Transceiver sparen musst.
asd schrieb:> Ca. 2m max Abstand, aber durch die 8 Teilnehmer doch ca. 10m Kabel.
Das ist gar nicht so wenig. Hast du starke Störer in der Nähe, z.B.
Elektromotoren? Dann ist CAN definitiv das Mittel der Wahl.
A. S. schrieb:> Einfach so 1 Master und 8 gleiche Slave ist in "Roh-CAN" auch übles> gebastel
Kann ich nicht bestätigen. Man vergibt unterschiedliche IDs an die
Slaves, und der Rest geht von alleine. Genau dafür ist CAN eigentlich
gemacht...
A. S. schrieb:> Unique-Telegramme, die selten und priorisiert> sind etc.
Das schöne am CAN ist, er arbeitet noch bis 100% Buslast stabil.
Man braucht keine Zeitslots, um die Senderichtung umzuschalten und
darauf zu warten, ob der Slave was zu senden hat. Der Slave stellt
einfach die Daten in den Sendepuffer, wenn es ihm paßt.
Man kann auch ganz einfach über Bits im Identifier den Nachrichten
Prioritäten vergeben.
A. S. schrieb:> Und robust ist CAN im Vergleich z.B. zu 485 nicht, sobald die> Strecken länger werden.
Das kommt immer drauf an, was "längere Strecke" bedeutet.
100m bei 250kbit/s bzw. 500m bei 125 kbit/s sollte doch für viele
Anwendungen reichen, insbesondere wenn es sich um Knoten handelt, die
"dicht beieinander liegen".
Peter D. schrieb:> A. S. schrieb:>> Unique-Telegramme, die selten und priorisiert>> sind etc.>> Das schöne am CAN ist, er arbeitet noch bis 100% Buslast stabil.
Das würde ich gerade für den CAN so nicht sagen. Der Bus an sich ist
schon stabil, und die Datenrate bricht nicht ein, wie z.B. bei Ethernet.
Aber bei 100% Buslast kommen die Botschaften mit den höheren IDs halt
nicht mehr durch. Schon bei deutlich geringeren Lasten können solche
Botschaften ggf. deutlich verzögert werden. Es sei denn, man legt da
noch ein Protokoll drauf, das koordiniert, wer wann senden darf, also
time-triggered CAN, aber das schließt du ja damit aus:
> Man braucht keine Zeitslots, um die Senderichtung umzuschalten und> darauf zu warten, ob der Slave was zu senden hat.
Kann man auch als Vorteil von LIN sehen. Man weiß genau, wer wann was
senden wird, weil das vorher in einem Schedule definiert wurde.
CAN ist an sich nicht echtzeitfähig, funktioniert aber bei moderaten
Buslasten in der Regel gut genug.
asd schrieb:> Aber was macht man wenn man LIN machen wollen würde? uC mit LIN hab ich> noch nicht gesehen. In Software implementieren?
µC mit LIN sind genauso gängig. Renesas RL78, RH850, Nec V850, Freescale
S9, S12, NXP, STM, ...
Eine LIN-Zelle ist im wesentlichen eine UART, hat aber ein paar
Funktionen zur Erzeugung und Erkennung des Sync Break und ggf zur
automatischen Anpassung der CPU-Taktrate an den Bustakt. LIN kann man
auch mit einer normalen UART machen, wenn man zur Erzeugung des Sync
Break temporär die Baudrate halbiert und 0x80 sendet und zur Erkennung
desselben auf 0x00 plus Framing Error prüft. Mit dem 0x55 direkt
dahinter ist das hinreichend eindeutig.
LIN-Transceiver sind kurzschlußfest und eigensicher, ein Transistor nach
Masse tut's funktional aber genauso.
Hallo Leute,
vielen Dank für die Diskussion. Jetzt kann ich sicher sein dass ich zu
dem Thema nichts offensichtliches übersehen habe (was dann Jahre später
zu einem Hand-an-die-Stirn-klatsch Moment führen könnte).
Vermutlich wird es eine Sternverdrahtung werden mit einem
(Software-)UART pro Knoten, oder eben doch CAN.
asd schrieb:> Vermutlich wird es eine Sternverdrahtung werden mit einem> (Software-)UART pro Knoten, oder eben doch CAN.asd schrieb:> Wobei mir RS-485 auch sympathisch ist...
Den höchsten Durchsatz, automatische Adressierung, kleinste
Leitungslängen und größte Störfestigkeit (allerdings längere
Antwortzeiten) hast Du mit einem Ring. Also Master und Slave je einen
Uart, Rx links, Tx rechts. Und vom Master Tx zum ersten Rx .... bis das
Tx vom letzten Slave zum Rx des Master kommt.
Erfordert ein paar ungewöhnliche Gedanken, ist dann aber das
störfesteste Überhaupt, weil Unidirektional und kurz.
Der Nachteil: Punkt-Zu-Punkt Verdrahtung, wenn einer ausfällt, dann
steht der Ring.
Der Vorteil: PUnkt-Zu-Punkt Verdrahtung, wenn einer ausfällt weiß man
direkt wo. Bei Bussen reicht ein Kurzschluss irgendwo und man sucht ...
und sucht ...
