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. Nonetheless, the point regarding the average st is really interesting, thanks Patrick! Regards, Maik
