LIN-Bus LIN-Treiber-Entwicklung leicht gemacht

LIN-Bus
LIN-Treiber-Entwicklung leicht gemacht

Ob Scheibenwischer, Sitzverstellung, Schiebedächer, Beleuchtung, Fensterheber etc. – der LIN-Bus hat im Fahrzeug Einzug gehalten. Zum einen kann das LIN-Protokoll auf Low-Cost, Low-Performance 8-Bit Mikrocontrollern oder ASICs implementiert werden. Ein zusätzlicher Kostenvorteil ergibt sich durch den möglichen Einsatz preiswerter Keramik- oder R/C-Oszillatoren.
Die im Folgenden beschriebene Treiber-Entwicklung eines Microchip Demonstrations-Boards mit einem Generierungstool von ihr bietet Einblick in die LIN-Welt.

LIN Grundlagen

Der LIN Bus ist ein Eindraht-Bus, der für den Einsatz im Automobil spezifiziert wurde. Es handelt sich um einen offenen Standard, die Spezifikationen sind auf der Plattform des LIN-Konsortiums frei erhältlich. Oft wird der LIN-Bus als CAN-Subbus bezeichnet, da er den Datenverkehr auf dem CAN-Bus reduzieren soll.

Physikalischer Aufbau des LIN-Bus

Mit Batteriespannung versorgt, wird die LIN-Leitung von bis zu 15 Teilnehmern bedient. Die logischen Zustände wechseln zwischen Dominant (0V) und Rezessiv (+12V). Jeder der angeschlossenen Teilnehmer kann prinzipiell die LIN-Bus-Leitung über den Transistor dominant schalten. Keiner der anderen angeschlossenen Teilnehmer kann dann den logischen Zustand rezessiv setzen.

Vermeidung von Kollisionen

Um Kollisionen zu vermeiden, wird die Kommunikation auf dem Bus nach dem LIN-Protokoll realisiert. Beim LIN-Bus wird das Single-Master Multiple-Slave Prinzip angewandt: Die Kommunikation wird vom Master, der genau ein Mal pro Netzwerk zur Verfügung steht, angereizt. Um den angeschlossen Slaves den Beginn einer Nachricht zu signalisieren, sendet der Master einen Dominantpegel mit definierter Mindestdauer (SyncBreak). Durch das darauffolgende Syncfield können sich die angeschlossenen Slaves auf den Takt des Masters aufsynchronisieren. Mit dem anschließenden Identfield spricht der Master den Slave an, von dem er eine Nachricht erwartet. Danach legt der angesprochene Slave seinen Dateninhalt von bis zu acht Bytes auf den Bus.

Ablauf des zyklischen Austausches der Botschaften

Ein Message Frame besteht aus einem Header und einem Datenfeld mit Prüfsumme. Bild 3 zeigt den Ablauf des zyklischen Austausches der Botschaften im LIN Netzwerk. In Frame A fordert der Master eine Nachricht von Slave 1 an, Frame B beantwortet der Master selbst und Frame C beantwortet Slave 2. Danach wird wieder mit Frame A eine Nachricht von Slave 1 angefordert. Dieser Ablauf ist in der Schedule Table definiert. Die Klartextbeschreibungssprache LDF (LIN Description File) für die Busumgebung nimmt eine wichtige Rolle ein. Sie definiert das LIN-Protokoll, Baudrate, die Busteilnehmer (Master & Slave), die Signale mit physikalischer und logischer Beschreibung sowie die Message Frames, mit denen die Signale übertragen werden. Die Syntax ist Bestandteil der LIN Spezifikationen.

Umsetzung einer LIN Applikation mit Hilfe eines Demo Boards

Anhand eines Demo-Boards von Microchip in Verbindung mit einem LIN Treiber Generierungstool von ihr werden die einzelnen erforderlichen Schritte durchgeführt – zur Erstellung eines exemplarischen LIN-Projekts. Ziel ist es, den Zustand des Potentiometers auf dem Demo Board auszulesen, sowie die darauf befindlichen Leuchtdioden mit dem LIN-Protokoll anzusteuern. Das Demo-Board ist dabei der Slave, mit einem PIC16 Mikrocontroller und einem LIN Transceiver. Bild 5 stellt die unterschiedlichen Schichten in dem Projekt dar: Der Physical Layer wird durch den LIN-Transceiver MCP2021 bedient, im Data Link Layer wird der LIN Treiber mit Hilfe des LIN Treiber Generierungstools erzeugt. Die Syntax der API-Schnittstelle zur Applikation ist in den LIN Spezifikationen definiert, d.h. nach Veröffentlichung des LDF-Files sind die Signalnamen und Übergabeparameter für das Projekt bereits festgelegt. Das LIN-Treiber Generierungstool liest das vom Kunden bereitgestellte LDF File ein und überprüft die Syntax mit dem eingebauten Parser. Der Software-Ingenieur wählt das Mikrocontrollerderivat und dann den Knoten aus, der mit der LIN Applikation erstellt werden soll. Im Fall des Demoboards ist das der Demo_Slave Knoten. Das Generierungstool erkennt die Parameter des dazugehörigen LIN Knotens wie LIN Protokoll, SupplierID, FunctionID, die im LDF File hinterlegt sind. Als Resultat erhält man Headerfiles und C-Code, und kann sofort mit der Umsetzung der Applikation beginnen. Die main.c mit der Applikation ist Bestandteil des Demos und benutzt die LIN API. Bild 7 zeigt einen Auszug aus der main.c: Die Funktion l_bool_rd_SetLed() ist die nach der LIN API erzeugte Schnittstelle zu dem LIN-Signal SetLED aus dem LDF File. Entsprechend dem Signalinhalt wird die LED gesetzt oder gelöscht.

Testen der Applikation

Bild 8 zeigt einen Bildschirmauszug der Datenanalyse des laufenden Projekts. Der Frame LED_Command ist der Frame des Masters zum Slave mit den Steuercommandos und der Frame Slave_Response beinhaltet die Signale, die der Slave zum Master sendet. In den Fenstern Demo_LED_Command und DEMO_LED_Response werden die Signalinhalte dargestellt. In dem hier dargestellten Projekt „LED Applikation“ ist nur ein kleiner Ausschnitt aus den LIN Spezifikationen beschrieben. Ein weiterer Teil der Spezifikationen widmet sich der Knotenkonfiguration (Node Configuration) und der Diagnose mit dem dazugehörigen Transport Protocol Layer. Der Projektverantwortliche kann sich durch die Anwendung des ihr LIN-Treiber-Generierungstools voll auf die Applikation konzentrieren und sich auf die LIN-Konformität der Treiberebene verlassen.

ihr GmbH
www.ihr.de

Das könnte Sie auch Interessieren