Re: can-isotp: TX stmin violations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Patrick,

On 04.01.22 13:06, Patrick Menschel wrote:
Am 03.01.22 um 18:40 schrieb Oliver Hartkopp:
In this example CF#2 is delayed by .5 ms on the wire while CF#3 is
sent .5 ms too early
when I look at the delta between CF#2 and CF#3 .

To me it seems that, while the messages are put into some tx-queue at the
correct time, they are not actually put on the wire at that exact time
leading to CF#3
being put on the wire too early.

Yes. The CAN frames are sent with a 'minimum' gap which is defined with
STmin, see isotp_tx_timer_handler().

Generally the handling and the sending of the frame is processed - and
*then* the offset gap of the current time is added. In your case it
should always be *slightly more* than 2ms, which is fine from the STmin
specification intention.

Hi,

actually spec says *average* gap time should not fall below STMIN.

I did not see this average gap recommendation so far.

Only:

9.6.5.4
SeparationTime minimum (STmin) parameter definition

The ST min parameter shall be encoded in byte #3 of the FC N_PCI.

This time is specified by the receiving entity. The STmin parameter value specifies the minimum time gap allowed between the transmissions of two ConsecutiveFrame network protocol data units (CFs).

The term "average" can not be found in the entire ISO15765-2-2016 specification ...


That .5 is actually not bad at all.
I have seen some autosar manufacturers stretching the spec up to the
point where you request stmin=5 and get st=10 by design.


Best regards,
Oliver



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux