Einleitung

• Entwicklung eines CAN-Treibers für IP460-Module Entwicklung eines CAN-Treibers für IP460-Module mit CAN-Modul TIP816-10mit CAN-Modul TIP816-10

• Entwicklung eines einfachen DemonstrationsmodulsEntwicklung eines einfachen Demonstrationsmoduls

Steer by Wire III (CAN)Steer by Wire III (CAN)David Weese, Philipp ReineckeDavid Weese, Philipp Reinecke

EinleitungEinleitung

Hintergrund:Hintergrund:Nutzung als Schnittstelle zwischen Nutzung als Schnittstelle zwischen Lenkung und Lenkrad im „Steer by Lenkung und Lenkrad im „Steer by Wire“-SystemWire“-System

EMES-Projekt bei Daimler ChryslerEMES-Projekt bei Daimler Chrysler

• Reaktionen in EchtzeitReaktionen in Echtzeit

• HochverfügbarkeitHochverfügbarkeit

• hohe Toleranz gegenüber Umwelteinflüssenhohe Toleranz gegenüber Umwelteinflüssen


allg. Anforderungenallg. Anforderungen

Konsequenz ist CAN-Protokoll wegenKonsequenz ist CAN-Protokoll wegen- KollisionsvermeidungKollisionsvermeidung- vorhersagbaren Reaktionszeiten (für vorhersagbaren Reaktionszeiten (für

hochpriorisierte Nachrichten)hochpriorisierte Nachrichten)


Treiber-AnforderungenTreiber-Anforderungen

Der Treiber sollteDer Treiber sollte

• tatsächliche Hardware weitestgehend abstrahierentatsächliche Hardware weitestgehend abstrahieren

• vom CAN-Modul-Hersteller unabhängig seinvom CAN-Modul-Hersteller unabhängig sein

• Streams für die Kommunikation zur Verfügung stellenStreams für die Kommunikation zur Verfügung stellen


Lösung – Theorie ILösung – Theorie I

Planung der Treiber:Planung der Treiber:

• Anpassung eines bereits existierenden PCI-Treibers für Anpassung eines bereits existierenden PCI-Treibers für Linux, um Fehlerquellen gering zu haltenLinux, um Fehlerquellen gering zu halten

• Entwicklung folgender Treiber:Entwicklung folgender Treiber:- SMC1-Treiber zur seriellen Kommunikation mit den SMC1-Treiber zur seriellen Kommunikation mit den

Terminals und Debug-AusgabeTerminals und Debug-Ausgabe- Raw-Treiber zur binären packetorientierten Raw-Treiber zur binären packetorientierten

Kommunikation über CANKommunikation über CAN- Cooked-Treiber zur zeichenorientierten Cooked-Treiber zur zeichenorientierten

Kommunikation über den Raw-TreiberKommunikation über den Raw-Treiber

• alle Treiber stellen Input-/Output-Streams zur Verfügungalle Treiber stellen Input-/Output-Streams zur Verfügung


Lösung – Theorie IILösung – Theorie II


Lösung – Theorie IIILösung – Theorie III

Planung des Demonstrationsmoduls:Planung des Demonstrationsmoduls:

• muss lediglich SMC1-Stream und Cooked-Stream muss lediglich SMC1-Stream und Cooked-Stream verwendenverwenden

• durch den SMC1-Stream vom Nutzer kommende Texte durch den SMC1-Stream vom Nutzer kommende Texte werden durch den Cooked-Stream über den CAN-Bus werden durch den Cooked-Stream über den CAN-Bus zum anderen Board übertragenzum anderen Board übertragen

• vom CAN-Bus durch Cooked-Stream kommende Texte vom CAN-Bus durch Cooked-Stream kommende Texte werden durch SMC1-Stream zurück zum anderen werden durch SMC1-Stream zurück zum anderen Nutzer gesendetNutzer gesendet


Lösung – Theorie IVLösung – Theorie IV

vorhandene Hardware:vorhandene Hardware:

• IP460-Board mit 32bit MC68040 und IP460-Board mit 32bit MC68040 und MC68360 (Communication Controller) MC68360 (Communication Controller) von Motorolavon Motorola


Lösung – Praxis ILösung – Praxis I

• IP-Modul TIP816 von TEWES IP-Modul TIP816 von TEWES mit integriertem CAN-mit integriertem CAN-Controller i82527 von IntelController i82527 von Intel

• bietet 14 frei belegbare Transmit-/Receive-bietet 14 frei belegbare Transmit-/Receive-Objekte für CAN-Nachrichten und ein Objekte für CAN-Nachrichten und ein exklusives Receive-Objekt (Message Ob-exklusives Receive-Objekt (Message Ob-jekt 15)jekt 15)

• alle Objekte sind nach ID maskierbaralle Objekte sind nach ID maskierbar

vorhandene Software:vorhandene Software:

• Monitorsoftware IP460Mon V2.01 im EEPROM des IP-Monitorsoftware IP460Mon V2.01 im EEPROM des IP-Boards - nimmt Initialisierung der Controller vor und Boards - nimmt Initialisierung der Controller vor und ermöglicht Upload des Treibers über serielles ASCII-ermöglicht Upload des Treibers über serielles ASCII-Protokoll (Quellen unvollständig)Protokoll (Quellen unvollständig)

• TIP816-Linux-Treiber von TEWES für eine PCI-Version TIP816-Linux-Treiber von TEWES für eine PCI-Version des CAN-Controllers mit Quellendes CAN-Controllers mit Quellen

da als Device-Driver geschrieben, enthält dieser da als Device-Driver geschrieben, enthält dieser Funktionen zum Initialisieren, Öffnen, Schließen Funktionen zum Initialisieren, Öffnen, Schließen Schreiben und Lesen (gewisse Abhängigkeit von Unix-Schreiben und Lesen (gewisse Abhängigkeit von Unix-Spezifika)Spezifika)


Lösung – Praxis IILösung – Praxis II

Vorgehensweise:Vorgehensweise:

1.1. Implementation des SMC1-TreibersImplementation des SMC1-Treibers

2.2. Adaption des TIP816-TreibersAdaption des TIP816-Treibers

3.3. Test des Treibers mittels BeispielprogrammTest des Treibers mittels Beispielprogramm

4.4. Implementation des Cooked-StreamsImplementation des Cooked-Streams

5.5. Aufsetzen des DemonstrationsprogrammsAufsetzen des Demonstrationsprogramms


Lösung – Praxis IIILösung – Praxis III

1.1. Implementation des SMC1-TreibersImplementation des SMC1-Treibers• Entwicklung von stabilen IRQ-unabhängigen Ein-/Entwicklung von stabilen IRQ-unabhängigen Ein-/

Ausgaberoutinen (schliesst Fehlerquellen aus)Ausgaberoutinen (schliesst Fehlerquellen aus)• Reverse-Engineering der Monitorroutinen und Reverse-Engineering der Monitorroutinen und

Anpassung mit MC68360 DokumentationenAnpassung mit MC68360 Dokumentationen

2.2. Adaption des TIP816-TreibersAdaption des TIP816-Treibers• Adaption zur KompilierbarkeitAdaption zur Kompilierbarkeit• Beibehaltung der Interfaces (da zweckmäßig)Beibehaltung der Interfaces (da zweckmäßig)• Entfernung der überflüssigen/nicht implementierbaren Entfernung der überflüssigen/nicht implementierbaren

BereicheBereiche

3.3. Test des Treibers mittels BeispielprogrammTest des Treibers mittels Beispielprogramm• Validierung der Treiberfunktion vor Implementation Validierung der Treiberfunktion vor Implementation

höherer Ebenenhöherer Ebenen• Kompilierung nahezu problemlos, Übertragung nicht Kompilierung nahezu problemlos, Übertragung nicht


Lösung – Praxis IVLösung – Praxis IV

Logic Analyser zeigt Spannungsverlauf des CAN-Busses an:Logic Analyser zeigt Spannungsverlauf des CAN-Busses an:• 1. Modul sendet Pakete (meldet errorcounter > 96)1. Modul sendet Pakete (meldet errorcounter > 96)• erfolgreich erkennbar sind Arbitrierungs- und Datenbitserfolgreich erkennbar sind Arbitrierungs- und Datenbits• Arbitrierung scheinbar erfolgreichArbitrierung scheinbar erfolgreich• 2. Modul empfängt keine Pakete, löst keinen IRQ aus, es 2. Modul empfängt keine Pakete, löst keinen IRQ aus, es

ist kein IRQ „pending“ und auf der IRQ-Leitung bleibt die ist kein IRQ „pending“ und auf der IRQ-Leitung bleibt die Spannung unverändertSpannung unverändert

Ursache in Hardware (CAN-Bus richtig angeschlossen?)Ursache in Hardware (CAN-Bus richtig angeschlossen?)

Nutzbar sind:Nutzbar sind:• SMC1-Treiber mit StreamSMC1-Treiber mit Stream• Cooked-StreamCooked-Stream• DemonstrationsprogrammDemonstrationsprogramm


ErgebnisErgebnis

Was hätte man anders machen können?Was hätte man anders machen können?

• Entwicklung eines eigenen Treibers mit Orientierung auf Entwicklung eines eigenen Treibers mit Orientierung auf Echtzeit (war in der Zeitkürze nicht möglich)Echtzeit (war in der Zeitkürze nicht möglich)

Wie könnte man weitermachen?Wie könnte man weitermachen?

• Verifikation der korrekten HardwarefunktionVerifikation der korrekten Hardwarefunktion

• Beseitigung des ÜbertragungsfehlersBeseitigung des Übertragungsfehlers

• Einsatz in „Steer by Wire“-Demo (Stand-Alone oder mit Einsatz in „Steer by Wire“-Demo (Stand-Alone oder mit RTOS)RTOS)


AusblickAusblick

ENDEENDE


SchlussSchluss

Documents

Einleitung