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: ... > > > 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/ > > 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 was in userspace and I assume that a > kernel solution would better be able to meet the timing but this > solution would only work for devices with embedded UART. Yes, and on fully preemptive it is not problem. We run control loops in userpace at 5 kHz on Xilinx Zynq systems and used up to 30 kHz on PC for mainboard without MSI issues. So this seems that problems are in programing area. We have achieved correct slLIN functionality on more embedded systems, AM335x, MPC5200 etc. But it required to check UART driver and found how to set Rx trigger level to 1 or disable FIFO. Often by nasty parch. But most hardware could provide knob to tune required parameters. Some RFC for the proposed API there https://marc.info/?l=linux-serial&m=164259988122122&w=2 int (*rx_trigger)(struct uart_port *, int mode, int *rx_trigger_bytes, int *rx_trigger_iddle_time) I think that all/the most of the UART HW I have seen can adjust what necessary, in the worst case by switching FIFO off in UART_RX_TRIGGER_MODE_CHECK_ROUND_DOWN mode. > I did create a solution that uses the gs_usb driver using "pseduo" CAN > frames that currently supports slave and monitor mode. I had no use > cases for master mode up to this point so it has not yet been > implemented. The framework is there if it needs to be added. The set of frames has been defined in slLIN 10 years ago and there is even defined control for LIN 1.0 and 2.0 check sum selection for individual IDs. I do not insist that our design is the best mapping but try to compare it to yours and describe advantages that the best decision can be made for futire. > 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. Best wishes, Pavel Pisa phone: +420 603531357 e-mail: pisa@xxxxxxxxxxxxxxxx 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
