Hallo! Ist es normal, dass die AT90CANxx Controller solange aussenden, bis ein Acknowledge kommt? Also nie wieder ins senden aufhören ansonsten? Oder muss man etwas spezielles einstellen? Danke mfg Franz
Wenn kein zweiter CAN-Knoten mit entsprechend geöffneten Filtern am Bus hängt, ist dieses Verhalten bei allen mir bekannten CAN-Controllern gegeben. Also kein spezielles Problem des AT90CAN. Schon ein CAN-Dongle am PC gilt als zweiter CAN-Teilnehmer sofern dieser nicht im Listen-Only-Mode arbeitet.
Danke Harald! Angenommen man sendet mit einem CAN Controller an einem PKW eine Message mit einer ID die nicht vorhanden ist, also auf die kein Filter anspricht, würde der Controller auch ewig lange senden richtig? mfg Franz
Hi bei einigen CAN-Controllern kann man das abstellen (Automatic Retransmission) aber ansonsten ist das verhalten normal. Matthias
Ein CAN Controller bei dem man das abstellen kann entspricht aber nicht der Spec. Bei CAN ist es immer so, dass ein ACK von einem zweiten aktiven Knoten benötigt wird. Fehlt dieses ACK sollte der Controller in den Fehlerzustand gehen (-> das kann man mindestens auslesen oder gar per Interrupt behandeln). Das ACK ist vollkommen unabhängig von den eingestellten Filtern der anderen Controller. So bald eine Nachricht auf dem Bus ordnungsgemäß übertragen wurde und dies durch einen zweiten Controller bestätigt wird "entsteht" das ACK auf dem Bus. Der Controller der die Bestätigung erzeugt muss die Daten selber noch nicht einmal verarbeiten. Jeder CAN-Controller muss erkennen ob er evtl selber fehlerhaft ist, damit er nicht den Bus zumüllt. Und genau das trifft in deinem beschrieben Fall zu. Manche (Can-Communikation-)Controller können einen Interrupt auslösen, wenn der Error Counter, der die Abtrennung vom Bus im Fehlerfall bewirkt, einen vordefinierbare Schwelle überschreitet. Es wird also vor dem Fehlerzustand ein "Warningzustand" erzeugt. Gruß, TManiac
TManiac schrieb: > Jeder CAN-Controller muss erkennen ob er evtl selber fehlerhaft ist, > damit er nicht den Bus zumüllt. Und genau das trifft in deinem > beschrieben Fall zu. Hallo! Was meinst du, dass es in meinem Fall zutrifft? Er erkennt ja selbst nicht dass er Fehlerhaft ist, sondern müllt den Bus eigentlich komplett zu, in dem er nicht mehr aufhört zu senden oder sehe ich da etwas falsch? Danke!! mfg Franz
Hallo Franz,
ich habe so eine Singleshotlösung umgesetzt:
(Sie ist villeicht nicht elegant aber effektiv)
void ActivateTransmission(unsigned int par_Identifier)
{
unsigned int varl_temp_CDMOB = 0;
/* Das MOb-Register CANPAGE */
SetCANPage(par_Identifier);
/* Hole das für das gewünschte MOB gültige */
varl_temp_CDMOB = CANCDMOB;
/* MOB-Senden aktivieren in Zwischenregister eintragen */
varl_temp_CDMOB |= MOB_SET_TXMODE; //(1 << CONMOB0);
/* und in Register eintragen. */
CANCDMOB = varl_temp_CDMOB;
/* danach Schreib-Marke sofort wieder löschen */
varl_temp_CDMOB &= MOB_RESET_TXMODE; //0xBF;
/* und in Register schreiben. */
CANCDMOB = varl_temp_CDMOB;
/* so funktioniert es. */
}
Viel Erfolg
Danke cskulkw! Mir geht es nur um das Verständnis, vermutlich ist es eh gut, wenn er es solange sendet, bis es jemand mit einem ACK akzeptiert. Ich muss es erst noch am Auto testen, und hoffen, dass ich dabei nichts zerstöre ;) Danke mfg Franz
SingleShot hat nichts mit ACK zu tun. ACK ist etwas das im LowLevel-Bereich abläuft. Du siehst im Controller selber nicht ob es ein ACK gibt. Sowas kannst du nur auf dem Oszi oder eben als Eintrag im Fehlerregister sehen. Wenn dein Controller weiter sendet, obwohl die Nachricht raus ist (dann hat er auch ein ACK empfangen) wird eben das "Sende-Die-Nachricht"-Bit nicht gelöscht. Wie dies gemacht wird zeigt cskulkw. Da ich die Interna des Controller nicht näher kenne, kann ich nicht sagen wie er sowas von allein macht. Ich könnte wetten, das es aber irgendwie geht, weil es nunmal der Regelfall ist, das Nachrichten gezielt gesendet werden. Also große Frage: bist du dir sicher, dass es kein ACK gibt? Und woher weißt du das? Mit was überprüfst du ob die Nachricht gesendet wird (also physikalisch auf dem Bus liegt)? Normaler Weise erzeugt schon die Messhardware ein ACK, wenn es bei dieser nicht explizit ausgeschaltet wird (Listen-Only-Mode). Gruß, TManiac
Hallo! Also ich habe ein Oszilloskop, damit sehe ich erstmal wenn am Bus die nachricht gesendet wird. und dann überprüfe ich es noch mit einem CAN "Monitor" der LEIDER nur im listen mode laufen kann, also definitiv kein ACK erzeugt. Bist du nun also der Meinung, dass das nicht an dem fehlenden ACK liegt, oder verstehe ich dir hier falsch? mfg Franz
Was ist nun wieder der CAN Monitor? Es kann viele Gründe haben. Da wir hier aber nur das von deinem Aufbau wissen, was du uns sagst/schreibst, können wir nur tippen/raten. Noch einmal von vorne: Der CAN-Bus funktioniert erst dann wenn mindestens zwei aktive Knoten vorhanden sind. Ein Knoten allein ist ein Fehler. Und dass sollte der Knoten auch erkennen und sich stummschalten. (wenn ich mich richtig erinnere nach 255 Sendeversuchen ohne ACK). Sendet dein Controller mehr als diese 255 (die Zahl müsste auch im Manual zu deinem Controller drin stehen), dann bekommt er entweder ein ACK und geht somit nicht in den Fehlerzustand. Oder aber er erkennt ihn richtig und führt danach ein Reset aus. Und fängt daher wieder von vorne an. Probier den oben vorgeschlagenen Code mal aus und berichte wie es damit aussieht. Hat dein Oszi evtl. eine Funktion um CAN-Nachrichten zu decodieren? Wenn nicht dann sende eine Nachricht mit nur einem Byte Länge (DLC einstellen). Eine solche kurze Nachricht müsste in den Speicher des Oszi (der meißten Oszis) passen. Und dann schau wie das ACK in deiner Nachricht aussieht). Noch etwas anderes: hat der Controller evtl eine LoopBack (Selbsttest-) Funktion. Solche sind zur Simulation gedacht um die grundlegende Software auch ohne reelen Bus testen zu können. Das heißt aber der der Controller sich auch so verhält als würde das ACK vorhanden sein. Ist diese Funktion evtl aktiv? Gruß, TManiac
TManiac schrieb: > Was ist nun wieder der CAN Monitor? Ein ELM327 der mir die Nachricht anzeigt. > Es kann viele Gründe haben. Da wir hier aber nur das von deinem Aufbau > wissen, was du uns sagst/schreibst, können wir nur tippen/raten. > > Noch einmal von vorne: > Der CAN-Bus funktioniert erst dann wenn mindestens zwei aktive Knoten > vorhanden sind. Ein Knoten allein ist ein Fehler. Und dass sollte der > Knoten auch erkennen und sich stummschalten. (wenn ich mich richtig > erinnere nach 255 Sendeversuchen ohne ACK). Ich verstehe schon wie du meinst, aber meiner schaltet NIE ab! > Sendet dein Controller mehr als diese 255 (die Zahl müsste auch im > Manual zu deinem Controller drin stehen), dann bekommt er entweder ein > ACK und geht somit nicht in den Fehlerzustand. Oder aber er erkennt ihn > richtig und führt danach ein Reset aus. Und fängt daher wieder von vorne > an. Er bekommt kein ACK egal wann. Es kann natürlich schon sein, dass er die 255 erkennt, aber trotzdem munter weitersendet. Ein ACK Error bit bzw. Interrupt gibt es natürlich, aber anfänglich war ja lediglich die Frage wieso der Controller immer weiter sendet, und das liegt laut euch ja daran, dass kein ACK kommt. > Probier den oben vorgeschlagenen Code mal aus und berichte wie es damit > aussieht. > > Hat dein Oszi evtl. eine Funktion um CAN-Nachrichten zu decodieren? Wenn > nicht dann sende eine Nachricht mit nur einem Byte Länge (DLC > einstellen). Eine solche kurze Nachricht müsste in den Speicher des Oszi > (der meißten Oszis) passen. Und dann schau wie das ACK in deiner > Nachricht aussieht). Es kommt kein ACK, mit nur einem Byte Länge kann ich es noch gut am Oszi ablesen. > Noch etwas anderes: hat der Controller evtl eine LoopBack (Selbsttest-) > Funktion. Solche sind zur Simulation gedacht um die grundlegende > Software auch ohne reelen Bus testen zu können. Das heißt aber der der > Controller sich auch so verhält als würde das ACK vorhanden sein. Ist > diese Funktion evtl aktiv? Ja hat er, allerdings ist die nicht aktiviert, es wäre außerdem genau das Gegenteil der Fall, wenn die aktiviert wäre, denn wenn er dann einen ACK bekommt, würde er ja aufhören zu senden, wenn du weißt wie ich das meine. Ich werde das ganze mal ans Auto hängen, mit einer ID die definitiv nicht vergeben ist, dann kann ich am Oszi ja sehen wie oft er es aussendet, und wenn die Annahmen stimmen, sollte er ja dank des erhaltenen ACKs von einem der ECUs nach einem mal senden aufhören. Danke mfg Franz
Äh. nöö. Wenn gar kein ACK auf dem Bus auftaucht sollte der Controller in den BUSOFF State gehen und nicht mehr senden. Steht auch so im Manual im Kapitel "19.7 Error Management" (ich habe nun doch mal das Manual rausgesucht). Wenn er eben durch irgendetwas ge-reset-ed wird, wird er immer weiter, bzw immer wieder senden. Wie sieht die Interrupt-Routine Hast du die Möglichkeit die Register CANGSTA und CANGIT auszulesen? Ja ELM327 ist bekannt. Meines Wissens nach kann man den aber auch ein ACK ein-konfigurieren. Hast du evtl noch etwas anderes um einen zweiten aktiven Knoten darzustellen, evtl einen zweiten AT90CAN? Der muss nichts senden, nur der CAN-Controller muss laufen (Baudrate einstellen und aktiveren). Gruß, TManiac
Hallo ! Ja ich habe noch einen zweiten At90CAN, ich versuche es dann gleich einmal! Ich habe beim ELM327 gesucht, aber habe nichts gefunden wo man es einstellen könnte. Also Interrupts verwende ich nichts, beim starten des µC stellt er ein, dass er die eine Message sendet, und dann eine endlose while Schleife, und Interrupts werden nicht verwendet. mfg Franz
TManiac schrieb: > Äh. nöö. > > Wenn gar kein ACK auf dem Bus auftaucht sollte der Controller in den > BUSOFF State gehen und nicht mehr senden. Steht auch so im Manual im > Kapitel "19.7 Error Management" (ich habe nun doch mal das Manual > rausgesucht). Wenn er eben durch irgendetwas ge-reset-ed wird, wird er > immer weiter, bzw immer wieder senden. Wie sieht die Interrupt-Routine Äh. Nöö :-) Erhält der Sender kein ACK im ACK Slot erhöht er den Transmit Error Count nur solange er "error active" ist. Irgendwann wechselt er dann in "error passive" aber nicht in "bus off". Siehe Note auf Seite 27 von http://www.bosch-semiconductors.de/media/pdf/canliteratur/can2spec.pdf
1 | Note: |
2 | Start-up / Wake-up: |
3 | If during start-up only 1 node is online, and if this node transmits some |
4 | message, it will get no acknowledgment, detect an error and repeat the |
5 | message. It can become ’error passive’ but not ’bus off’ due to this |
6 | reason. |
Das führt dann dazu das, wenn nur ein Teilnehmer am Bus ist dessen erste (oder höchstpriore) Nachricht endlos wiederholt wird. Das ist das ganz normale Startverhalten des CAN Bus. Matthias
Upps, dann nehme ich alles zurück und behaupte das Gegenteil :-) Danke für das Zitat aus der Bosch-Spec. Damit ist ja alles geklärt. (ich hätte es ja einfach mal ausprobieren können) Gruß, TManiac
Ich hätte noch eine Frage undzwar, wenn ich eine CAN Nachricht manipulieren möchte, indem ich 2 CAN Controller verwende, und die dazwischenschalte, ist der AT90CAN schnell genug um alle Nachrichten durchzuleiten? Bis auf eine auf die ich hald warten muss. Das heißt ich müsste alle Filter ausschalten, und bei einem Interrupt ( Message empfangen ) direkt auf senden umschalten, und die empfangene Nachricht über einen anderen CAN Controller rausschicken. Wisst ihr wie ich meine? Ich denke der AT90CAN wird zu langsam sein für soetwas, aber gibt es einen logischen Schaltungsaufbau der mir die Sache vereinfacht? mfg Franz
Angehängte Dateien:
-
K800_P1010172.JPG
82 KB
Ich habe das ganze jetzt ans Auto gehängt, es soll folgendes machen, gleich nachdem er etwas von der ID 0x201 empfängt, sendet er mit der ID 0x299 etwas aus. Soweit funktioniert das auch, ABER! schaut euch bitte mal den Anhang an. Das ausgesandte, ist nie auf dem BUS zu sehen. Obere Kurve = Tx vom AVR / MCP2551 untere Kurve = Rx vom AVR / MCP2551 Eigentlich sollte ja, wenn alles passt die beiden Kurven gleich sein, wenn der AVR etwas aussendet, ist aber absolut nicht, obwohl hierfür eigentlich kein Grund ist oder? Danke! mfg Franz
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.