Hallo, mir ist gerade der Begriff des CANHandlers untergekommen. Leider kann ich damit nicht viel anfangen aber vielleicht ihr. Ich habe das so verstanden, dass ein CANHandler ein Stück Code ist, der CAN-Nachrichten speichert, dann die gewünschten IDs filtert und einen Interrupt auslöst, wenn eine Nachricht mit der gewünschten ID empfangen wurde. Die Auswertung der Nachricht erfolgt dann in der Applikation selbst. Kann man das so sagen oder habe ich das falsch verstanden? Viele Grüße Michael
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...
Bitte 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.