Hallo, ich habe jetzt eine CAN-Kommunikation mit 5 Teilnehmer aufgebaut. Dies funktioniert auch schon. Also ich kann Daten an bestimmten Teilnehmern senden. Was ich aber nicht verstanden habe, sind die Anzahl der Buffer. Jetzt hat mein Controller 2 Sendebuffer und 3 Empfangsbuffer. Wozu sind diese da? eigentlich benötige ich doch nur einen oder? Weil beim Senden wird doch eh immer der erste Buffer rausgesendet. Wozu sind die anderen gut? Karsten
Karsten schrieb: > Wozu sind diese da? eigentlich benötige ich doch nur einen oder? Weil > beim Senden wird doch eh immer der erste Buffer rausgesendet. Wozu sind > die anderen gut? Damit der Prozessor nichst sofort springen muss, sobald ein Puffer leer/voll ist.
Weil die Leute, die CAN machen irgendwie glauben, das Ding macht magische Dinge. Deshalb glauben die auch, dass man nur ein Datentelegramm senden muss, und es kommt dann garantiert an. Da CAN aber auch nur mit Wasser kocht (sogar eher nur mit lauwarmen) gibt es Dinge wie Kollisionen oder Übertragungsfehler. Die fängt zwar der Controller bis zu einem gewissen Grade ab, es kann aber trotzdem sein, dass es relativ lange dauert, bis der Controller sein Datentelegramm abschicken kann und er eine positive Bestätigung bekommt. So lange muss das gespeichert werden. Und da sind halt Sendebuffer sehr angenehm, weil Du dann schon mal 2 Telegramme rein schreiben kannst, bis Du warten musst. Dazu kommt noch, dass CAN halt im Automotive-Bereich eingesetzt wird, und da verstehen die Leute häufig nicht was sie machen, was dazu führt, dass das Betriebssystem durch Fehlbenutzung schon mal 90% der Zeit mit Taskswitches verbringt. Da ist es gut, wenn die Hardware mal etwas zwischenspeichern kann, und die Buffer nicht gleich voll laufen.
Christian B. schrieb: > Dazu kommt noch, dass CAN halt im Automotive-Bereich eingesetzt wird, > und da verstehen die Leute häufig nicht was sie machen, was dazu führt, > dass das Betriebssystem durch Fehlbenutzung schon mal 90% der Zeit mit > Taskswitches verbringt. Da ist es gut, wenn die Hardware mal etwas > zwischenspeichern kann, und die Buffer nicht gleich voll laufen. Kannst du dazu eine Quelle nennen? Würde mich sehr interessieren. Vielen Dank und Gruß
Ich finde diese negativen Behauptungen auch sehr gewagt - so ohne Quellen Angabe.
Stefan U. schrieb: > Ich finde diese negativen Behauptungen auch sehr gewagt - so ohne > Quellen Angabe. Mein Ironie-Detektor fand Casandros Kommentar äußerst vergnüglich.
Im Automitive-Bereich gibt es sogar viel mehr Buffer so ca. 60 - 64. Man konfiguriert hier oft für Rx-Messages einen Buffer pro Message. Damit versucht man zu vermeiden, dass der Controller Messages verliert, falls er gerade mit irgendwas anderem beschäftigt ist. Die Buffer sind ja Hardware mit ner ID-Maske davor und werden ohne die Beteiligung der CPU durch die CAN-Zelle im Controller erstmal automatisch mit der aktuellen Message vom Bus befüllt. Anschließend kann die CPU sich diese Message auch etwas zeitversetzt abholen.
Hm, von welchen Prozessoren redest du da? Hauptsächlich begegnen mir immer wieder C167 und XC167.
R.B. schrieb: > Anschließend kann die CPU sich diese Message > auch etwas zeitversetzt abholen. Könnte man nicht einfach dem Empfangs-Interrupt eine hohe Priorität verpassen, sodass er den Prozessor bei seinen Tätigkeiten unterbricht und die Nachricht in einen (fast beliebig großen) RAM-Puffer kopieren kann? Von da kann der "Hauptprozess" die Nachrichten dann abholen wenn er Zeit hat.
So kenn ich es. Und das macht die vielen Empfangsbuffer absolut entbehrlich (es sei denn, es läuft Windows drauf :-) ) 5 halte ich für absolut ausreichend, selbst eine ganz kurze Botschaft bei 1MBit dauert um die 50µs, schneller kommen sie also nicht rein.
Hallo, und wie ist es mit einem Gateway z.B. mit 3-6 CAN Bus + 2 Lin uvm? In dem Fall sind grössere Buffer ratsam.
Programmierer schrieb: > Könnte man nicht einfach dem Empfangs-Interrupt eine hohe Priorität > verpassen, sodass er den Prozessor bei seinen Tätigkeiten unterbricht > und die Nachricht in einen (fast beliebig großen) RAM-Puffer kopieren > kann? Von da kann der "Hauptprozess" die Nachrichten dann abholen wenn > er Zeit hat. Welche MCU man wählt mit wievielen Buffer ist je nach Usecase bzw. Steuergerät unterschiedlich. Habe ich ein Motorsteuergerät oder ein Bremssteuergerät - dann will ich auf keinen Fall vom CAN in meinem Hauptprozess / Hauptfunktion (z.B. Bremsvorgang) gestört werden. Hier verpasse ich lieber eine der Botschaften, die mir irgendeine aktuelle Statusinformation mitteilt oder irgendwelche Sensorwerte von der langsamen Sorte (z.B. Temperatur) übermittelt. Bei einem reinen Gateway (gibt es im Auto selten) - wo der Schwerpunkt tatsächlich auf der Kommunikation liegt - verwendet man eher weniger Buffer. Ich kann einige Beispiele nennen von den Steuergeräten - die ich mitentwickelt habe: Klimaanlage 16 Buffer Scheinwerfer 64 Buffer Kamerasystem 16 Buffer Anhängersteuergerät 5 Buffer BCM (Body Control Module) mit Gateway 16 Buffer pro CAN, 1 Buffer pro Lin Die Entscheidung für einen Controller ist sehr stark davon beeinflusst - welcher Hersteller im Unternehmen bereits eingesetzt wird wegen Tools und bereits vorhandener Erfahrung. Man versucht dann auch möglichst bei einem Hersteller zu bleiben um die ganzen Treiber nicht neu schreiben zu müssen. Ein Wechsel wird meistens nur aus Kostengründen vollzogen. Die Entscheidung welche Buffer man wie konfiguriert und wieviele für Rx und Tx verwendet werden wird nicht einfach so "from scratch" getroffen, sondern aus der Sicht der Applikation festgelegt und während der Entwicklung optimiert. Es gibt controller, bei denen ich einen Buffer als Full-Can oder als Basic-Can konfigurieren kann (Die Terminologie ist auf den hier bereits erwähnten PPC bezogen). Full-CAN empfängt genau eine einzige Botschaft und Basic emfängt mehrere - sozusagen gemultiplexed. Hierbei habe ich die Freiheit alles so zu konfigurieren - wie ich es gerne mag. Hier ist auch die Konfiguration von 5 Buffer mit nem Interrupt möglich.
H.Joachim S. schrieb: > Hm, von welchen Prozessoren redest du da? Hauptsächlich begegnen mir > immer wieder C167 und XC167. Aber in Serie immer weniger, oder? Am meisten verbreitet sind wirklich die PPC von Freescale. Zunehmend sehe ich aber auch Arm-Basierte MCUs im Automotive. Seitdem Hersteller, wie Freescale und Fujitsu den Arm anbieten sowieso. Von Infineon selbst wird sehr gerne der Tricore genommen, ist aber nicht so stark verbreitet wie MPC. Generell verwendet man selbst für kleine Steuergeräte zunehmend gerne 32-Bit Controller. Freescale hat hier sehr kleine Power-PCs zu sehr günstigen Preisen auf dem Markt. Die ganzen Arms von NXP STM usw. gibt es ja auch in sehr kleinen Packages. Von Infineon werden aber auch sehr gerne Stromaufbereitende Bausteine im Automotive-Bereich eingesetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.