LIN-Bus mit Arduino

[R. H. (breezer)]

Hallo zusammen,

ich versuche gerade einen Automotive Sensor mittels LIN-Bus und einem 
Arduino nano auszulesen.

Als Tranciever kommt ein MCP2004 zum Einsatz welcher an der 
Hardware-Uart vom Arduino hängt und als Master arbeitet.

Der Sensor antwortet auf meine Anfrage, jedoch passt die empfangene 
Antwort im Uart Einganspuffer irgendwie nicht.

Ich sende ein LIN-Bus Start-Bit, eine 0x55 als Sync Byte gefolgt von 
einem Identifier Byte. Als Antwort erwarte ich ein Byte vom Slave, im 
Einganspuffer vom Arduino befinden sich jedoch zwei Byte.

Ich habe zwei Scopes, einmal mit angeschlossenem Slave und Response, 
einmal ohne Slave und entsprechend ohne Response.

Irgendwie komme ich mit dem Flanken interpretieren nicht weiter, kann 
mir jemand sagen was da als Response gesendet wird?

Im Uart Einganspuffer befinden sich 4 Byte, die zwei vom Master 
gesendeten plus zwei empfangene: 0x55, E7, C0, 57

[H.Joachim S. (crazyhorse)]

Meinst du einen echten Lin-Bus? Das geht mit der üblichen UART sowieso 
nicht. Beim Lin wird bitweise zurückgelesen und mit dem verglichen, was 
eigentlich gesendet wurde (Kollisionserkennung, ähnlich wie beim CAN).

[fop (Gast)]

Paperlapap. Fast Jeder macht Lin mit einem Uart. Man muss halt in der 
Software darauf gefasst sein, dass Alles, was man sendet umgehend auch 
empfangen wird. Schwieriger ist da schon die Erzeugung des Sync-Break. 
Aber das hat der Fragesteller ja schon längst gemeistert.
Was ihn verwirt ist wohl die Prüfsumme der Lin-Botschaft, die hinter den 
Nutzdaten noch kommt.

[fop (Gast)]

https://elearning.vector.com/index.php?&wbt_ls_seite_id=819818&root=376493&seite=vl_lin_introduction_de

[R. H. (breezer)]

Danke für die Antworten. Ja es stimmt das letzte Byte ist die 
Checksumme, ist alles korrekt so. Danke nochmal.

[Rudolph (Gast)]

H.Joachim S. schrieb:
> Beim Lin wird bitweise zurückgelesen und mit dem verglichen, was
> eigentlich gesendet wurde (Kollisionserkennung, ähnlich wie beim CAN).

Welche Kollisionserkennung? CAN ist Multi-Master, LIN ist Master/Device.
Senden zwei gibt es eben Error-Frames über die Checksumme.

[Alex W. (Gast)]

Rudolph schrieb:
> H.Joachim S. schrieb:
>> Beim Lin wird bitweise zurückgelesen und mit dem verglichen, was
>> eigentlich gesendet wurde (Kollisionserkennung, ähnlich wie beim CAN).
>
> Welche Kollisionserkennung? CAN ist Multi-Master, LIN ist Master/Device.
> Senden zwei gibt es eben Error-Frames über die Checksumme.

Die kann er doch selbst machen, sofern er Hardware-UART nimmt! Einfach 
schauen was beim Senden empfangen wurde. Ist da der Stream falsch -Y 
Kollision

[Rudolph (Gast)]

Alex W. schrieb:
>> Welche Kollisionserkennung? CAN ist Multi-Master, LIN ist Master/Device.
>> Senden zwei gibt es eben Error-Frames über die Checksumme.
>
> Die kann er doch selbst machen, sofern er Hardware-UART nimmt! Einfach
> schauen was beim Senden empfangen wurde. Ist da der Stream falsch -Y
> Kollision

Wofür? LIN hat keine.

[P:S. (Gast)]

Kollisionen können bei Verwendung von Event Triggered Frames auftreten.

[Rudolph R. (rudolph)]

P:S. schrieb:
> Kollisionen können bei Verwendung von Event Triggered Frames auftreten.

Schön. Und?
Es ging nicht darum, dass keine Kollisionen auftreten können, sondern 
das LIN keine Kollisionserkennung auf Bit-Ebene hat.

In dem Sonderfall passt doch auch bestenfalls die Checksumme nicht. Wenn 
die doch passen würde bekäme der Master die Kollision nicht mal mit und 
würde somit mindestens eins von zwei Events verlieren.