CAN mit ATMega128 und MCP2515

das liegt an der Software! (wo ist sie denn?)
-status lesen
-id lesen
-length lesen
-entsprechende anzahl von Datenbytes abholen
-interrupt-flags löschen

ich vermute, du hast letzteres vergessen.
in der Art:
// Interrupt Flag löschen
  if (status & 0b01000000){      //Bit 6 set?
    mcp2515_bit_modify(CANINTF, (1<<RX0IF), 0);
  } else {
    mcp2515_bit_modify(CANINTF, (1<<RX1IF), 0);
  }

Ich würde sagen, dass der externe Interrupt momentan auf den Lowpegel
reagiert und nicht auf die negative Flanke.
Bei der Einstellung auf den L-Pegel bleibt der Interrupt so lange
aktiv, wie er freigegeben ist. Der Controller springt also in die ISR,
bearbeitet sie und springt sofort nach Beendigung wieder in die ISR.

nene, pegelgesteuert ist schon richtig.
Und wenn der MCP gelesen und dessen Interruptanforderung zurückgesetzt
ist, nimmt der MCP auch den L-Pegel von der Leitung. Das passiert alles
noch in der ISR.

Warum sollte man es nicht per Flanke machen? Wegen Spikes? (Nur so
interessehalber)

damit du solche Spässchen wie hier auch erkennst :-)
Der MCP hat ja mehrere Interruptquellen, die alle auf einer Leitung
angezeigt werden. Und nur wenn die Anforderung richtig bearbeitet
wurde, kannst du die ISR auch verlassen.
Theoretisch ginge es auch flankengesteuert, gewinnen würdest du dabei
aber nichts.
Ausserdem funktionieren diverse Aufwachfunktionen nur mit
pegelgesteuertem Int, das habe ich schon mehrfach benutzt. Also Frage
andersrum: warum sollte man es per Flanke machen?

Pegelgesteuert ist schon richtig.
Denn tritt ein INT auf, springt der Pegel auf 0, du arbeitest ihn ab,
löschst das Flag, beendest die ISR. Das Flag vom INT wird gelöscht.
Ende. Das aber während deiner ISR nochmals ein anderer INT am MCP2510
aufgetreten ist, kriegste nicht mit. Genausowenig wie alle noch
kommenden INTs, da der MCP2510 den Pegel konstant unten hält (es steht
ja noch die Bearbeitung eines INTs aus)

Danke! Den MCP2515 hatte ich damals nur durch Polling betrieben...
Wird wohl Zeit, das Ding mal wieder zum Leben zu erwecken...

Hallo zusammen,

ich habe noch ein bischen probiert und den "Hauptfehler" gefunden.
Habe auch mal auf Flanke gestellt gehabt, aber dann ging der CAN nicht
(wenn der MC doch mal hochgekommen ist).
Ich habe als erstes den MC initialsiert und den Interrupt freigegeben.
Danach die 6 Displays initialisiert usw.
Nach all dem Zeug habe ich den MCP resetet und eingestellt.
Das heist es verging schon eine ganze Zeit bis der MCP dran war.
Die ganze Zeit war auch der L-Pegel am Interrupt. Und deshalb habt ihr
recht, das er die meiste Zeit in der Interruptroutine verbracht hat.
Jetzt aktiviere ich das Globale Interruptflag erst nach dem Reset und
der initialsierung der ganzen Display und des MCP und er läuft.
Was ich aber nicht verstehe ist, das nach dem ersten Durchlauf der
Int.Routine der MCP nicht den Interrupt zurücknimmt.
Kann es sein, das beim MCP defaultmäßig noch ein andere Int-Quelle
aktiviert ist (Bufferüberlauf oder so)?

Gruß