Hallo Leute.
Ich benutzte einen PSoC-yC von Cypress. Dieser hat einen integrierten
CAN-Controller.
Nun möchte gerne zwei dieser Dinger miteinander kommunizieren lassen.
Hierzu habe ich nach den CAN-Spezifikationen je Controller einen
MCP2551-Transreceiver an den Bus gelötet. Der Bus besteht aus zwei 3cm
Kabel (Testplatine) die an den Enden jeweils mit 120 Ohm terminiert
werden.
Nun ist es so, dass der MCP den Bus nicht einmal auf 2.5V zieht. Selbst
wenn ich ihn nur an die Versorgungsspannung hänge und TX/Rx nicht
beschalte, sollte das doch mindestens funktionieren oder?
Der MCP bekommt Vdd/Ground vom Mikrocontroller. Der PIN für die
Flankensteuerung ist auf Masse.
Hat jemand eine Idee zum Thema ?
Besten Dank
Mal unabhängig vom Transceiver-Problem.
Ich möchte gerade den CAN-Controller auf Funktion prüfen. Hierzu habe
ich einfach den Tx an den Rx des Controllers geklemmt.
Es gelingt mir eine Nachricht zu versenden (Standard-Daten-Frame/
Standard-CAN-Nachricht) und ich bekomme auch eine periodische Bit-Folge
am Tx raus. Diese entspricht jedoch nicht dem Standard-Frame nach
CAN-Spezifikation.
Meine Nachricht enthält nur 1 Datenbit. Ändere ich dieses von 0 auf 1
wird die gesamte Bitfolge auf einmal um 3bit kürzer. Das ist doch
eigentlich garnicht möglich oder?
Bilder habe ich mal angehängt:
Datenbit = 0; Datei ...low
Datenbit = 1; Datei ...high
Danach wiederholt sich die Folge, nach ca. 27 high-bits periodisch (in
beiden Fällen).
S.K. schrieb:> Meine Nachricht enthält nur 1 Datenbit. Ändere ich dieses von 0 auf 1> wird die gesamte Bitfolge auf einmal um 3bit kürzer. Das ist doch> eigentlich garnicht möglich oder?
Doch, die Länge der Signalfolge auf dem Bus hängt vom Inhalt ab. Lange
Folgen gleichen Pegels werden zur Auffrischung der Taktsynchronisation
durch eingeschobene Stopfbits unterbrochen.
Jetzt wird mir einiges klarer. Ich hatte überlesen das das Datenfeld im
Daten-Frame bis zu 8byte ist. Das bedeutet also das in diesen Rahmen
mein Datenbit + zusätzliche Stopfbits auftreten? Wonach richtet sich
denn die genaue Größe des Datenfeldes, ist das Controllerspezifisch?
Wenn ich mir den Signalverlauf anschaue finde ich jedoch keine festen
Bits, wie Startbit, Id-bits, usw.. Die müssten doch wenigstens in der
Folge zu erkennen sein. Oder handelt es sich womöglich garnicht um ein
Daten-Frame?
Grüße Stephan
Okay, die letzten Fragen haben sich erledigt. Nach dem ich mir das
CAN-Protokoll etwas gründlicher angeschaut habe, finde ich nun auch
meine ID in der Bitfolge wieder ;-).
Die nächste Sache ist nun, da ich ja noch das Problem mit den
Transceivern besitze, die beiden Mikrocontroller erstmal über eine
Wired-And-Verbindung kommunizieren zu lassen.
(siehe:
http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf)
Ich habe hier noch Verständnisprobleme. Die obige Nachricht liegt nun
auf dem Bus an. Timing/Baudrate stimmt bei beiden. Aber sobald ich den
Empfänger an den Bus klemme ist der Bus wieder "leer" (in diesem Fall
auf 5V, siehe Schaltung). Beim Empfänger erhalte ich keine Daten. Woran
könnte das liegen und wie kann ich das Problem eingrenzen?
Gruß S
Hallo,
wenn du OHNE Fehler senden kannst, dann sollte es auf der anderen Seite
auch ankommen. Als erstes würde ich diverse Fehlerbits auf beiden Seiten
beim Senden überprüfen. Wenn es keine Fehler gibt, liegt die Nachricht
auf dem Bus und kann auch empfangen werden.
Evtl. hast du auch den Filter aktiviert und empfängst aus diesem Grund
keine Nachricht ?!
Grüße.
Hi.
Ja du hast recht, es passiert was auf dem Bus. Die Nachricht wird genau
1x gesendet und empfangen ist mir heute erst aufgefallen.
Wie sieht den eine richtige Kommunikation auf dem Bus aus? Sender sendet
Nachricht 1x. Empfänger empfängt diese. Bus ist wieder leer?
Mir ist nämlich aufgefallen, dass sich einige Bits der Nachricht ändern
wenn der Empfänger mit am Bus hängt.
Ich hab mir die Fehlerwerte mal angesehen und es stimmt, zumindest der
Sender macht keinerlei Fehler.
AMR und ACR sind richtig eingestellt. Es treten, vor allem beim
Empfänger, Sendefehler > 255 auf. Da müsste der doch eigentlich in den
Bus-Off gehen oder? Warum macht der Empfänger eigentlich Sendefehler,
der soll doch nur Empfangen :-)?
Die Fehlerwerte kann ich über C-Funktionen auslesen.
Besten Dank und Viele Grüße
S
S.K. schrieb:> Wie sieht den eine richtige Kommunikation auf dem Bus aus? Sender sendet> Nachricht 1x. Empfänger empfängt diese. Bus ist wieder leer?
Ja.
> Mir ist nämlich aufgefallen, dass sich einige Bits der Nachricht ändern> wenn der Empfänger mit am Bus hängt.
Das ist normal. Der Empfänger (oder mehrere) schauen ob die Nachricht
empfangen werden darf (Filter) und senden ein ACK wenn sie es dürfen. Es
wird dem Sender also signalisiert das die Nachricht von mindestens einem
Empfänger empfangen wurde.
S.K. schrieb:> Es treten, vor allem beim> Empfänger, Sendefehler > 255 auf. Da müsste der doch eigentlich in den> Bus-Off gehen oder? Warum macht der Empfänger eigentlich Sendefehler,> der soll doch nur Empfangen :-)?
Siehe oben.
Rudi schrieb:> Das ist normal. Der Empfänger (oder mehrere) schauen ob die Nachricht> empfangen werden darf (Filter) und senden ein ACK wenn sie es dürfen.
Die senden auch dann ACK, wenn die Nachricht nicht in den Filter passt.
Sie muss nur korrekt empfangbar sein.
Ein aktiviertes ACK Bit ist also kein Indiz dafür, dass sich jemand
dafür interessiert hat.
Mhh das ist interessant. Im Moment siehts so aus. Der Sender sendet, bis
auf vereinzelte Bitfehler, problemlos. Hängt kein Teilnehmer am Bus,
gibts einen Ack-Error. Auf dieser Seite also alles normal.
Der Empfänger muss die Nachricht ja zumindest richtig bestätigen, sonst
würde der Sender Ack-Error melden richtig?
Ich erhalte jedoch nicht meine übertragenen Datenbits am Empfänger. Hier
kommt also inhaltlich nix an.
Das Problem sollte somit entweder bei der Schaltung oder am
ACR/AMR-Filter des Empfängers zu finden sein oder?
S.K. schrieb:> Der Empfänger muss die Nachricht ja zumindest richtig bestätigen, sonst> würde der Sender Ack-Error melden richtig?
Irgendeine Node muss es bestätigen. Nicht unbedingt diejenige, die damit
gemeint ist.
> Das Problem sollte somit entweder bei der Schaltung oder am> ACR/AMR-Filter des Empfängers zu finden sein oder?
Sieht so aus. Man darf CAN auch ohne Filter bzw. mit "ich will alles"
betreiben um anschliessend per Software zu filtern. Kann u.U. einfacher
sein als sich mit z.T. komplexen Filterstrukturen rumplagen zu müssen.
Mindestens anfangs.
Endlich Ergebnisse.
Es lag sowohl an einem falsch eingestellten Filter als auch am falschen
Auslesen der Empfangspuffer. Nun klappt der Nachrichtenaustausch
erstmal. Bedeutet also diese provisorische wired-or Verbindung kann man
für Testzwecke durchaus benutzen.
Vielen Dank erstmal für die Hilfe. Falls noch Fragen auftauchen, meld
ich mich hier :-).
