LIN (ISO 17987)

LIN (ISO 17987)

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

Hello CAN community,

has anyone experience with a LIN stack for Linux? Can you recommend one?

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: LIN (ISO 17987)

[Oliver Hartkopp]

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.