CAN auf PIC18F26K80 (generell ECAN-Modul)

[Anon X. (pascalx)]

Hallo zusammen,

Ich entwickle gerade eine Anwendung, in welcher CAN-Knoten mit je einem 
PIC18F4580 bzw. PIC18F2680 kommunizieren. Senden und Empfangen läuft 
dabei über Interrupts, im Mode 2 (FIFO mode).

Im Loopback-Mode funktioniert soweit alles, wobei eine Überraschung war, 
dass es nicht ausreicht, den Transmit-Interrupt zu enablen (TXBnIE=1), 
sondern dass beim ersten Mal das Interrupt-Flag manuell gesetzt werden 
muss (es wird nicht bei verfügbarem TX-Buffer gesetzt (wie z.B. bei der 
UART), sondern nur wenn zuvor ein CAN Frame erfolgreich gesendet wurde). 
Die Senderoutine sieht inetwa so aus:

  // ... Daten in die Transmit-FIFO füllen, die später von
  //     der ISR ausgelesen und via TXB0 versandt wird

  PIE3bits.TXBnIE = 1;  // Interrupt enablen
  PIR3bits.TXBnIF = 1;  // Interrupt Flag beim ersten Fall manuell 
setzen

Was ich nun trotz X-fachem Lesen der ECAN-Dokumentation nicht verstehe, 
ist was bei Fehlern passiert.

Im 4580-Datenblatt steht unter "23.14 Error Detection", dass bei CRC 
error, form error, bit error, und stuff bit error die Nachricht 
automatisch wiederholt wird. Soweit so gut. Bei "Acknowledge error" 
steht aber einfach, "the message will have to be repeated" (im Gegensatz 
zu "The message is repeated" bei den anderen Fehlern). Heisst das nun, 
dass ich das in Software veranlassen muss? Ich dachte, genau bei 
fehlendem Acknowledge ginge das automatisch.

Das andere, was mir nicht klar ist, ist was passiert, wenn Fehler 
wiederholt auftreten. Dann geht der CAN-Knoten ja erst in Error-passive 
und später sogar in den Bus-off Modus. Später wird der Knoten irgendwann 
wieder automatisch aktiv. Was passiert nun mit der "steckengebliebenen" 
Message? Wird diese automatisch wieder gesendet, da das TXREQ-Bit noch 
gesetzt ist? Oder kann der Fall oben entstehen, bei welchem kein 
TXBnIF-Interrupt generiert wird, da die Message ja nicht erfolgreich 
versandt wurde?

Langer Rede kurzer Sinn: Ich blicke nicht durch, ob es noch Umstände 
gibt, in denen das Senden via Transmit-Interrupt aus oben genannten 
Gründen stehenbleiben kann. Die entsprechenden Fehler gezielt zu 
provizieren dürfte auch sehr schwierig sein.

Danke für Euren Rat

Pascal