Message-Id: <202211281549.47092.pisa@cmp.felk.cvut.cz>
Date:   Mon, 28 Nov 2022 15:49:47 +0100
From:   Pavel Pisa <pisa@....felk.cvut.cz>
To:     Christoph Fritz <christoph.fritz@...dev.de>
Cc:     Oliver Hartkopp <socketcan@...tkopp.net>,
        Richard Weinberger <richard@....at>,
        Andreas Lauser <andreas.lauser@...tion.io>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        "Marc Kleine-Budde" <mkl@...gutronix.de>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jonathan Corbet <corbet@....net>, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/2] LIN support for Linux

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@....felk.cvut.cz
    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

Powered by blists - more mailing lists