Hello Christoph and Oliver, On Monday 28 of November 2022 11:16:05 Christoph Fritz wrote: > > are you already aware of this LIN project that uses the Linux SocketCAN > > infrastructure and implements the LIN protocol based on a serial tty > > adaption (which the serial LIN protocol mainly is)? > > > > https://github.com/lin-bus > > Sure, that's why I initially added Pavel Pisa to the recipients of this > RFC patch series. When there is an internal kernel API for LIN, his > sllin (tty-line-discipline driver for LIN) could be adjusted and finally > go mainline. Some layer common for UART based and dedicated LIN hardware would be usesfull. The main think to decide is if the solution encoding LIN interface control into CAN messages is the right one and how the encoding should work. Actual mapping keeps LIN and CAN data 1:1 and puts control into identifier and flags. It has advantage that common SocketCAN infrastructure can be used. There is disadvantage that in the case of real CAN to LIN gateway connected to CAN bus almost whole identifiers range is occupied by gateway control. If the response table control and LIN identifier is part of the data field then I can imagine, that more real gateway devices can be be connected to the single CAN bus. But if there is not standard followed by all such gateways producers then it is not of much help. So probably actual mechanism is reasonable. > Adding LIN only as a tty-line-discipline does not fit all the currently > available hardware. Another argument against a tty-line-discipline only > approach as a LIN-API is, that there is no off the shelf standard > computer UART with LIN-break-detection (necessary to meet timing > constraints), so it always needs specially crafted hardware like USB > adapters or PCIe-cards. Break is not so big problem, slave side baudate automatic setup is and then control of Rx FIFO depth and if not possible then its switchinch off which needs generic UART level API longterm https://github.com/lin-bus/linux-lin/issues/13 > For the handful of specialized embedded UARTs with LIN-break-detection I > guess it could make more sense to go the RS485-kind-of-path and > integrate LIN support into the tty-driver while not using a > tty-line-discipline there at all. The state automata is required and its implementation in userspace complicates the design and would result in higher latencies (memory context switch etc.) but may be not so critical for 19200 baud or similar. Kernel with RT preempt support is quite capable and for master side there is time when driver does not lost Rx characters. > > IIRC the implementation of the master/slave timings was the biggest > > Currently sllin only supports master mode, I guess because of the tight > timing constraints. On the UART with FIFO control, there is no problem with response latency on moderately loaded fully preemptive kernel and slLIN supports both modes. I see as the main problem for actual integration of both modes to select acceptable names for standard defined entities "master node" and "slave task". May it be "coordinator", "initiator" and "responder" or "target".... Probably N_SLLIN and N_SLLIN_SLAVE are unacceptable today... > > challenge and your approach seems to offload this problem to your > > USB-attached hardware right? > > The hexLIN USB adapter processes slave mode answer table on its own, > just to meet timing constraints. For master mode, it is currently not > offloaded (but could be if really necessary). Yes, for USB the responses uploading to device is a must and API has to count with it. > The amount of offloading (if any at all) is totally up to the device and > its device-driver (the entity actually processing data). So sllin does > not do offloading but can only work in relaxed timing constrained > environments. > An UART with built in LIN-break-detection (there are a few) might be > able to fully meet timing constraints without offloading (as well as > e.g. a PCIe card). In theory request/response loop up to RT user space task but keeping in the kernel is better and less error prone to applications errors. > > Can I assume there will be a similar CAN-controlled programming interface > > to create real time master/slave protocol frames like in a usual CAN/LIN > > adapter (e.g. https://www.peak-system.com/PCAN-LIN.213.0.html) ?? > > I already did some tests letting hexLIN and PCAN talk to each other in a > real time manner. Please see my preliminary PDF docu at > https://hexdev.de/hexlin/ Best wishes, Pavel Pisa phone: +420 603531357 e-mail: pisa@xxxxxxxxxxxxxxxx Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
