Hallo, ich verwende hier momentan in einem Roboter I2C und bin am überlegen auf CAN Bus umzustellen. Habe mir dazu nun ein wenig etwas durchgelsen und das scheint I2C ja relativ ähnlich zu sein und da stellt sich ein Problem, was mich primär bewegt von I2C weg zu gehen. Ich habe viele Controller, die alle aktiv senden können müssen, sprich Multi-Master. Das geht ja mit I2C auch, jedoch gibt es da ein Kollisionsproblem. Angenommen zwei Controller wollen gleichzeitig etwas senden, sagen wir Controller A und B. A will etwas an B senden und B an A. Beide fangen gleichzeitig an zu senden, dann verliert ja irgendwer von den beiden die Kontrolle, hält die Klappe und bricht seinen Sendevorgang ab, sagen wir A. Nun Wollte B ja an A etwas senden, der hat jedoch den Beginn der Mitteilung nicht mitbekommen, sprich er wird auf die Anfrage nicht reagieren. Nun meine Frage: Ist das bei CAN auch so? Edit: Arg ich sehe grade CAN scheint komplett ungeeignet laut Wiki: Verwenden beide Teilnehmer den gleichen Identifier, wird nicht sofort ein Error-Frame erzeugt (siehe Frame-Aufbau), sondern erst bei einer Kollision innerhalb der restlichen Bits, was durch die Arbitrierung ausgeschlossen sein sollte. Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal einem Teilnehmer verwendet werden soll. Bedeutet wohl, dass jeder Slave nur einen Master haben darf?
Fabian S. schrieb: > Nun meine Frage: Ist das bei CAN auch so? In üblicher Einstellung wird die unterlegene Node es danach erneut probieren. Macht der CAN Controller automatisch.
Fabian S. schrieb: > Verwenden beide Teilnehmer den gleichen Identifier, Was nicht sein darf. > Bedeutet wohl, dass jeder Slave nur einen Master haben darf? Nein. Das bedeutet nur, dass man sich über die IDs bischen Gedanken machen sollte. Wenn mehrere Nodes die gleiche Art Message senden können, dann kann man beispielsweise eine Absender-ID reincodieren, die vom Empfänger ggf. ignoriert wird.
Aha ok, so teif stecke ich momentan noch noch in der Materie... Einfache Frage: Ich habe ein Haufen Controller (so 10-20) und jeder soll jedem Nachrichten zukommen lassen können, ohne dass die irgendwo unter gehen. Geht das?
Fabian S. schrieb: > Nun Wollte B ja an A etwas senden, der hat jedoch den Beginn der > Mitteilung nicht mitbekommen, sprich er wird auf die Anfrage nicht > reagieren. Warum sollte der Empfänger der Node das nicht mitgekriegt haben, bloss weil der Sender der Node mal was versucht hat?
A. K. schrieb: > Fabian S. schrieb: > >> Nun Wollte B ja an A etwas senden, der hat jedoch den Beginn der >> Mitteilung nicht mitbekommen, sprich er wird auf die Anfrage nicht >> reagieren. > > Warum sollte der Empfänger der Node das nicht mitgekriegt haben, bloss > weil der Sender der Node mal was versucht hat? :-/ Der Empfänger war ja bis zu Hälfte der Node mit Senden beschäftigt.
Fabian S. schrieb: > Einfache Frage: Ich habe ein Haufen Controller (so 10-20) und jeder soll > jedem Nachrichten zukommen lassen können, ohne dass die irgendwo unter > gehen. Geht das? Ja. Du kannst sogar so weit gehen, die ID in 2 Teile zu unterteilen. Eine Absender-ID und eine Adressat-ID. Oder die lange 29-Bit ID in 3 Teile, mit der eigentlichen Message-ID als drittem Teil. Das hatte Bosch bei der Erfindung von CAN zwar nicht im Sinn, aber so läuft das dann ähnlich wie Ethernet.
Bei CAN gibt es keine Geräte-Adressierung wie beim I2C und auch keine Master und Slaves. Die Identifier sind den einzelnen Messages zugeordnet. Der CAN-Controller hat dazu meist ein oder mehrere Akzeptanz-Filter für die Identifier die für ihn interessant sind. Wenn also Dein Roboter vorwärts fahren soll, sendet der "Master" einen entsprechenden Frame. Der Motor-Controller wertet diesen aus und steuert den Motor, ein anderer Controller kann z.B. die Kollisionserkennung nach vorn mittels Ultraschall aktivieren. Wird ein Hindernis erkannt, sendet der "Kollisions-Controller" z.B. ein Frame mit der gemessenen Entfernung. Dieses wird dann vom Steuercontroller ausgewertet, der dann wiederum einen neuen fahrbefehl sendet... Jeder Controller empfängt alle Frames, sein Programm entscheidet darüber, welche Meldungen für ihn interessant sind. Jörg
Fabian S. schrieb: > :-/ Der Empfänger war ja bis zu Hälfte der Node mit Senden beschäftigt. Mit "Sender" und "Empfänger" waren in diesem Fall nicht die Nodes gemeint, sondern die betreffende Komponenten in den CAN Controllern der jeweiligen Nodes.
Ach ja, da hatte ich wohl was in Tüdel gebracht, hatte das mit den Identifiern falsch verstanden. In den CAN Controllern gabs doch so Register wo man diese Identifier einstellen konnte. Würde also heißen wenn ich es sauber lösen will brauche ich einen Controller der ausreichend viele Identifier Register hat, denn der Hauptcontroller der das ganze mitm Laptop verbindet soll tendenziell alle Nachichten bekommen.
Fabian S. schrieb: > brauche ich einen Controller der ausreichend viele Identifier Register > hat, Nur wenn du bei der Vergabe der IDs so planlos vorgehst, dass die zig IDs, die eine Node empfangen soll, sich partout nicht per Filtermaske zusammenfassen lassen. > denn der Hauptcontroller der das ganze mitm Laptop verbindet soll > tendenziell alle Nachichten bekommen. Dann verpasst du dem einen Wildcard-Filter und er kriegt grundsätzlich alles. Bei den CAN Filtern gibt es immer einer Variante mit einer Maske, die sagt, welche Bits überhaupt relevant sind.
Ist ja genial, da hat Bosch ja ganze Arbeit geleistet :D Bin dann erst mal gefüttert mit Antworten, jetzt muss ich mir überlegen ob ich die ganze Hardware die ich schon habe nochmal auf CAN umbaue oder ein I2C MultiMaster System nutze. Weil habe inzwischen festgestellt, dass mit ein wenig Software I2C alles das was CAN kann auch kann, abgesehen von den mehreren Empfängern. Klar dieser General Call ist natürlich möglich aber das nicht gerade sauber, wenn das dann jede empfängt und dann erst in den Daten quasi der Identifier drin steht.
Gast
#1933904
Es gibt CAN Controller, die über einen Ringbuffer mit einem vorgeschalteten Akzeptanzfilter verfügen, z.B. SJA1000. Der Akzeptanzfilter lässt nur Can-Frames passieren, die einstellbare Bits in der CAN ID gesetzt haben. Wenn Du diesen ausschaltest, landen alle empfangenen Nachrichten in der Ringbuffer. Der Ringbuffer kann dann z.B. über einen uC ausgelesen werden.
Joa ich hatte jetzt so an den AT90CAN32 gedacht, kostet 5,20€ oder so und hat dann halt gleich den ATMega mit drin ;) Meine der kann da auch was mit Filtern und so. Edit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Denke mal das maskieren ist mit dem "Identifier Mask" gemeint?
Gast
#1933980
>abgesehen von den mehreren Empfängern. Kann kann auch >Klar dieser General Call ist >natürlich möglich aber das nicht gerade sauber, wenn das dann jede >empfängt und dann erst in den Daten quasi der Identifier drin steht. Im Gegenteil, es ist Teil des Can-Konzepts. Bei CAN entscheidet der Empfänger an Hand der ID einer Nachricht, ob diese für ihn interessant ist (im Gegensatz zu anderen Protokollen, bei denen der Empfänger über eine StationID angesprochen wird). http://de.wikipedia.org/wiki/Controller_Area_Network >AT90CAN32 > Denke mal das maskieren ist mit dem "Identifier Mask" gemeint? Vermutlich -- wurde ich aber an Deiner Stelle im Datenblatt nachlesen. Typischer Weise haben CanController mit mehreren CAN-Objekten keinen Ringbuffer, sondern EIN CanObjekt, das ein Register zum Maskieren hat (Akzeptanzfilter). Man muss selbst einen Ringbuffer schreiben, der die Nachrichten aus diesem Can-Object mit einer ISR ins RAM umkopiert. Die verbleibenden CAN-Objekte können nur EINER CAN-ID zugeordnet werden. Wie gesagt, eine reine Hypothese meinerseits -- der Blick ins Datenblatt schafft Klarheit :-)