Also ich habe hier einen ATMega163 mit Phillipps SJA1000 CAN Controller und Display. Als "Gegenstelle" habe ich einen AT90S4433 nur mit SJA1000. Einzeln funktioniert alles wunderprächtig. Testweise schicke ich vom ATmega eine CAN Message los, die der 4433 empfangen soll und genauso wieder zurückschicken soll. Zur Kontrolle wird die CAN Message dann auf dem Display angezeigt. Ich erhalte auf dem Display die richtige Anzeige, also funktioniert die Kette "msg hinschicken, empfangen, zurückschicken, empfangen, auf dem Dispaly ausgeben" korrekt. Mache ich daraus eine Endlosschleife wirds kurios. Also der Atmega schickt die soeben empfangene Nachricht wieder zum 4433 und der wieder zurück und der Mega zeigt se wieder am Display an und schickt se wieder zum 4433. Also ping pong mit CAN. Die CAN Controller melden keine Busfehler, aber die Messagebytes verschieben sich immer mehr nach links! Meine Testmessage sieht so aus 0xAB 0xCD 0xEF 0x12. Daraus wird dann irgendwann 0xBC 0xDE 0xF1 0x10 (man beachte die Null am Ende). Und lasse ichs noch länger laufen dann verschiebt es sich immer mehr! (aber eher zufällig, also die Anzahl der korrekten Messages, die zwischen den Fehlerauftritten liegt ist zufällig). Ich habe bisher immer einen Programmierfehler im Timing der Ansteuerung der CAN Controller gedacht. Aber heute wirds ganz kurios! Anstatt die Messages zeigt mein Display nur noch kryptische Zeichen an (ohne das ich was am Programm geändert hätte; Kurzschluss?!), wenn die Endlosschleife beginnt (vorher nicht, da werden erst Informationen zur Initialisierung des CAN Controllers angezeigt; deswegen wohl kein Kurzschluss!)! Ich bin der Sache auf den Grund gegangen und musste feststellen, daß PD7 (daran hängt der Datenpin 7 vom Display) am ATMega dauernd high ist in der Ping Pong Schleife. WIESO verdammt? Die CAN Routinen haben gar nix mit dem PORTD des ATMegas zu tun (CAN Controller hängt auf PortC und B). Der Pin PD7 ist sogar dann dauernd high, wenn ich testweise alle Displayanzeigefunktionen aus der Ping Pong Schleife auskommentiere. Dann zeigt das Display zwar auch nix mehr an, aber das Ping Pong läuft ja trotzdem und der Pin ist auch trotzdem high. Selbst wenn ich immer bei jedem Schleifendurchlauf expliziet den PortD resette (outb(PORTD,0x00);) dann bleibt der Pin high (der Rest des Ports ist low). Ist also in der Ping Pong Schleife auf keine Weise low zu kriegen. Nur wenn ich die CAN Routinen Streiche dann gehts wieder mit dem Display. Aber wie gesagt die CAN Routinen schauen den PORTD noch nicht mal an! Hat mein ATMega ne Macke oder wodran kann das liegen? Kann das kuriose mit dem Display auch auf das Bit shifting der CAN Messages was zu tun haben (wenn das auf dem Bus passieren würde, dann würde ich Bus Errors vom CAN Controller erwarten)? Wäre ja möglich, daß das komische Verhalten des Pins nicht die einzige Macke ist.
Wenn der Port ohne CAN reagiert, dann ist wohl hardwaremäßig alles in Ordnung und das Problem liegt in der Software. Ich habe auch schon manches mal an mir (und dem Atmel) gezweifelt, aber es hat sich (fast) immer als Programmierfehler herausgestellt. Schau Dir mal die Interrupts an - werden wirklich alle im Interrupt benutzten Register gesichert? Statusregister? Evtl. irgendwo ein Schreibfehler (falsches Register erwischt)
es werden ja gar keine Interrupts verwendet (vorerst polle ich die ganze Zeit das Statusregister. Es muss erstmal so laufen und dann kann ich mich den Interrupts widmen) und ich hab auch nirgends den falschen Port erwischt. Sonst würde ja der Can Controller ja auch gar nicht funktionieren. Ich programmiere ja in C und deswegen habe ich jeweils nur eine Routine zur Ansteuerung des CAN und des LCD und deswegen ist es alles sehr übersichtlich. Die anderen Routinen schreiben ja gar nicht auf Ports. Ausserdem hat es ja vorher funktioniert, mit dem selben Routinen. Und da ich an denen nix geändert habe sondern nur am Programmablauf seitdem das Problem auftritt (das mit dem Display war ja nicht von Anfang an) kann ich mir eigentlich nur einen Compilerfehler vorstellen oder halt das der Atmel defekt ist. Leider kann ich das ganze ja im AVR Studio nicht simulieren, denn ich kann ja die Kommunikation mit dem CAN Controller nicht simulieren.
Hast Du Dein altes Programm gesichert, mit welchem noch alles funktionierte? Damit kannst Du die Funktion Deines AVRs überprüfen. Evtl. löst das schon die ganze Problematik (kaputt ist kaputt). Wenn es damit funktioniert, kannst Du ja Stück für Stück vom Programmcode des neuen Programms entfernen, solange bis es ebenfalls wieder funktioniert, dann wirst Du sicherlich auf die kritische Stelle stossen. Es liegt dann sicherlich nicht am CAN, sondern evtl, an irgendeiner falschen Registerdefinition (z.B. PD7 aus Versehen als OC2 definiert?)
nein leider habe ich das alte Programm nicht gesichert. Das ist es ja gerade... Und an den kritischen Routinen, die auf den CAN und das Display zugreifen habe ich nichts geändert. Gerade habe ich das Display umgeklemmt, so daß ich PD7 nicht mehr benötige. In der Initialisierungsphase zeigt das Display wieder ganz normal an. Wenn das Ping Pong Spiel beginnt sehe ich jetzt anderen Kauderwelsch. (es sind übrigens immer die selben kryptischen Zeichen, nur wo ich jetzt auf PD7 verzichte und dafür einen anderen noch freien Pin von PORTD verwende haben sich die Zeichen verwendet. Sie sind nach jedem Reset jedoch immer gleich).
Hallo! Ich will mit meinem AVR den CAN-Controller "SJA1000" ansteuern. Irgendwie funktioniert es nicht so ohne weiteres. Dazu verwende ich zwei Ports. Auf den einen Port gehen die Daten/Adressleitung (8-Leitungen) hin. Am anderen Port habe ich die Steuerleitungen (ALE,RW,CS usw.) angeschlossen. Kann mir jemand dabei helfen, wie ich den CAN-Controller mit der Programmiersprache C ansteuern kann???? Wenn jemand ein kleines Beispiel dazu hat, wäre echt super. Dafür wäre ich echt sehr dankbar. Danke Bye Mfg Hennse
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.