Hello Marc, On 22.06.21 10:25, Marc Kleine-Budde wrote:
Hello CAN community, has anyone experience with a LIN stack for Linux? Can you recommend one?
there was an off-list discussion in February where I would like to share the latest reply.
In https://github.com/ppisa/linux-lin there's a bunch of URLs which points to a LIN implementation and documentation based on SocketCAN with LIN netdevices.
Best, Oliver On 21.02.21 19:54, Pavel Pisa wrote: > Hello Christoph and Oliver, > > On Sunday 21 of February 2021 18:05:45 Christoph Fritz wrote: >> I would like to see a LIN implementation upstream in the Linux kernel, >> I'm eager to help. A friend of mine is working for a car company and may >> fund me a bit. >> >> So here I am asking for your opinion. What do you think about mainline >> LIN support? Do you consider sllin's approach ready for mainline >> (especially the CAN API and tty buffer requirement)? > > I am not sure if CAN API is a best approach but it worked, so it > is such integrated CAN to LIN gateway. I am not sure if it > should target drivers/net/can and considered rock stable API, > but I think that pushing it to staging would help when there > are users. > > My latest version is at > > https://github.com/ppisa/linux-lin > > I have separated line discipline for master and slave > mode to allows both types to be registered easily. > It would be great if official slattach can add parameter > to select discipline number, then we do not need to > provide separate utility. > >> At first I thought about using an integrated chip like SJA1124 and >> writing a small driver (UIO + userland for example). Oliver's point was >> that it could use the already existing CAN API into userland as sllin is >> doing. > > The SJA1124 is probably more robust but RT with SPI on Linux > would cause probably even longer latencies than slLIN. > I suggest to use RT preempt kernels. The main limitation > of slLIN on UART is than in slave mode it cannot adjust > bitrate according to the frame start synchronization. > The timely response for slave on slLIN requires sound UART > and RT preempt. I did not finish reading of SJA1124 doc > if it support slave cache. For master mode, it seems that > slLIN is good enough. Problem is FIFO Rc trigger level > control. There should be unified API for this option control > for all UARTs. If slLIN gets at least into staging then there > is argument to start this proposal. > >> A beta character device driver like PEAK has for its products is pretty >> sure nothing to get adopted upstream: >> https://forum.peak-system.com/viewforum.php?f=237 >> Still it's interesting and maybe an inspiration for the slave mode.
