LIN Bus als physischer Layer für UART

hi,

LIN-Unit braucht man nicht unbedingt.

Reinhard schrieb:

Der eingesetzte Controller hat keine LIN Unit und dann wird es mit dem Sync und Break ja haarig.

Break lässt sich bei vielen UARTs als Framing-Error detektieren. Easy.

Sync geht mit einem Capture-Timer der einen seiner Inputs auf dem UART-RX Pin legen kann (Bitzeit vermessen). Wenn du allerdings Quarze auf beiden Enden der Kommunikation hast, kannst du auch einfach nur auf die 0x55 warten und brauchst keinen Timer.

MODBUS wäre vielleicht auch eine Alternative zu LIN. LIN-Transceiver ruhig behalten und als Single-Wire-UART-Bus betreiben.

mfg mf

Reinhard schrieb:

Ausbaustufe wären nämlich denkbar mit mehreren Geräten (Display als Master).

LIN ist im physikalischen Layer zu Gunsten einer geringen Störausstrahlung nicht übermäßig schnell. Wenn dir das für deine Anwendung reicht - ok.

Rainer W. schrieb:

LIN ist im physikalischen Layer zu Gunsten einer geringen Störausstrahlung nicht übermäßig schnell. Wenn dir das für deine Anwendung reicht - ok.

Nein ist in Ordnung. Ein paar Byte pro Sekunde.

Also wenn ich proprietär einfach UART sende/empfange sollte es klappen?

Ja. Jeder Knoten sieht auch sein eigenes TX. Der RX-Task muss also wissen ob der Knoten selber sendet, im einfachsten Fall eben RX ignorieren, bis senden fertig. Und, LIN ist nur bis 19200bd spezifiziert. Wird schon. mfg mf

@Achim M: bist du da sicher, dass das funktioniert? So wie beschrieben müsste man doch zwei LIN Master zusammenschalten. Das kann doch nicht gehen. Da wird es sicher zu Kollisionen kommen. Man kann also nicht sicher sein, dass die Nachricht ankommt. Und wenn man das abfangen will, dann kann man auch den LIN rudimentär implementieren. Das ist auch nicht mehr Aufwand. Elektrisch geht aber nichts kaputt. Die LIN-Leitung ist kurzschlussfest.

Bei Microchip gibt es fertige Implementierungen für LIN Master und Slave als App Note. Und bei den anderen kann man das auch finden und portieren. Oder hier: https://github.com/open-LIN/open-LIN-c

Grüße, Jens

Jens W. schrieb:

So wie beschrieben müsste man doch zwei LIN Master zusammenschalten.

mit einem eigenen Protokoll würde auch das gehen, aber anscheinend soll es nur einen Master geben:

Reinhard schrieb:

Ausbaustufe wären nämlich denkbar mit mehreren Geräten (Display als Master).

Wenn Du das halb Duplex im Griff hast (nur einer sendet) brauchst Du nur dafür zu sorgen, dass Dein Ruhepegel Deinen Aktiv-Pegel nicht stört. Also pull-up (oder down) und Diode oder oben drain.

Wenn es langsam ist und Du kein Protokoll selber strickst, kannst Du z.b Can auf einer Leitung nutzen.

Bruno V. schrieb:

Wenn es langsam ist und Du kein Protokoll selber strickst, kannst Du z.b Can auf einer Leitung nutzen.

Die Idee find ich gut

LIN ist auf Basis von UART, also das Protokoll, nicht der physikalische Teil hinter dem Transceiver. Die LIN Einheiten in manchen Controller machen die Software einfacher, ohne geht es aber auch. 8N1 und go

Ein Break lässt sich auch mit einem UART senden, man muss nur die Datenrate so weit senken das 8 Null-Bits aussehen wie 13+ Null-Bits bei der nominellen Datenrate - und das erzeugt auf der anderen Seite wie oben erwähnt einen Frame Error.

Also warum dann nicht gleich LIN implementieren? :-) So mit Break, Sync, ID, Parity und Checksumme.

Wobei ich Sync bisher weitgehend ignoriert habe, auf beiden Seiten ein Quarz und fertig.

Anhand der ID ergibt sich dann ob der Master noch Daten sendet, oder ob der Slave mit Daten + Checksumme antwortet.

Reinhard schrieb:

Wenn es langsam ist und Du kein Protokoll selber strickst, kannst Du z.b Can auf einer Leitung nutzen.

Die Idee find ich gut

Dann suche nach "Single Wire CAN".