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: > Aber was macht man wenn man LIN machen wollen würde? uC mit LIN hab ich > noch nicht gesehen. Dann guck mal die SoCs der Autobauer an. Da ist dann z.B. neben LIN auch gleich die Endstrufe für den Aktuator mit integriert. z.B. https://www.melexis.com/en/product/mlx81310-mlx81315/smart-lin-driver
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
:
Bearbeitet durch User
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 ...
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.