Projekt 76: LIN Demonstrator

→ zurück zur Übersicht: WS 18/19: Fachpraktikum Elektrotechnik (BSE)

Autoren: Blunck, Schaffer
Betreuer: Prof. Schneider

Aufgabe

Sensoren und Aktoren eines Kfz sollen über einen LIN BUS angesteuert werden. Visualisieren Sie die Daten mit CANoe.

Erwartungen an die Projektlösung

Recherche zum LIN BUS
Beschaffen Sie kostenlos LIN fähige Sensoren und Aktoren aus dem Kraftfahrzeug (Sponsoring, Schrottplatz)
Ein Arduino mit LIN Shield soll einen Sensor auslesen und einen Aktor ansteuern.
Überwachen Sie den Datenverkehr mit CANoe.
Test und wiss. Dokumentation
Live Vorführung der Kommunikation

Hinweise:

Dieses Projekt ist nur mit viel Kreativität und Eigeninitiative zu lösen. Sie sollten Spaß an Bussystemen im Kraftfahrzeug haben.
Dieses Projekt wurde zweifach vergeben. Stimmen Sie sich mit dem anderen Team ab, damit zwei unterschiedliche Demonstratoren entstehen.

Einleitung

In diesem Projekt wird ein LIN - Demonstrator entwickelt und ein Aktor mithilfe des LIN-Protokolls angesteuert. Der LIN - Demonstrator wird mithilfe von ausgewählten Bauteilen aufgebaut. Die verwendeten Bauteile sind in einem nachfolgenden Kapitel dargestellt. Als Aktor wird ein Xenon Scheinwerfer eines Audi Q7 verwendet. Der Xenon Scheinwerfer kann über einen Schrittmotor in horizontaler und vertikaler Richtung verstellt werden. Als Kommunikationsprotokoll wird das LIN-Protokoll verwendet, um Nachrichten zwischen zwei Mikrocontroller zu versenden. Die Mikrocontroller (Arduino Uno) dienen dabei stellvertretend als Steuergeräte.

Grundlagen LIN - Protokoll

In diesem Kapitel werden einige Grundlagen zum Verständnis dieses Projektes erläutert. Für dieses Projekt muss die Funktionsweise und der Aufbau des LIN-Bus bekannt sein. Hinzu muss für diese Kommunikation die Zweidrahtkommunikation des Arduinos auf eine 1-Draht kommunikation umgewandelt werden, wofür der LIN-Transceiver benötigt wird.

Funktionsweise LIN-Bus

LIN (Local Interconnect Network) ist ein junges Bussystem, das ende der 90er Jahre entwickelt wurde. Es wird für einfache Sensor-Aktor-Anwendungen mit relativ geringen Echtzeitanforderungen verwendet, wie zum Beispiel der Tür-, Sitz- oder Schiebedach-Elektronik oder der Ansteuerung des Scheinwerfers eines Autos. Der LIN-Bus ist die kostengünstige Alternative zu dem Low-Speed-CAN Bussystemen. Auf der Bitübertragungsschicht kommt eine UART-Übertragung(8 Datenbits, 1 Startbit, 1 Stoppbit) zum Einsatz. Mögliche Bitraten liegen im Bereich von 1 bis 20 kbit/s. Das LIN-Bussystem besteht aus einem Master-Knoten, der i.d.R gleichzeitig Gateway zu einem übergeordneten CAN-Netzwerk ist. Alle restlichen Knoten sind Slave-Knoten, die nach Anforderungen des Masters ihre Datenpakete verschicken können. Jeder LIN-Knoten beherbergt in der Software eine Slave Task und der Master Knoten besitzt ebenfalls eine Slave-Task und zusätzlich den Master-Task. Zusätzlich besitzt der Master-Knoten ein LIN-Schedule, was ein hinterlegter Zeitplan ist, in dem festgelegt ist, welcher Slave wann abgefragt werden soll, die sogenannten Frame Slots. Zu Beginn eines Frame Slots sendet der Master den Frame Header, der von dem passenden Slave Task zu einem LIN Frame komplettiert wird.

In der Abbildung 1 ist das LIN-Kommunikationsprinzip dargestellt. Der Master-Knoten sendet den Header auf den Bus. Die Slaves hören den Bus ab und erkennen anhand des Headers, ob sie antowrten müssen oder nicht. Muss ein Slave antworten, fügt seine Response hinter den Header. Zwischen Header und Response befindet sich jeweils ein Response Space und zwischen einer Response und einem Header befindet sich ein Interframe Space. Das sind jeweils willkürliche Bits, die nicht direkt zum LIN-Protokoll gehören.

Der Aufbau eines LIN-Frames ist in der Abbildung 2 dargestellt. Einzuteilen ist das Frame in einen Header und eine Response. Der Header wird von dem Master und die Response von dem Slave erstellt. Im Folgenden wird der genaue Aufbau des LIN-Frames dargestellt.

Kommunikationsprinzip LIN-Bus
Abb. 1: LIN Kommunikationsprinzip
Abb. 2: LIN Frame Struktur

Header

Der Header besteht aus dem Break-Field, dem SYNC-Field und dem Protected-Identifier-Field. Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante-Bits (logisch 0) und anschließen 1 Delimeter-Bit (logisch 1) gesendet. Auf das Break-Field folgt das SYNC-Field. Sync wird definiert als das hexadezimale Zeichen x55. Das Sync-Feld ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren. Das Protected-Identifier-Field ist das letzte, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen.

Response

Die Response besteht aus dem Response Space, den data-fields und der checksum. Der Response Space ist wie oben erklärt eine zufällige Bitfolge, die aufgrund des zeitlichen versatzes zwischen dem Header und der Response befindet. Auf den Response Space folgt das data-field. Das Data field besteht aus einem Startbit, 8 Datenbits und einem Stoppbit. Die Übertagung des Datenbits erfolgt über das Little-Endian Prinzip, d.h das LSB(least significant Bit) wird als erstes eingefügt. Es könne bis zu 8 Nutzdatenbytes eingefügt werden. An letzter Stelle der Response befindet sich die Checksum. Die Checksum dient zur Überprüfung der erfolgreichen Übertragung. Mittels Modulo-256-arithmetik wird die Checksum gebildet. Die einzelnen Datenbytes werden per Modulo-256-Arithmetik addiert wobei jedes überlaufende Bit zum jeweiligen Zwischenergebnis addiert wird. Schließlich wird das Gesamtergebnis inverteirt und als Checksum in die Response eingefügt. Ein Empfänger führt denselben Algorithmus bis auf die Invertierung mit den empfangenen Datenbytes durch. Falls die Summe aus den Datenbytes und der Checksum nicht 0xFF ist, hat ein Übertragungsfehler stattgefunden und die Kommunikation muss erneut durchgeführt werden.

Funktionsweise LIN-Transceiver

Beschreibung

Für das Projekt wird der LIN-Transceiver MCP2004 der Firma Microchip verwendet. Dieser Transceiver stellt eine physikalische Schnittstelle zwischen einem Mikrocontroller und einem LIN-Bus dar. Dafür wandelt er die CMOS/TTL-Logik des Mikrocontrollers in die passende LIN-Bus-Logik um und umgekehrt. Für die Kommunikation zwischen Mikrocontroller und Transceiver wird die USART-Schnittstelle des Arduino Unos genutzt.

Der LIN-Transceiver MCP2004 hat folgende Eigenschaften:

Kompatibel mit LIN-Bus-Spezifikationen 1.3, 2.0, 2.1, SAE J2602
Unterstützung von Baudraten bis zu 20Kbaud
Schutz gegen 43V Spannungsspitzen (bspw. Lastabwurf bei der Lichtmaschine)
ESD & EMI geschützt
Versorgungsspannung: 6.0V bis 27.0V
Temperaturbereich: -40°C bis +125°C

Aufbau

Abb. 4: Blockschaltbild des LIN-Transceivers

Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschluss-Schutz und ein Abschaltmechanismus, beim Erreichen von zu hohen Temperaturen, verbaut sind. Der LIN-Bus Pin ist gegen Kurzschlüsse und Verlust des Erdpotentials (Ground) gesichert. Intern ist dieser mit einer Diode und einem Pull-Up-Widerstand versehen.

Weiterführend zeigt die Abb. 5 die Belegung der Anschlusspins am PDIP-Gehäuse.

Abb. 5: Anschlusspins des LIN-Transceivers

Pin 1: Receive Data Output
Pin 2: Chip Select
Pin 3: Fault reporting/TXD Dominant Time-out
Pin 4: Transmit Data Input
Pin 5: Ground
Pin 6: LIN Bus
Pin 7: Battery Positive
Pin 8: Voltage Regulator Enable Output

Betriebsarten
Der LIN-Transceiver unterstützt folgende Betriebsarten:

POWER-DOWN MODE
READY MODE
OPERATION MODE
TRANSMITTER OFF MODE

Abb. 6: Zustandsdiagramm der Betriebsarten

Damit der Transceiver Daten zwischen Mikrocontroller und dem LIN-Bus vermitteln kann, ist es notwendig den PIN 2 (Chip Select / CS) auf "High" zu setzen. Dafür kann ein digitaler Pin oder die 5V Spannung vom Arduino eingesetzt werden. Der Tranceiver bleibt dadurch im Modus "Operation Mode" und lässt den Transmitter durchgängig aktiv. Dieser Vorgang wird jedoch nur für dieses Projekt angewandt und sollte für andere Anwendungen entsprechend angepasst werden.

Anwendung

Abb. 7: Schaltplan zur Anwendung
Abb. 8: Aufbau eines LIN-Netzwerks

Um mit Hilfe des Transceivers Daten senden zu können, wird dieser wie in der Schaltung aus Abb. 7 mit einem Mikrocontroller verbunden. Die Abb. 8 zeigt das LIN-Netzwerk, welches einen Master und mehrere Slaves enthält. Dabei ist jedoch darauf zu achten, dass nach der LIN-Spezifikation 2.1 die Transceiver aller Geräte im Netzwerk durch den LIN-Pin und das Erdpotential (Ground) miteinander verbunden sind. Insgesamt sollte das Netzwerk einen maximalen Abschlusswiderstand zwischen Lin-Bus und Batteriespannungsversorgung von 510 Ohm aufweisen. Die 510 Ohm entsprechen einem Netzwerk von einem Master und 15 Slaves.

Projektdurchführung

In diesem Kapitel wird die eigentliche Projektdurchführung des Projekts beschrieben. Nach und nach werden die einzelnen Testergebniss bis zum fertigen Endergebnis dargestellt.

Projektplan

Der für unser Projekt verwendete Projektplan ist in der Abbildung 9 dargestellt und wird nun erläutert.

Abb. 9: Projektplan

Die als Raute dargestellten Ereignisse sind Meilensteine, wie zum Beispiel die Abschlussmesse oder der Erhalt der Bauteile. Hinzu war es uns sehr wichtig während des gesamten Semesters kontinuierlich zu arbeiten, was zum Beispiel an der Dokumentation oder der Recherche zu sehen ist. Es kann gesagt werden, dass wir anhand des Projektplans unser Projekt zeitlich passend fertigstellen konnten. Unsere Einteilung des Projektes zu Beginn konnte kontinuierlich abgearbeitet werden.

Verwendete Bauteile

Anzahl	Bauteil
2	12 V DC Netzteil
2	Arduino Uno
1	Audi Q7 Scheinwerfer
1	Steckbrett
1	Steckbrücken-Drahtbrücken Set
1	Motor Stepper Servo Shield
2	LIN-Transceiver
2	220 kOhm Widerstände
2	4.7 kOhm Widerstände
2	50 Ohm Widerstände
2	1 kOhm Widerstände
2	100 nF Kondensator
2	220 pF Kondensator
2	1 µF Kondensator
4	Standarddiode 1N4148

Scheinwerfer als LIN fähigen Aktor

Im Folgendem Abschnitt wird ein Versuchsaufbau erläutert, um den Scheinwerfer für das Projekt als LIN fähigen Aktor verwenden zu können. Dafür wird zunächst der Aufbau des Scheinwerfers beschrieben und ein Versuch für die Ansteuerung erklärt.

Anschlussplan

Anschlussplan des Scheinwerfers
Abb. 10: LIN Kommunikationsprinzip
Abb. 11: Stecker für die Schrittmotoren

Versuchsaufbau "Erste Inbetriebnahme"

In diesem Kapitel ist der Versuchsaufbau zum Ansteuern des Audi Q7 Scheinwerfers dargestellt. Die Abbildung 8 enthält hinzu die Beschriftung der einzelnen Bauteile.

Anschlussplan des Scheinwerfers
Abb. 12: Versuchsaufbau Scheinwerfer
Abb. 13: Schaltplan Versuchsaufbau

Damit der Scheinwerfer als Aktor eingesetzt werden kann, wurde dieser zunächst in Betrieb genommen. Dafür wurden die Anschlüsse (Abb. 6 u. 7) für die Spannungsversorgung und die Schrittmotoren identifiziert. Anschließend folgte der Aufbau der ersten Inbetriebnahme nach dem Schaltplan aus Abb. 9.

Versuchsdurchführung

Zu Beginn des Versuchs wurde der Xenon-Brenner an die Spannungsversorgung angeschlossen. Damit der Xenon-Brenner jedoch korrekt betrieben werden kann, wird ein Netzteil mit 12 V DC und 10 A benötigt, da beim Einschaltvorgang eine höhere Stromaufnahme (etwa 8 A) vorliegt als im weiteren Betrieb (etwa 3,5 A). Nachdem die Funktionsfähigkeit des Xenon-Brenners bestätigt werden konnte, wurden die Anschlüsse für das Fernlicht und für den Blinker an die Spannungsversorgung angeschlossen. Auch hier konnte eine erfolgreiche Inbetriebnahme festgehalten werden. Im nächsten Schritt wurde die Verstellung des Kurvenlichts getestet. Dafür kam ein Arduino Uno mit Motor-Shield zum Einsatz, weil die Schrittmotoren für die vertikale und horizontale Verstellung angesteuert werden mussten. Das Motor-Shield hat die Möglichkeit zwei verschiedene Schrittmotoren anzusteuern und diese bei Bedarf mit einer externen Spannungsquelle zu versorgen. Der Schaltplann in Abb. 9 zeigt die Verkabelung für die jeweiligen Schrittmotoren.

Kommunikation zweier Arduinos über LIN-Bus

In diesem Kaptitel wird die Kommunikation über einen LIN-Bus mit 2 Arduinos (Master und Slave) getestet. Zu Beginn wird der Programmablaufplan mithilfe eines PAP-Designs grafisch dargestellt und anschließend wird dargestellt, wie die Kommunikation Programmtechnisch umgesetzt ist. Anschließend wird der Versuchsaufbau mit der Versuchsdurchführung erläutert. Abschließend werden zwei LIN-Shields entwickelt, auf denen die Schaltungen des Masters und des Slaves platziert werden sollen.

Versuchsaufbau

In den Abbildungen 10 bis 12 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 11 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.

Versuchsaubau Test LIN-Nachricht
Abb. 14: Versuchsaufbau Kommunikation Schaltungsaufbau
Abb. 15: Versuchsaufbau Kommunikation Oszilloskop
Abb. 16: Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt

Test der Kommunikation

Zuerst wurde lediglich der Master(Arduino in Abbildung 10) getestet. Von dem Master werden die Werte 99 und 123 mithilfe der ersten beiden Datenbytes auf den LIN Bus gelegt. Das Ergebnis lässt sich in der Abbildung 11 sehen. Das gemessene Signal am Oszilloskop zeigt das typische Muster eines LIN-Protokolls. Zuerst werden in unserem Beispiel 16 dominante Bits (logisch 0 - ca. 1V) gesendet. Die rezessiven Bits (1) entsprechen ca. 12V, die an dem Bord und somit an den LIN-Transceivern angelegt werden. Mithilfe des in der Abbildung 12 dargestellten Versuchsaufbaus ist es nun möglich ziwschen dem rechten Arduino (Master) und dem linken Arduino (Slave) zu kommunizieren. Der LIN-Bus ist das grüne Kabel. Mit diesem Ergebnis wird nun in dem nächsten Kapitel der Audi Q7 Scheinwerfer mithilfe des LIN Protokolls angesteuert.

Ansteuerung des Kurvenlichts über LIN-Bus

In diesem Kapitel wird die eigentliche Aufgabe dieses Projektes durchgeführt. Mithilfe des LIN-Protokolls wird der Schrittmotor des Xenon Brenners angesteuert und die Kommunikation zwischen dem Master und Slave des LIN-Bus mithilfe von CANoe überwacht.

Programmablaufplan Master und Slave

In diesem Kapitel sind jeweils die beiden Programmablaufpläne des Masters und des Slaves dargestellt. Zuerst sendet der Master ein festgelegtes Datenpaket an den Slave. Der Slave überprüft das Datenpaket mithilfe der Checksumme auf Richtigkeit. War die Datenübertagung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beipiel wird der Scheinwerfer nacheinander um 100 Einhieten nach links, um 100 nach unten, um 100 einheiten nach rechts und um 100 einheiten nach oben angesteuert. Somit bewegt sich der Scheinwerfer in einem Quadrat.

Programmablaufpläne
Abb. 17: Programmablaufplan Master
Abb. 18: Programmablaufplan Slave

Software Programm

Das Programm, dass auf dem Master und auf dem Slave ausgeführt wird, kann unter dem nachfolgenden SVN-Link eingesehen werden:

SVN-LINK Arduino Programm

Versuchsaufbau und Versuchsdurchführung

Der Versuchsaufbau zum Ansteuern des Kurvenlichts wird in diesem Kapitel erklärt und ist in der Abbildung 19 zu sehen. An dem Scheinwerfer und an den Anschlüssen des Steckbretts werden 12V angelegt. Die Arduinos erhalten die Betreibsspannung über den USB-Anschluss des angeschlossen PCs. Der Master-Arduino sendet die einestellte Nachricht auf den LIN-Bus und der Slave setzt diese Nachricht um. Der Scheinwerfer wird nun über einen Motortreiber von dem Slave angesteuert.

Überwachen des Datenverkehrs mit CANoe

In diesem Kapitel ist die Inbetriebnahme der Vector Software zum Überwachen des Datenverkehrs dargestellt. Hierzu muss der LIN-Bus mithilfe des in der Abbildung 20 dargestellten Steckers an den PC mit der installierten Software angeschlossen werden. Die Pinbelegung des Steckers kann unter dem folgenden Link eingesehen werden: https://assets.vector.com/cms/content/products/VN16xx/docs/VN1600_Interface_Family_Manual_DE.pdf

CANoe
Abb. 20: Anschlussstecker CANoe
Abb. 21: Ergebnis Überwachung mit CANoe

Die Datenverkehrüberwachung konnte nicht vollständig durchgeführt werden, da wie in der Abbildung 21 dargestellt ein Fehler beim Auslesen auftrat. Der beschriebene Fehler besagt, dass das Delimeter Feld eine inkorrekte Länge hat. Da wir die Baudrate beim Arduino gesenkt haben, um mindestens 13 dominante Bits als Break zu senden ist das Delimeter Feld folglich zwei rezessive Bits anstatt einem rezessiven Bits. Somit kann die Software keine zu 100% exakte LIN-Nachricht erkennen und zeigt deswegen Fehler an. Dieses Problem zu lösen erfordert weitere Änderungen an dem Protokoll, was den Aufwand überschreiten würde.

Entwicklung eines LIN-Shields

In diesem Kapitel werden die, für das Projekt geforderten, Platinen beschrieben. Eine Platine dient dabei als Arduino-Shield für den Master, welches der Schaltung auf dem Steckbrett aus der Abbildung 16 entspricht. Die andere Platine wird für den Slave verwendet und die entsprechende Schaltung kann aus der Abbildung 16 entnommen werden. Um das Vorgehen zu erläutern wird zu Beginn der Versuchsaufbau dargestellt und die Durchführung des Versuchs erklärt.

Platinenlayout

Master LIN-Shield
Abb. 22: 3D-Ansicht Master Shield-Entwurf
Abb. 23: Master Shield-Entwurf Unterseite
Abb. 24: Fertig bestücktes Master Shield

Da eine Anforderung, die Entwicklung eines LIN-Shields für den Arduino, war, wurde für den "Arduino Uno Rev 3" ein passendes Shield mit Hilfe der Software "Ultiboard" entworfen und im Anschluss mittels Fräsmaschine die Platine gefertigt. Die Schaltung entspricht dabei der gleichen, wie aus der Abbildung 16, sodass sichergestellt werden konnte, dass die Schaltung funktionsfähig ist. Die Bauteile wurden vom Steckbrett auf die Platine gelötet und der Transceiver auf einen Sockel gesteckt. Dies hat den Vorteil, dass bei fehlerhafter Bedienung der Transceiver gewechselt werden kann. Außerdem wurden Stiftleisten verbaut, damit das Shield auf den Arduino gesteckt werden kann. Das Shield besitzt des Weiteren Pin-Anschlüsse für die externe Verkabelung (Spannungsversorgung, LIN-Bus).

Slave LIN-Shield
Abb. 25: 3D-Ansicht Slave Shield-Entwurf
Abb. 26: Slave Shield-Entwurf Unterseite
Abb. 27: Fertig bestücktes Slave Shield

Im Gegensatz zu den Master konnte für den Slave jedoch kein Shield entworfen werden, da auf dem Arduino Uno bereits ein Shield für die Ansteuerung der Schrittmotoren befestigt ist. Um dennoch eine saubere Schaltung für das Projekt verwenden zu können, wurde stattdessen eine einfache Platine entworfen, welche alle notwendigen Pin-Anschlüsse für die entsprechenden Schnittstellen des Arduinos usw. aufweist. Ebenfalls wurde auch auf dieser Platine ein Sockel für den Transceiver verbaut, um diesen bei Beschädigungen wechseln zu können.

Funktionstest der Platinen

Nachdem alle Platinen fertigt bestückt wurden, mussten diese schließlich in Betrieb genommen werden, um beispielsweise Beschädigungen durch den Lötvorgang festzustellen. Dafür wurden mit einem Durchgangsprüfer eines digitalen Multimeters zunächst alle Pins durchgetestet, ob diese eventuelle störende Masseverbindungen (außer Erdpotentialanschluss -> Ground) aufweisen. Nach der erfolgreichen Prüfung, wurden die Platinen anschließend nach entsprechender Vorgabe an die Mikrocontroller usw. angeschlossen. Auch dieser Vorgang verlief fehlerfrei, sodass die Platinen mit dem LIN-Bus verbunden wurden. Nach dem Einschalten aller Geräte, konnte der Funktionstest als erfolgreich festgehalten werden. Die Arduinos kommunizierten einwandfrei miteinander und das Kurvenlicht des Scheinwerfers bewegte sich wie gewünscht.

Abb. 28: Funktionstest der Platinen

Ergebnis

Unser Projektergebnis wird in diesem Kapitel dargestellt. Auf der linken Seite befindet sich der Master, der ein erstelltes Datenpaket auf den Bus legt. Das Signal auf dem LIN-Bus ist mit dem Oszilloskop dargestellt. In der Mitte befindet sich ein Netzteil an dem wir 12V einstellen, um den Scheinwerfer anzusteuern und den LIN-Bus mit Spannung zu versorgen. Auf der rechten Seite befindet sich der Slave, der die gesendeten Daten auf dem LIN-Bus. Bei passender, gesendeter ID steuert der Slave den Motortreiber an, der den Schrittmotor nacheinander nach links, runter, rechts und hoch ansteuert (die Richtigen sind in Fahrtrichtung angegeben).

Abb. 29: Ergebnis LIN-Bus

Das Ergebnis ist am besten in dem nachfolgenden Video zu sehen

Zusammenfassung

Lessons Learned

Ausblick

Projektunterlagen

Sämtliche in diesem Projekt verwendeten Unterlagen und Dokumente sind im SVN unter dem nachfolgenden Link einzusehen:

SVN-Link LIN-Demonstrator

YouTube Video

Das Ergebnis dieses Projekts kann unter folgendem YouTube Video entnommen werden:

Projektvideo

Weblinks

Datenblatt LIN-Transceiver MCP2004

Aufbau LIN Nachricht

Literatur