CAN Schnittstelle für FreeBSD

Hallo Chaos,

ich finde es wirklich beeindurckend, daß du dich mit dem Netzwerk Interface abgibst.
Aber warum willst du dich unbedingt mit dem SJA1000 abmühen? Die meisten Adapter werden heute über USB (bzw. Bluetooth wäre auch ganz interessant) angeschlossen (weil das jeder Laptop hat) und haben Eigenintelligenz (z.B. "Sende alle 100ms ein bestimmtes Telegramm", interne Puffer, Filterblöcke, ...); du bekommst CAN auf einer MCU für lau. FreeBSD ist ggf. eh nicht so richtig echtzeitfähig.
Bei FreeBSD wäre für mich erstmal wichtig, daß {Buseinstellung (11bit / 11 und 29 bit), Bitrate, Abklatschen ja/ nein, Handhabung Spezialbefehle an einen Controller }, der Aufbau der übergebenen Nachricht beim Schreiben / Lesen.. standardisiert sind. Dann könnten Leute wie ich mit Python oder anderen Sprachen den Bus auslesen und Meßwerte speichern / darstellen. Mir ist z.Z. unklar wie das in FreeBSD gehandhabt weren soll.

Serie300
 
Nur weil FreeBSD "nicht echtzeitfähig ist" würde es rechtfertigen es nicht zu implementieren?

Bspw. sind Elemente bzw. Komponenten des BSD-Networkstack sind bspw. in QNX [RTOS] integriert.

Wiso ich mich mit dem Implementieren einer NIC beschäftige?

Weil ich einerseits keinen Bock auf GNU/Linux bzw. Monokultur habe und andererseits Bock drauf habe es zu implementieren.

Mir ist mMn die Welt der industriellen Feldbussysteme viel zu sehr GNU/Linux-lastig.

Zum Thema usb(4):

Nun, if_slc(4) ist ein RAD Prototyp fur eine tty(4) Device-driver Class, die das Interagieren bspw. mit usb(4) Devices [CDC-Class] zum Zweck hat.

Zum Thema "Handhabung" bei unixoiden Hosts:

Dafür böte sich das Ioctl(2) oder sysctl(3) Interface an.
 
Hallo Chaos,

ich finde es ja auch erstrebenswert, CAN auf dem FreeBSD Rechner zu ermöglichen :cool:. Ich glaube du hast mich falsch verstanden. Die Controller von denen ich sprach sind nicht Linux oder Wago Feldbus Adapter sondern nackte MCUs mit ein bisschen C SW und intelliegnter CAN HW (s. z.B. Teensy 3.x). Und sie können als "intelligente Terminal Adapter" dem Host eine Menge (z.T. zeitkritische) Arbeit abnehmen. Ich finde nur ein BSD Interface sollte nach oben eine durchdachte Schnittstelle bieten, sodaß einfach ASW dafür geschrieben werden kann. if_slcist doch schon mal eine feine Sache für drunter

Serie300.
 
@schorsch_76 Langsam steige ich dahinter: ich gucke mir die von Peak-Systems veroeffentlichte Code-base an und vergleiche diese mit dieser [weil diese Variante auf mich wesentlich "entspannter" oder generischer wirkt, da mMn nicht so "verbaut" bzw. verschachtelt - es ist irgendwie offensichtlich, wie notwendig stabile KPI sind oder waeren :ugly:], d. h. ich schiesse mich auf letztere ein - es _ist_ ein Stueck hartes Brot, aber mWn realisierbar [aber das wird einige Zeit beanspruchen].

Was ich mich frage, ob ich Elemente aus einer dual-lizensierten Header-file [GPL und BSD-3-Clause] in einer anderen unter BSD-3-Clause licence ohne GPL "recyclen" darf [siehe error.h in Code-base von Treiber von Peak-systems]?
 
Bei dual-lizensiertem Code kannst du dir theoretisch aussuchen, unter welcher der beiden Lizenzen du den Code nutzen möchtest. In der Praxis wäre ich vorsichtig, gerade wenn nicht klar nachvollziehbar ist, wer alles zu dem Code beigetragen hat. Ich hatte es schon mehrmals, dass plötzlich verwirrte GNUschisten (ich mag das Wort) auf der Matte standen und mit wüsten Drohungen forderten, dass ich bitte doch alles unter der heiligen GPL lizensieren müsse...
 
Jo, krass! :rolleyes: Da dachte ich waere schon sowas aehnliches wie ein "Fanatiker". Naja, GNUschisten passt aber irgendwie: ich erinnere mich da an einer Rede von Stallman, die ich entweder 2015 oder 2016 per Live-stream verfolgte [das war auf dem CCC Congress]. Wie wuest war das denn???

Du musst aber die Lizenz beachten.... Sonst ist alles für die Katz....

Danke. Mmmhhh, sonst werde ich einen "neuen" Namespace fuer die Konstanten "entwerfen", ... wird schon irgendwie "hingebogen".
 
Es wurde sich einigermaszen in Code-base [die vom Linux-Kernel und die von Peak Systems] eingearbeitet bzw. die Funktionsweise vom PCI-Adapter [PCAN] verstanden [es werden bspw. zwei Addressraeume fuer Zugriff auf dem Multiplexer sowie SJA1000 Controller allokiert bzw. {cfg,reg}_base usw. usf. ...].

FreeBSD integriert stabile KPI, da die urspruengliche Implementierung, aufgrund nicht wirklich stabiler KPI [oder sind da welche, mal abgesehen fuer netdev(9), Char-devices oder DMA beim Linux Kernel???], definitiv nicht wirklich portierbar ist [aber in Kombination mit dem Datenblatt sehr hilfreich fuer das Versaendnis ist], was [hier] positiv zu bewerten ist, da es einem zu einer anderen Implementierung "zwingt".
  1. Den Device-driver fuer den SJA1000 basierte Adapter werde ich in modularisiert bzw. in mindest. zwei Teilschichten [bspw. newbus(9) Peak-PCI-device(9)-node mit generischer SJA1000-device(9)-node] strukturiert implementieren, was Skalierbakeit bedingt [bspw. Glue-code mit iic(4)-bus, etc. ..].
  2. Wie schon bereits erwaehnt, sind einige Fehlerkorrekturen in Protocol-layer [High-level Interface] notwendig, die noch umgesetzt werden.
 
Dank dem Sessel mit benachtbarter Steckdose sowie der Atmosphare beim "Spaeti" waehrend des 35C3 laesst sich [langsam] bei der Implementierung des Geraetetreibers des Phillips SJA1000 Controllers eine Struktur erkennen, die es ermoeglicht die Software wieder als TDD zu entwickeln.

Der Geraetetreiber wird in zwei Schichten unterteilt:
  1. Frontend bzw. sja(4), welches via ifnet(9) ein Mapping von Interface-layer mit Protocol-layer des BSD Kernels implementiert sowie ein kobj(9) mit driver(9) Interface implementiert [oder soll, da noch nicht Fertig].
  2. Backend bzw. peak_pci(4) als Kernel Object, was ein Proxy-pattern fuer Zugriff auf dem pci(4) Bus implementiert.

Derzeit verwende ich _noch_ FreeBSD 11.3 als Basis.

Erreicht die Software dann irgendwann ein "benutzbares" [sowie "fehlerfreies"] Stadium [was noch etwas dauern wird, da ich leider kein "IT-Professionell mit "Projekt- / Berufserfahrung" bin und dementsprechend "entwickele"], dann wird FreeBSD 12 als Basis verwendet. Da sind noch einige Sachen, die mir persoenlich nicht gefallen, weil das alles noch irgendwie "written from scratch" ist, aber langsam habe ich die Implementierung [wohl eher Implementierungen] von CAN Feldbus des Linux Kernels "durchschaut".

Das derzeitig erreichte Statdium von Implementierung ist quasi als eine Art "Zwischenbericht" zu verstehen.
 
Worueber ich mich jetzt schwarz aergere, dasz ich auf dem 35C3 mich nicht traute Personen anzusprechen, die sich mit CAN auch beschaeftigen, und den BSD Tisch zu suchen. :rolleyes:
 
Kommt drauf an, sobald echte Hardware im Spiel ist und es sich nicht um ein Pseudo-Device handelt, ist die Antwort fast immer "ja". Du musst die Hardware in einem definierten Zustand hinterlassen, sodass der oder ein anderer Treiber sie wieder aufgreifen kann, ohne dass es einen Host Reset gab. Weil Nutzer das Kernelmodul eventuell entladen und später laden wollen, vor allem aber da sich viele moderne UEFIs einen vollständigen Host Reset sparen. Das System muss ja ein paar Millisekunden schneller starten... Auch musst du im Hinterkopf gehalten, dass auf vieler moderner Hardware komplexe Firmware läuft, die sich auch schon mal aufhängen kann. Erkennt der Treiber das, ist es meistens hilfreich, wenn er die Karte resetten und damit wieder in einen definierten Zustand bringen kann.
 
Ist es ein gangbarer Weg eine zusaetzliche taskqueue(9) fuer Post Interrupt Handling waehrend eines Interruptes zu integrieren oder ist das "Schwachsinn"?
Unter FreeBSD kann ich das nicht beantworten. Unter Linux weis ich, das etliche IRQs ihre Aufgaben in Queues packen und dann von einem Kernel Thread oder tasklets erledigen lassen. Ich habe das aus zwei Büchern: "Linux Treiber entwickeln von Jürgen Quaide" und "Linux Device Driver Development von John Madieu".

Im Buch "FreeBSD Device Drivers von Joseph Kong" steht das auch FreeBSD Task Queues hat. Leider weis ich auf die schnelle nicht, ob das auch aus IRQ Handlern geht. Ich vermute das es gehen sollte (tm).
 
Ich guckte mir seit ein paar Tagen die PCI Bus Specification Rev. 2.2 sowie einige andere Datenblaetter [PITA, PLX, ...] bzw. gucke die immer noch an.

Es wurde systematisch der Quellcode [von pci(4) bis nexus(4)] sowie Baumstruktur
des Newbus Systems untersucht und kam zur Erkenntnis, das die Taskqueue ginge, wenn IntrN "gesendet" wurde und Irq-handling von Device temporaer deaktiviert werde, wobei ich mir da noch nicht ganz sicher bin. Spannendes Thema.

Im Buch "FreeBSD Device Drivers von Joseph Kong" steht das auch FreeBSD Task Queues hat. Leider weis ich auf die schnelle nicht, ob das auch aus IRQ Handlern geht. Ich vermute das es gehen sollte (tm).

Das ist bspw. beim Bosch [CD]_CAN Controller moeglich, wo nach deaktivierung von Interrupts das anscheinend eine Taskqueue mit Callback triggert.
 
Ich bin bald oder demnaechst soweit reale bzw. physische Hardware zu testen [juhu], aber ueberarbeite die Code-base im Hinblick auf die Application Notes zum SJA1000 Controller.

@schorsch_76 Ich habe eine Frage zum Interrupt Handling, des SJA1000 Controllers.

In der Code-base vom orginaeren Geraetetreiber der Fa. Peak Systems werden maximal 6 Interrupts vom handler verarbeitet und bei der Code-Base vom Linux Kernel 20.

Bei jedem RX Interrupt wird jeweils ein CAN Frame aus dem FIFO Buffer gelesen [was da geschieht habe ich schon verstanden].

Wie kommt der Wert von der SJA_MAX_IRQ Konstante zustande? In den Application-Notes konnte ich dazu nichts entdecken.

Ich uebernahm den Betrag vom Geratetreiber der Fa. Peak Systems [siehe Zeile #783, pcan_sja1000.c], da anscheinend maximal 6 Interrupts mit maximal 8 Nachrichten [CAN Telegramme, etc.] je Interrupt von dem Device verarbeitet werden..

Parallel fing ich an mich schon etwas mit dem Geraetetreiber des C-CAN Controller der Fa. Bosch und etwas [wegen Autodidaktik] mit dem I2C-Bus [damit ist es auch moeglich CAN Frames zu senden] zu beschaeftigen.
 
Zurück
Oben