• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

CAN Schnittstelle für FreeBSD

schorsch_76

FreeBSD Fanboy
#51
@das.chaos Wie du ja siehst, beschränkt der Wert die maximale Anzahl der Schleifen Durchläufe. Deshalb glaube ich, das der Wert rein durch empirische Ermittlung entstanden ist an einem der Systeme der Entwickler.
 

das.chaos

Duracellhase 2.0
#55
Auf dem Screenshot wurden fuer Unit Tests [im Zusammenhang mit dem High Level Interface] zwei Stationen ganz einfach mit RS-232 vernetzt.

Das Ueberarbeiten von if_slc(4) musste sein, damit bspw. eine Station mit einem PCI Adapter [der den SJA1000 Controller integriert] mit einer anderen Station [bspw.] per USB2CAN Adapter [allein schon aus Kostengruenden :zitter:] vernetzt wird.

Ziel ist es [irgendwann] sich auf das und [eventuell] das "einzuschiessen".
 
Zuletzt bearbeitet:

pit234a

Well-Known Member
#56
ich verstehe hier schon lange nichts mehr, lese aber interessiert mit und wollte einfach mal ein Lob loswerden, für diese Beharrlichkeit und auch den Informationsfluss.

Einfach geil, so etwas verfolgen zu können.
 

das.chaos

Duracellhase 2.0
#57
Ich verstehe hier schon lange nichts mehr, lese aber interessiert mit und wollte einfach mal ein Lob loswerden, für diese Beharrlichkeit und auch den Informationsfluss.
Der Network Stack vom FreeBSD Kernel unterteilt sich [bei _oberflaechlicher_ Betrachtung] in drei Schichten:
  1. Interface Layer
  2. Protocol Layer
  3. Socket Layer

if_slc(4) ist der Glue zwischen ein "Terminal" und der can(4) Communication domain(9), der sich in der Interface Layer befindet.

D. h. es wird eine Schnittstelle [oder eine Dienstzugangspunkt] implementiert, der aehnlich verwendet werden koennte, wie es hier beschrieben wird.

Es ist eine Herausforderung nicht mit GPL lizensiertem Code zu "kollidieren".

Einfach geil, so etwas verfolgen zu können.
Danke. :)
 
Zuletzt bearbeitet:

Kamikaze

Warrior of Sunlight
#61
Was ich gar nicht verstehe ist wie man das alles benutzt. Ich habe ja viel Erfahrung mit CAN und auf der Busebene kümmert man sich da um so Sachen wie die Busgeschwindigkeit (die stellt man in der Regel fest ein), den Samplezeitpunkt um den richtigen Kompromiss zwischen möglicher Kabellänge und Anpassbarkeit der Länge eines Bits.

Auf der Applikationsebene arbeitet man mit Signalen und Botschaften. Botschaften haben eine Id (Standard oder Extended) und Länge in Octets. Außerdem implizite Merkmale wie die Zyklusszeit (wenn es keine Event-Botschaften sind). Signale haben eine Position, Länge in Bits und Endianess. Eine Botschaft kann mehrere Signale haben, Motorola und Intel Endianess kann munter gemischt werden.

Das alles lässt sich für mich nicht so toll auf ein Ethernet Interface abbilden.
 

serie300

Well-Known Member
Themenstarter #62
Mir geht es da wie Kamikaze, komme auch aus der mcu Ebene. Deswegen hatte ich mich rausgehalten. v.a. auch weil CAN m.W. vom Ansatz her anders ist wie Ethernet und ich meine nicht den phys. (elektrischen) Layer.

Serie300
 

schorsch_76

FreeBSD Fanboy
#63
Unter Linux gibt es das schon als Netzwerkprotokoll. Du hast dann eben slcan0. Du stellst die Baudrate mit dem slcand ein (bei serieller Anbindung). Beim sja1000 wird das beim "ip up" des Interfaces eingestellt.

Mit dem offenen Socket kannst du eben Can Pakete verschicken. Diese haben maximal 8 Nutzbytes, ein DLC und eine CobID. Damit kannst du dann CanOpen ansprechen oder alles andere. Dadurch das du einen Socket hast, nutzt du auch die normalen read/write Funktionen auf dem Socket.

https://de.wikipedia.org/wiki/SocketCAN
https://github.com/linux-can/can-utils/
 

Kamikaze

Warrior of Sunlight
#64
Ich habe bei CAN immer mit .dbc Dateien gearbeitet. Das ist ein proprietäres Datenformat von Vector in dem man ECUs, Botschaften und Signale beschreibt. Inklusive Umrechnungsfunktionen, Enums, Defaults, Zykluszeiten etc..

Dafür habe ich einen Parser der mir mit ein paar Templates den ganzen Code generiert um mit den Botschaften und Signalen zu arbeiten.
 

das.chaos

Duracellhase 2.0
#67
Moin, "Socket CAN" deckt mWn die Schichten 1 bis 3 vom OSI-Modell ab [wie es mir beim Lesen des Quellcodes der Implementierung im Linux Kernel aufgefallen ist], wobei dann die Implementierung der Schichten darueber anscheinend sich je nach Hersteller unterscheiden, wie ich vermute, wobei ich mangels praktischer Erfahrung zu wenig Hintergundwissen habe.

Wollte anmerken, dasz ich bald wieder an dem Kram weiterarbeiten werde, da ich noch etwas anderes [mit JavaScript *heul*] zu erledigen habe. Bin ja mit dem Treiber fur den SJA1000 eigendlich schon auf der Zielgeraden bzw. fast fertig. :)