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
:
Verschoben durch Admin
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).
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.
Danke für die Antworten. Ja es stimmt das letzte Byte ist die Checksumme, ist alles korrekt so. Danke nochmal.
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.
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
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. 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.
Bitte 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.