On 14.01.2022 14:19:29, Maik Allgöwer wrote: > On 22-01-05 08:36, Oliver Hartkopp wrote: > > > > In fact the discussion hits a valid point. On the one side you might think > > about a time slotted receive task that might only be able to process a frame > > inside this slot. At least in the 'very early' days of CAN transport > > protocols I've heard about such weird implementations. > > > > On the other side (as we can see from the jitter in Maiks's original > > question) we face different requirements in todays implementations. Here an > > *average* result makes sense. But this is no implementation requirement but > > a testing requirement to relax the STmin timing checks then. > > I did some more testing and the issue seems not to be related to the isotp driver. > > The system we are using is an i.MX-based one and we have three CANs. > Two of those are flexcan, the third is a mcp2518fd (mcp251xfd). > > I can not reproduce the timing issue on the flexcans, only on the MCP. The flexcan uses a single TX buffer, while the mcp251xfd uses 8 for classical CAN and 4 for CAN-FD. 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:
signature.asc
Description: PGP signature
