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
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!
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?
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?
Es ist ein privates Projekt. Danke schon mal für deine Hilfe, werde das so ausprobieren.
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.
Habe gerade mal geprüft, ob es das noch gibt - hier isses: http://www.vector.com/vi_infomaterial_orderlist_details_de,,2816.html
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.
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!
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.
>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.
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....
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)
Ich benutze die normale usart.h von MPLAB bzw. vom C18....werd da mal rein gucken.
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.
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!
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.
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.
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)
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.