Hallo, ich habe mal eine Frage zu einer Überlegung bezüglich CAN. Wenn ich ein Embedded Device entwickeln wöllte, dass nach aussen eine CAN-Schnittstelle etwa über einen Sub-D 9 Stecker anbieten würde und ich in dem Embedded Device folgende (senden und empfa zwei Applikationen hätte: - Applikation A: Muss alle Botschaften in einer Textdatei tracen - Applikation B: Muss über vielleicht eine Hand voll an Botschafts-IDs ein höheres Protokoll abhandeln (senden und empfangen) und ignoriert die restlichen Botschaften Wäre es sinnvoll dies per Hardware so zu lösen, dass sich hinter dem Sub-D 9 Stecker zwei CAN-Controller befinden und ich in meinem Embedded Device quasi zwei (virtuelle?) CAN-Knoten realisiere? Die Applikation B könnte dann ihren CAN-Controller mit einem Botschaftsfilter initialisieren und es könnte je ein Thread auf einem CAN-Controller rumrödeln... Oder sollte ich das über die Software lösen? Grüße
Wenn du eh alle Nachrichten in Applikation A empfängst ist ein zweiter Controller doch quatsch. Wenn die gewünschten Nachrichten in Applikation A empfangen wurden setzt du einfach ein Flag für Applikation B. Fertig! Oder habe ich was übersehen?
Hi Hängt noch von ein paar Randbedingungen ab (Bitrate, Ziel für die Textdatei) aber wenn der µC einen internen CAN-Controller hat ganz klar eine Softwarelösung. Matthias
Ne das siehst du schon richtig. Ich hätte halt dadurch erreicht, dass beide Applikationen unabhängig voneinander laufen, ich keine Threads synchronisieren muss und ich nicht jede Botschaft daraufhin überprüfen muss, ob sie eine von den wenigen ist, die für das Protokol verwendet wird...
Wenn du einen halbwegs leistungsfähigen Mikrocontroller hast (zB STM32F103 mit integriertem CAN-Controller) ist das einzig sinnvolle alles auf dem einen Controller zu machen. Dank Filter-Bänke ist das Unterscheiden der Nachrichten kein Problem. Threads sind unnötig, dafür gibt's ISRs...
Hallo, also ich würde die CAN Controller wohl extern anbinden müssen. Es würde ein x86 Prozessor verwendet werden, der keine CAN Controller integriert hat. Als Betriebssystem würde Windows Embedded Compact (7 / 2013) zum Einsatz kommen. Ich würde dann wohl Win32 Threads, Semaphoren und Events verwenden...
Habe ich auf einem CortexM3, M4 und einem Core2 in Software gemacht... stellt bei halbwegs passender Implementierung keine Probleme dar. Bedenke aber die Latenzen die Windows mit sich bringt... Die HW filter brauchst du nicht.. die paar Packerl kann die CPU so auch locker durchforsten ;) 73
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.