Wollte mal fragen wer schonmal mit dem MCP2551 CAN-Transceiver gearbeitet hat und mal etwas an seiner Schaltung/Software vergleichen kann. Da ich hier einen Fehler in der Übertragung habe und die Ursache nicht finde. Benutzt ihr auf der RX Leitung zw. µC und MCP2551 in der Hard-/Software einen Pullup oder ist das sogar contraproduktiv. Ich habe hier aus der Forums Wanderkiste eine Platine mit einem AVR ATMega16M1 dem ein MCP2551 bestückt, die Übertragung läuft einwandfrei aber ganz zum Schluß wird die Nachricht am PC-Interface verworfen und ich komme nicht drauf woran das liegt.
Angehängte Dateien:
CAN_Newbie schrieb: > die Übertragung läuft einwandfrei > aber ganz zum Schluß wird die Nachricht am PC-Interface verworfen und > ich komme nicht drauf woran das liegt. Woher weißt du, dass die Übertragung einwandfrei läuft, wenn sie doch verworfen wird? Mit welchem Fehler wird sie verworfen? Pullups sind nicht notwendig, sollten aber eigentlich auch nichts kaputt machen.
CAN_Newbie schrieb: > Benutzt ihr auf der RX Leitung zw. µC und MCP2551 in der Hard-/Software > einen Pullup oder ist das sogar contraproduktiv. Warum sollte da ein Pullup rein? die Leitung kann kein Tristate, also ist der Pegel immer definiert und ein Pullirgendwas unnötig. > aber ganz zum Schluß wird die Nachricht am PC-Interface verworfen An welchem PC-Interface? Von welcher Software?
Pull-ups brauchst du keine auf TXD/RXD. Mit welchen Spannungen arbeitest du? Die µC-VCC legst du auf Vref, den Transceiver selbst versorgst mit 5 V. Denk dran, den CAN-Bus auf beiden Seiten mit 120 Ohm zu terminieren. Viele Grüße Jochen
CAN_Newbie schrieb: > Ich habe hier aus der Forums Wanderkiste eine Platine mit einem AVR > ATMega16M1 dem ein MCP2551 bestückt, die Übertragung läuft einwandfrei > aber ganz zum Schluß wird die Nachricht am PC-Interface verworfen und > ich komme nicht drauf woran das liegt. Bei mir zählt eine Übertragung erst als einwandfrei laufend, wenn alles so ankommt, wie ich es mir vorstelle. Wie sehen deine Signale auf dem Bus aus (physical layer), versteht der LA die Nachrichten und mit welchem Argument verwirft das PC-Interface die Nachricht? Wie sieht deine Busbeschaltung aus? (Schaltplan)
ja Terminierung ist vorhanden, VREF ist offen das ist ja nur ein Ausgang, bei mir hängen aber alle Knoten hängen an der gleichen 5V, GND, CANL und CANH Leitung gibt also keinen Potentialunterschiede. Das Interface ist dieses hier https://www.microchip.com/en-us/development-tool/apgdt002 Mit dem Oszi kann ich die Nachricht aufzeichnen und da passt alles habe die Nachricht komplett analysiert inkl. Stuffbits, CRC Check usw. Kann es sein das der Sender die Nachricht wiederuft, wenn man das TXOK Bit nicht richtig gesetzt/abgerufen wird? Nach den 7 Bits Pause nach der Nachricht sind noch mal 2 kürzere Pulse auf der Leitung allerdings nur mit etwa 1/4 der normalen Bitzeit.
Ein CAN Bus benötigt mindestens 2 aktive Teilnehmer am Bus, sonst wird ein gesendeter Frame nicht quittiert. 1 aktiver Teilnehmer reicht nicht, ein zusätzlicher rein passiv bleibender Sniffer ändert nichts.
:
Bearbeitet durch User
Angehängte Dateien:
-
CAN-Schaltplan.jpg
74 KB
Die Bussignale sind sauber. Das Interface sagt einfach nur Error. Anbei der beigelegte Schaltplan.
das ist kein passiver Sniffer. Ohne das Interface kommt eine Dauerwiederholung.
Angehängte Dateien:
Vref bleibt offen, korrekt. Aber warum ist RS mit 100k auf einen Portpin gelegt? Brücke RS mal stumpf auf GND. Bei RS mit 100k gegen GND hast du schon extrem langsame Flanken, vlt noch für sehr niedrige Bitraten aber nicht mehr 100kbit oder höher. Siehe Bild. Wenn der Portpin auf High liegt geht der MCP in Standby. Absicht? Und zeige mal einen Screenshot von deinem Sniffer bitte. Pull-ups an RXD/TXD kenne ich höchstens noch aus der 8051 Zeit, wo die Portpins beim Startup teilweise nicht Highpegel halten konnten und vor der Initialisierung des Ports bei einem zufälligen Low mal schön einen Busfehler bei den übrigen Busteilnehmern erzeugt hat.
:
Bearbeitet durch User
Angehängte Dateien:
-
CAN_Telegram_3.png
220 KB -
CAN_Telegram_5.png
26 KB
@Harald ja das scheint Absicht zu sein das RS schaltbar ist. Die Bitrate ist sehr langsam 16 kbit/s glaub das war das unterste Ende des MCP2551. Ich könnte aber den 100kOhm Widerstand zum testen mal austauschen.
Es ist eine alte Weisheit dass Schaltungen mit dem MCP2551 CAN-Transceiver keine Abblock-Kondensatoren brauchen. Solche Kondensatoren müssen nur dann vorgesehen werden wenn auf der Schaltung das Prädikat "professionell" aufgeklebt ist. Normale Hobby-Schaltungen brauchen diese Kondensatoren grundsätzlich nicht da überall im Internet geschrieben wird dass es auch ohne hunderprozentig zuverlässig funktioniert.
OMG schrieb: > Es ist eine alte Weisheit dass Schaltungen mit dem MCP2551 > CAN-Transceiver keine Abblock-Kondensatoren brauchen. Solche > Kondensatoren müssen nur dann vorgesehen werden wenn auf der > Schaltung das Prädikat "professionell" aufgeklebt ist. > Bevor ich den Verdacht raushaue, würde ich erstmal den Rest der Schaltung betrachten. Mit der Drossel, PESD1CAN und der Split-Termination entstammt das ja höchstwahrscheinlich nicht der Feder eines Dilettanten. Die Abblockung kann je nach Aufbau auch anderweitig stattfinden, wenn z.B. der Transceiver direkt neben dem Spannungsregler sitzt. @CAN_Newbie: Das Oszillogramm sieht etwas merkwürdig aus, entweder 1MHz Taschenoszilloskop oder fehlender Masseanschluss. Ich würde nicht so ein Auf und Ab im Pegel erwarten…
Angehängte Dateien:
Ich denke dein Problem sind die zwei rot eingekreisten Impulse, die offensichtlich nicht zum CAN Protokoll gehören. Die können den Error auslösen. Während das gesamte Oszillogramm zu deinem Diagramm passt sind die beiden Impulse fehl am Platz. Auch von der Breite her passen die nicht zur eingestellten Baudrate. So etwas kann ausgelöst werden, wenn die IO-Portpins mit 0 initialisiert sind und die Sonderfunktion CAN von diesen beiden Portpins zu- und abgeschaltet wird. D.h. solange das CAN-Modul die Portpins bedient werden die schön mit 1 in den Ruhephasen belegt. Wird die Sonderfunktion CAN von dieser IO weggeschaltet gilt wieder der zuvor eingestellte Pegel. Also bitte mal das IO-Ausgangsregister mit „1“ vorbelegen.
:
Bearbeitet durch User
Harald: Ja genau diese 2 Impulse habe ich im Verdacht, als ob das als Errorframe erkannt wird und die ganze Übertragung verworfen wird.
Angehängte Dateien:
-
CAN-Schaltplan.png
460 KB
CAN_Newbie schrieb: > Die Bussignale sind sauber. Das Interface sagt einfach nur Error. > Anbei > der beigelegte Schaltplan. Laut Forenregeln müssen Schaltpläne im PNG-Format (oda GIF) gespeichert werden! Ich hab das mal korrigiert! Halte dich nächstes mal bitte daran! Zidat: "Bitte das JPG-Format nur für Fotos und Scans verwenden! Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen. Siehe Bildformate."
:
Bearbeitet durch User
Content B. schrieb: > Ich hab das mal korrigiert! Dein PNG-Anhang ist ein Foto oder Scan! LG, Sebastian
ja was soll es bringen ein .jpg nochmal in .png zu ändern die Infos die das .jpg verloren hat kommen dadurch nicht wieder. Wenn ich einen Schaltplan einstelle der direkt vom Rechner stammt speichere ich das selbstverständlich gleich als .png PS aus dem 74kB .jpg wurde jetzt ein 460kB .png Der MCP2551 hat nen 100nF Kerko direkt zw. VCC und GND, bei der Messung habe ich mir nicht die größte Mühe gemacht, da es bei der differentiellen Übertragung nicht darauf ankommt.
Thomas O. schrieb: > Harald: Ja genau diese 2 Impulse habe ich im Verdacht, als ob das als > Errorframe erkannt wird und die ganze Übertragung verworfen wird. Lass dich nicht mit den Bildformaten irritieren. Aber was ist denn jetzt mit den beiden Impulsen? Vom CAN Controller kommen die eher nicht. Die Übertragung ist eigentlich nicht verworfen, das Quittungsbit kommt ja.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.