CAN Schnittstelle für FreeBSD

@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.
 
Danke. :) [Ich war etwas bzgl. "Hirnakrobatik" gedanklich zu sehr auf diese Konstante "eingeschraenkt".]
 
image.jpeg
 
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 von einem Moderator:
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.
 
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 "[url=https://elixir.bootlin.com/linux/v4.14/source/drivers/net/can/slcan.c#L191]kollidieren[/url]".

Einfach geil, so etwas verfolgen zu können.

Danke. :)
 
Zuletzt bearbeitet von einem Moderator:
Im Rahmen von Debugging wurde [als parallel verlaufender Entwicklungszweig] begonnen if_slc(4) nach NetBSD 8.0 zu portieren.
 
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.
 
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
 
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/
 
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.
 
Im Prinzip ist das wie UDP mit max 8 Bytes und nicht wie TCP ;)
Tatsächlich hat CAN ein nicht-acknowledge. Jeder Empfänger kann damit ein neu Versenden der Botschaft veranlassen. Es sitzt also zwischen UDP und TCP. Der kritische Unterschied ist, dass es keinen expliziten Empfänger gibt.
 
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. :)
 
Zurück
Oben