µC + 2x MCP2515 zum Filtern

Hi!

Ich rätsel gerade ein wenig.

Ich habe mir einen STM32 (bzw. Nucleo F303K8) gekrallt und an diesen zwei MCP2515 angeschlossen. Senden und Empfangen funktioniert soweit wunderbar.

Was ich eigentlich erreichen möchte, ist, dass ich eine Headunit an den einen MCP2515 und das dazugehörige Display an den anderen anklemme. Das was von einem reinkommt, wird bei dem anderen rausgesendet und andersherum.
Ich möchte so zum einen sehen, welche Nachrichten von welchem Gerät kommen und außerdem möchte ich einzelne IDs herausfiltern können. Soweit die Theorie. An sich funktioniert das auch schon, ABER: Sobald viele Daten kurz hintereinander kommen (wenn ich z.B. ein umfangreiches Menü öffne), werden Nachrichten gedroppt und das Öffnen des Menüs scheitert natürlich.
Es sieht einfach so aus, als wenn er die RX-Buffer nicht schnell genug abrufen könnte. Egal wie ich es drehe und wende (eigenen TX-Buffer erstellt, dem Empfangen höhere Prio geben, serielle Ausgabe deaktiviert, etcpp), es hilft nichts. Es läuft so unzuverlässig .

Bevor ich jetzt weiter versuche jedes Fitzelchen zu optimieren um es irgendwie ans laufen zu kriegen: Ist mein Vorhaben überhaupt so machbar??? Ich mein, das was ich da gerade mache, wäre für mich nur ein Nice-To-Have und ich muss das nicht 100% lauffähig haben, aber ich dachte mir, dass mir das evtl. zukünftige Aktionen vereinfachen kann, wenn ich so schön was zum Zielgerät rausfiltern könnte. Ideen?

Gruß
Sven

Hast du die Interruppt Pins der MCP2515 auf je einen Eingangspin des STM gelegt?
Damit meldet sich jeder MPC Harwareseitig ob was im Buffer ist.
Ich habe so keinen einzigen verlorenen Frame

Hallo,

was Du vorhast macht mein FIS Blocker genauso, sprich er sitzt zwischen (in meinem Fall) Radio und KFZ im Infotainment CAN Bus. Basiert auf einem STM32F4, der hat 2 integrierte CAN Schnittstellen. Man spart sich also den ganzen SPI Kram.

Ich hatte noch nie Dropframes. Der STM32 läuft mit 186MHz, die CAN Schnittstellen werden per Interrupt abgefragt.

Nutzt Du Polling, irgendwelche Wait-Statements oder evtl. unnötige langsame serielle Ausgaben?
Schau Dir mal ein STMF4 Discoveryboard an.

Der STM32 ist eigentlich schnell genug, daß bei passender Programmierung keine Nachrichten verloren gehen sollten.

Ich glaube ich habe gestern spät abends das Problem gefunden. Es war wahrscheinlich gar kein Softwareproblem, sondern ein Kontaktproblem zwischen einem Transceiver und dessen MCP2515... Steckbrett halt . Werde das mal beobachten.

Hatte mit einem Saelae Logic gesehen, dass zu einen Random Zeitpunkt total randale auf dem SPI-Bus war, aber keine neuen Interrupts von dem MCP kamen, was darauf schließen lies, das mein µC immer wieder nach freien TX-Buffer Plätzen gefragt hat, aber wohl keiner frei wurde.

Aber danke für die Anregungen .

Steckbrett ist soooo oft das Problem

Nur so als Tipp: Schau Dir mal den Teensy 3.6 an, der ist Arduino kompatibel, hat 2 CAN Interfaces, SD Slot, ist klein und sehr sehr schnell. Da einfach 2x 3.3V CAN Tranceiver dran und die Samples laden für Dual CAN. Einfacher gehts kaum.

Eine CAN Schnittstelle hat der Nucleo auch direkt, aber mir ist nicht ganz klar wie ich da das Timing hinbekomme. Ich brauche was ziemlich krummes für den Infotainment Bus von Opel, nämlich 95,238kbps.