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
