Re: [RFC][PATCH 0/2] LIN support for Linux

[Ryan Edwards]

Hello Pavel,

On Mon, Nov 28, 2022 at 12:52 PM Pavel Pisa <pisa@xxxxxxxxxxxxxxxx> wrote:
>
> Hello Ryan,
>
> On Monday 28 of November 2022 18:02:04 Ryan Edwards wrote:
> > On Mon, Nov 28, 2022 at 10:09 AM Pavel Pisa <pisa@xxxxxxxxxxxxxxxx> wrote:
> > Marc gave me a heads on on this discussion and I have some insight.
> >
> > I've spent quite a bit of time trying to craft a solution for the LIN
> > problem.  Even with a TTY solution the best I was able to achieve was
> > 40ms turnaround between the header and response which exceeded the
> > timeout of the master.
>
> This is indication of some serious problem. We have been able to
> achieve right timing even from userspace on PC 10 years ago
> when RT task priorities are used and mlock all even on standard kernel...
> Yes under load that could be a problem but on RT kernel and in kernel
> slLIN driver it was reliable even on relatively slow MPC5200.
>
> See FIGURE 3: Master: MPC5200 with slLIN; Slave: MPC5200 with slLIN
> of our comprehensive RTLWS 20212 UART-based LIN-bus Support for Linux
> with SocketCAN Interface article. For the complete protocol designed
> on basis of Oliver's proposal and then our finalization see complete
> report for VolkWagen. The timing is shown there as well
> Figure 5.2: Master: MPC5200 with sllin; Slave: MPC5200 with sllin
>
> https://github.com/lin-bus/linux-lin/wiki
>
> The problem with typical UARTs is then when they have enabled FIFO
> then drivers select trigger level higher than one and sometimes
> even minimal level is 1/4 of Rx FIFO depth. Then when trigger
> level is not reached the Rx interrupt waits for eventual
> more characters to come for (typically) 3 character times.
> So this is a problem. Because of 1/4 FIFO minimal threshold
> for 16C450+ UARTs, it is only solution to achieve right slave/response
> function to switch off the FIFO, there some internal API for that
> but not exposed o drivers. For 16V450, there is option
>
>   echo 1 >/sys/class/tty/ttyS0/rx_trig_bytes
>
> See https://github.com/lin-bus/linux-lin/issues/13

This test was done 2-3 years ago on a RaspberryPi.  I was testing as a
slave and had a hard time responding to the master any faster than
40ms.  I assume based on the work that you've done that I must have
not been accessing the TTY correctly.  Wish I would have found the
work already done on linux-lin.  Would have saved me some time and
headaches.

> > The README contains the HOWTO on usage of the driver.  Right now it's
> > a hack but could be better designed using message flags or a seperate
> > CAN channel.
> >
> > In my design the device contains a slave response table which is
> > configured via CAN frames via socketcan.  Currently up to 10 master
> > frames can be responded to.
>
> I think that even on embedded HW it is not problem to keep
> data for all 64 LIN IDs. So I would not complicate thing with some mapping
> etc. We have reused already present BCM (SocketCAN Broadcast Manager)
> to periodically send LIN headers.
>
> > It also allows the LIN node to be put
> > into monitor mode and gate those messages to the host via a CAN
> > message.
> >
> > https://github.com/ryedwards/budgetcan_fw
>
> Great, version connected over USB with local response table
> is more reliable with timing than software solution on big(err)
> complex system like Linux kernel is. So if the well defined
> open protocol is designed or some CAN USB devices one is reused
> for LIN than it is advantage.
>
> I would be happy if the project moves forward. The critical is
> some settlement on unified API. Please, compare and map functionality
> between our solution and your proposal and we can discuss what
> worth to keep or change. slLIN solution seems to be used in more
> project not only that two for Volkswagen and Digiteq Automotive,
> I have directly participated.
>

I think that what I have built is a high level embedded solution.  The
fundamental code is the same as it was developed from the state
diagram in the LIN specification.

I understand now that this project is to build on and implement the
work already done on slLIN.  I'll review the slLIN driver and see if
there is any input I can provide based on the work I've done in my
code.  I'd be very interested if the driver could be implemented in a
way that easily allows for dynamic slave repsonses.

Thanks,

--Ryan