Forum: Mikrocontroller und Digitale Elektronik Hilfe bei MCP201 Lin-Transceiver


von paul (Gast)


Lesenswert?

Hallo,

ich arbeite mit einem MCP201, welches über USART an einem PIC18f242 
angeschlossen ist. Wenn ich den CS-Eingang vom MCP201 auf High lege und 
per USART etwas schicke und dann den CS-Eingang auf low lege, kann ich 
auf dem Oszi sehen, dass etwas über den LIN gesendet wird. Jedoch gibt 
CANoe immer eine Fehlermeldung aus, dass der Header nicht stimmt.
Hat jemand mit diesem IC schon mal gearbeitet? Ich finde leider keinen 
Besispielcode oder ein Tutorial. Ich weiß leider nicht, wie ich den 
Identifier und die Daten per USART an den MCP201 schicke.
Kann mir jemand helfen???

Gruß Paul

von Harald (Gast)


Lesenswert?

Wenn CANoe sagt, dass der Header nicht stimmt, so liegt das nicht an dem 
MCP201. Dieser Baustein macht ja nur die physikalische Umsetzung von 
TTL-UART auf LIN-1-Draht. Vereinfacht kann man sagen, dass der MCP201 
die LIN-Leitung auf Low zieht, wenn TX des Controller = 0 ist. Der 
aktuelle Pegel des LIN-BUS wird auf den RX des Controllers 
"zurückgespiegelt".

Was ist denn der PIC18F242, Lin-Master oder Slave? Falls Slave, der 
Header wird NUR vom Master gesendet, niemals vom Slave!

von paul (Gast)


Lesenswert?

Der PIC ist Master. Muss ich dann einfach den Header bzw. Identifier und 
danach die Daten nacheinander per USART an den MCP201 übertragen? Der 
Start und die Synchronisation erfolgen automatisch?

von Harald (Gast)


Lesenswert?

Zunächst einmal muss der MCP201 in den aktivn Modus versetzt werden --> 
siehe Datenblatt, das ist ein Flankenwechsel an -WAKE.

Gesendet wird folgendes:

- Break 13 bit low Pegel (kann z.B. durch temporäres Herunterschalten 
der Baudrate erreicht werden --> Byte 0 senden)

- Auf gewünschter Datenrate (z.B 19200 Baud) 0x55 senden (Sync)

- ID incl. 2 Paritybits (siehe Norm, ich hole die vorbereitete 6-bit-ID 
+ 2 Partity-Bits aus einer Tabelle mit 64 Einträgen)

- Jetzt gibt es zwei Möglichkeiten:
- 1. Wenn der Master Daten an den Slave sendet, werden jetzt 1..8 Daten 
gesendet, anschliessend Checksumme laut Norm (V1.3 oder V2.0)
- 2. Wenn der Slave Daten senden soll, sendet der Slave jetzt 1..8 Daten 
(der Slave führt sozusagen den vom Master initiierten Frame weiter), 
anschliessend Checksumme laut Norm

Wenn alles richtig gemacht wurde, sollte man mit CANoe etwas sehen.

Ist das ein privates Projekt oder ein kommerzielles?

von paul (Gast)


Lesenswert?

Es ist ein privates Projekt. Danke schon mal für deine Hilfe, werde das 
so ausprobieren.

von Harald (Gast)


Lesenswert?

Wenn Du offensichtlich schon Vector-Kunde bist: Die haben ein Poster, wo 
die LIN-Kommunikation schön übersichtlich dargestellt ist. Frag dort mal 
an, die senden Dir das sicherlich gerne. Übrigens gibt es die Poster 
auch für CAN und FlexRay.

von Harald (Gast)


Lesenswert?

Habe gerade mal geprüft, ob es das noch gibt - hier isses:

http://www.vector.com/vi_infomaterial_orderlist_details_de,,2816.html

von paul (Gast)


Angehängte Dateien:

Lesenswert?

Kannst du dir vielleicht mal mein Programm angucken und sagen, ob das so 
ungefähr stimmt?
Habs versucht wie du beschriben hast zu machen, aber bei CANoe kommt 
trotzdem eine Fehlermeldung.

von Harald (Gast)


Lesenswert?

Gern, was mir sofort auffällt:
Beim Senden des 0-Bytes als Break musst Du die Baudrate umschalten. 
Ansonsten bekommst Du ja keinen 13-bit langen Break. Es müssen meines 
Wissens auch nicht genau 13 bit sein, es kann auch etwas länger sein. 
Probiere es also in etwa so;

- Baudrate auf 4800 schalten
- Byte 0 senden
- Baudrate auf 9600 schalten
- Byte 0x55 senden
- Byte ID senden
- usw.

Nach außen hin sieht dieses mit niedriger Baudrate gesendete 0 Byte dann 
wie der gewünschte Break aus.

Viel Erfolg!

von paul (Gast)


Lesenswert?

Danke für den Tipp. Hab ich ausprobiert und funktioniert leider immer 
noch nicht. Theoretisch könnte ich doch auch statt die Baudrate zu 
halbieren einfach zweimal 0x00 senden (hab mit beidem keinen Erfolg). 
Oder sehe ich das falsch? Zudem wird auf den Veranschaulichungen (z.B. 
Vector) ein Delimiter am Ende des Break gesendet. Dann müsste ich doch 
eigentlich 0x01 (oder 0x02) senden? Außerdem steht auf der Vector-Seite, 
dass das Sync-Feld und das PID-Feld 10 bit lang sind. Das PID-Feld ist 
doch aber 0x55 und das sind nur 8 Bit. Das verwirrt mich. Manchmal steht 
noch ein Start- und ein Stopp-Bit, dann würde man auf 10 Bit kommen. Da 
ich die zu sendenden Daten per USART schicke, kann ich ja nicht 10 Bit 
senden.

von Harald (Gast)


Lesenswert?

>Oder sehe ich das falsch?
Ja, zwei 0-Bytes kannst Du NICHT hintereinander senden, da dazwischen 
zwangläufig 1 Stopbit liegen würde. Anhand des Start- und Stopbits 
erfolgt ja die UART-Synchronisation. Mit den 10 bit ist das Datenbyte + 
Start und Stopbit gemeint. Der Break ist ja mit seinen >> 10 bit eine 
bewusste Verletzung dieses Framings, damit kann jeder Teilnehmer den 
Beginn eines neuen Frame eindeutig erkennen. In den Empfängern mache ich 
die Break-Detektion anhand eines Framing-Errors:
Ist das ein Framing-Error aufgetreten
UND
ist das empfangene Datenbyte = 0
UND
ist das Portbit ebenfalls bei Eintritt in den Interrupt noch '0'

1. Schritt
Du könntest versuchen, mit einem normalen RS232 Transceiver an den PC zu 
gehen. Trotz des Breaks sollte man den Frame in einem Terminal-Programm 
wie HTERM erkennen.
2. Schritt
Bist Du dir überhaupt sicher, dass der MCP201 sendet? Am besten mit 
einem Oszi überprüfen, zur Not tut es auch eine LED mit einem 1..3k 
Widerstand gegen +UB. Im Ruhezustand ist die LED aus, bei Sendung sollte 
die dann sichtbar flackern.

von paul (Gast)


Angehängte Dateien:

Lesenswert?

Also ich hatte schon mit einem Oszi geguckt und es war zu sehen, dass 
etwas auf dem LIN gesendet wird. Habs grad nochmal mit einer LED 
ausprobiert und gleiches Ergebnis.
Hab mein Programm grad so umgeschrieben, dass ich die Baudrate veränder. 
Anscheinend reicht es nicht, dass ich einfach SPBRG mit einem anderen 
Wert beschreibe? Ich dachte, nach dem ich die USART initialisiert habe, 
brauch ich nur noch SPBRG mit dem berechneten Wert zu beschreiben....

von Harald (Gast)


Lesenswert?

Wie ist WriteUSART() aufgebaut? Wird das Byte in die HW geschrieben und 
dann gewartet? Oder wird erst geprüft ob UART busy und dann das Byte 
geschrieben? Im letzteren Fall würde das erneute Umschalten auf 9600 zu 
früh kommen.

Wenn Du ein Oszi zur Verfügung hast, könntest Du ja etwas genauer 
prüfen: Eine Bitzeit ist 104µs, d.h. ein Byte sind 8*104µs+2*104µs 
(Startbit + 8 Bit + Stopbit). Ein Byte auf der UART ist immer Startbit = 
0, dann die 8 bit Daten + Stopbit = 1. Bei dem Break müsstest Du eine 
'0'-Lücke sehen, die signifikant breiter als die anderen Bytes ist. 
Dabei muss das Break bei 9600 Baud also mindestens 13*104µs '0' sein.

Danach der Delimiter (einfach eine Mindest-Ruhepause) und dann das 
charackteristische Muster von dem Sync, sprich 0x55 (01010101)

von paul (Gast)


Lesenswert?

Ich benutze die normale usart.h von MPLAB bzw. vom C18....werd da mal 
rein gucken.

von paul (Gast)


Angehängte Dateien:

Lesenswert?

Ich kann leider nicht genau sagen, der von dir beschriebene erste oder 
zweite Fall auf WriteUSART zutrifft. Ich kann in meiner verwendeten 
usart.h keine vernüftige Funktionsweise der WriteUSART erkennen. Kannst 
du mir vielleicht sagen, wie ich das Problem für den zweiten Fall 
umgehe? Habs grad mit einem delay versucht, aber scheint auch nichts zu 
nützen.
Das Oszi hab ich leider nicht zu Hause, nur an der Uni :-(
(Hab mal die usart.h mit hochgeladen, falls du rein gucken möchtest)
Und schon mal ein riesen Dank, dass du mir so viel hilfst.

von Harald (Gast)


Lesenswert?

Das mit dem Delay war auf jeden Fall der richtige Ansatz, das würde 
diese Problematik in jedem Fall abfangen. Ich würde sagen, schau erstmal 
mit dem Oszi und dann gehts weiter!

von paul (Gast)


Lesenswert?

So...ich komm grad aus der Uni. Hab mit dem Oszi nachgesehen und eine 
ganze Weile hin und her probiert. Mein Ergebnis ist: 
Baudratenumschaltung funktioniert. Sogar ohne ein Delay. Die Daten, die 
ich per UART schicke, werden auch auf dem LIN gesendet. Man muss 
allerdings beachten, das der MCP201 das LSB zuerst sendet. Wenn ich also 
0xF0 (11110000) gesendet hab, kam auf dem LIN 0xF (00001111) an. Aber 
gut zu wissen.
Hab mich gefreut und bin nach Hause....hier jetzt die Ernüchterung. 
Immer noch ein Fehler. Illegal Sync-Byte und nicht mehr illegal Header. 
Ich steiger mich :-)  Als Sync-Byte sendet man doch 0x55. Damit 
funktionierts nicht und mit 0xAA leider auch nicht.

von Harald (Gast)


Lesenswert?

Also der MCP201 kann nichts an der Bitfolge drehen, er ist nur der 
physikalische Umsetzer. Da ist keine Intelligenz drin, gar nichts, null!

Der UART sendet IMMER das LSB first, das ist aber immer so (siehe auch 
http://de.wikipedia.org/wiki/EIA-232). Ich wüsste keine 
UART-Implementation, wo man das überhaupt drehen könnte (SPI schon, aber 
nicht UART).

Nimm dir doch einfach das Oszi und lege die LIN-Norm daneben. Bis zur ID 
kann man das Timing doch ganz einfach selbst auszählen.

Ich könnte mir noch vorstellen, dass CANoe sehr resitriktiv auf das 
Timing reagiert. Vielleicht passen auch die Delimiter-Zeiten auch nicht.

Ist CANoe überhaupt auf Autobaud-Erkennung geschaltet oder geht es von 
einer festen Baudrate aus? Könnte mir nämlich vorstellen, dass ansonsten 
die meist gängigere Rate 19200 eingestellt ist. In diesem Fall könnte er 
die auf 9600 gesendete 0x55 nicht erkennen.

von paul (Gast)


Angehängte Dateien:

Lesenswert?

So hab mal wieder mit dem Oszi gemessen. Signal vom MCP201 sieht so weit 
sehr gut aus. Muss wohl an den Einstellungen von CANoe liegen, da denke 
ich aber auch schon alle ausprobiert.
Hier mal ein Bild, wo nur Break und Sync gesendet werden. (Da ist mir 
auch aufgefallen, dass ich ein Fehler bei der Baudrate gemacht hatte)

von paul (Gast)


Angehängte Dateien:

Lesenswert?

Hier mal ein Bild von einem kompletten Frame. Ich habe mal als Break 
eine 0x80 gesendet, weil auf einigen Bildern im Inet zu sehen war, das 
eine kleine Pause zwischen Break und Sync liegt (Delimiter). 
Funktioniert so aber auch nicht. Der Rest stimmt auch, als Identifier 
hatte ich glaub 0x3C gesendet und als Daten-Byte 0xF0.

von Harald (Gast)


Lesenswert?

Sieht gut aus, vielleicht liegt es - wie schon gesagt - an CANoe. Könnte 
sein, dass die aufgrund Einhaltung von Automobilnormen ein 
ultrakorrektes Timing erwarten. Wenn Du es nur für private Zwecke 
benötigst, würde ich es dabei belassen und mich um die 
"Gegenstation(en)" kümmern. Oder Du versucht es noch mal mit 19200 Baud.

von paul (Gast)


Lesenswert?

Das wollte ich vorhin machen, hab aber festgestellt, dass ich dazu erst 
ein anderes Qurtz brauch. Bis jetzt ist eins mit 8 MHz drauf und mit den 
PIC-internen 2 MHz schaff ich keine 19200. Wird auch morgen besorgt.

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
Noch kein Account? Hier anmelden.