Frage zum CANHandler

Ja. das kannst Du so sagen.
Das Interrupt auslösen würde ich eher bei CAN-Treiber als beim Handler 
sehen.

Aber dsa ist Glaubenssache.

Muss ich mir dann den CANHandler als einen eigenen Thread vorstellen? 
Der Filter muss ja "clever" programmiert sein, damit der Prozessor nicht 
zu stark ausgelastet wird.

Thread ? <-> OSEK-Betriebssystem?

Filter <-> clever programmieren ?

32Bitter <-> stark ausgelastet?

Michael,

bitte, ein Mikrocontroller ist kein PC !

Wenn Du einen 1MBaud CAN-Bus hast, dann würde er bei Volllast ca 6000 
8Byte Botschaften im 2.0 A- Standard (11-Bit-Identifier) maximal 
übertragen können. D.h. Deine maximale Bearbeitungfrequenz wäre 6 kHz. 
Und das ist selbst für einen ATmega kein Kunststück.

Also, ich habe einen ATMega mit einem MCP2515 zum CAN-Bus-Sniffen 
eingesetzt.

Der Mega (lumpiger 8-Bitter mit 16 Mhz - Quarz) brauchte über SPI nur 
ca. die halbe CAN-Botschaftsdauer, um die Daten aus dem externen 
Controler in den MCU zu kopieren. Der Kopiervorgang umfasst CAN-ID, DLC, 
DATEN. Also 12 Bytes. Ich glaube das waren ca. 68µs. Ich habe auch den 
SPI mit 8 MHz gequält, was eigentlich out of Spec ist. Es funktioniert 
bis heute.

So, jetzt hast Du erst einmal Zahlen...

Das Filtern habe ich erst im MCU gemacht. D.H. der Mega hat jede 
Botschaft in die Hände nehmen und bearbeiten müssen. Und das hat der mit 
eine Buslast von 60% geschafft.

Soweit zur Praxis.

Was willst Du jetzt machen?

Wie hoch ist Deine Datenrate auf dem CAN?

Wie willst Du die CAN-Botschaften weiterverarbeiten?

Threads, die asynchron parallel arbeiten, müssen sich auch verwalten 
bzw. sich gegenseitig verriegeln.

Ich arbeite mit einem kooperativen Round-Robin-Scheduler. Und der 
schafft das auch...

Danke für die ausführliche Antwort aber mir gehts eigentlich nur um die 
Definition des CANHandlers, da ich darüber so gut wie nichts gefunden 
habe.

Aber mal zu deiner Antwort: Klar die reine CAN-Geschichte sollte ein µC 
locker packen aber wie sieht das z.B. in einem Motorsteuergerät aus? Ok 
da ist dann ein Tri-Core drin aber der Controller kann sich ja trotzdem 
nicht jede Nachricht ansehen und überprüfen ob er sie wirklich braucht. 
Daher ist mein Verständnis so, dass der Prozessor nur die Messages 
bekommt, die auch wirklich für die Applikation benötigt werden. 
Ansonsten kommt ständig ein INterrupt mit einer neuen, nicht benötigten 
Message und andere Applikationen werden dadurch unterbochen.

Nun Michael,

der TriCore ist eine ganz andere Liga.

Der besteht, wie der Name schon sagt, aus drei Prozessorkernen.

1. der Mikrocontroler mit parallen Pipes (mehrfach bearbeitung von 
Befehlen zur gleichen Zeit)

2. den digitalen 64 oder 128 Bit breiten Signalprozessor

und

3. der Peripherieprozessor.

und der letzte macht genau diese Stumpfsinnsarbeiten und kopiert über 
einen Dualported-RAM (wird häufig so gemacht - ist aber keine Pflicht) 
die extrahierten Signale für die Applikationen, der Prozessor unter 1. 
dann mit der Applikation berechnet. Er braucht sich um die 
CAN-Datenlogistik nicht mehr kümmern.

Außerdem sind im Steuergeräteverbund die zu emfangenen und sendenen 
Signal im Vorfeld abgestimmt. (CAN-Kommunikaitons-Matrix)

Dadurch hält sich der Arbeitsaufwand sehr in Grenzen.

Der TriCore und andere 32-Bitter bewältigen die umfangreichen Aufgaben 
durch Parallelisierung...