BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception

[F.Vergnaud]

Hello,

There is no continuous loop, PCAN-ISO-TP also uses high resolution timestamps and wait handles to ensure the communication.
However the frequency is set below 1ms in order to process more quickly communications where Seperation Time is between 0xF1 and 0xF9 (100µs to 900µs).

Moreover by default PCAN-ISO-TP handles all CAN frames received by PCAN-Basic. If you need to improve speed, you can enable frame filtering parameter (PCANTP_PARAMETER_FILTER_CAN_ID) and use function CANTP_AddFiltering_2016 to filter the allowed CAN IDs.

[F.Vergnaud]

I was a bit quick to reply on the ISO-TP topic, sorry.
Since you're using PCAN-PassThu, could you mention which PassThru protocol's version you're using (04.04 or 05.00)?

[projix]

I was a bit quick to reply on the ISO-TP topic, sorry.

Yeah, I was wondering what was going on there, as your reply seemed nothing to do with what I said

Since you're using PCAN-PassThu, could you mention which PassThru protocol's version you're using (04.04 or 05.00)?

I am using 04.04 and I am transmitting pretty much as fast as my other node can receive. STmin is 0 and BS is also 0 (sent by other node in first FC message).
And there are 256 byte packets being transmitted.
But even if I break the packets up, one core of the CPU is completely consumed, this probably means the ISO15765-2 layer in the DLL is called in a tight or spinwait loop.

There is no way to wait less than 0.5ms in user code on Windows without spinning the CPU (and even for this you need a bunch of hacks). The default granularity is 15ms when you de-schedule the thread. So if you're using smaller wait times you're almost certainly just blocking the thread by spinning the CPU, which maxes a core.
This could also explain why my ISO15765-2 implementation uses over 20 times less CPU resources than yours. Because as I understand the PCAN hardware lacks the ability to do ISO15765-2 in hardware, so this is purely a software thing.

There is a small throughput penalty with a 0.5ms raster vs a tight loop depending on how the clock syncs up between your CPU and the target node. It can be between 2-10%.
But I think this is preferable to keeping a CPU core in a tight loop. At least in my field most people use these cables on laptops to communicate with vehicles, and the laptop battery is rapidly depleted if you keep a core maxed.

[F.Vergnaud]

A zero STmin and BS is indeed a condition where the API will do everything it can to send the data as quickly as possible:
- self-confirmation of CAN frames is disabled (which usually takes up to 300µs depending on the frame content),
- scheduling of the next frame transmission is set to as soon as possible.
As a result this is understandable that the CPU is heavily used.
Unfortunately in other customer's use-cases, the time performance is more critical than the CPU usage (for instance flashing an ECU with 4095 bytes ISOTP messages must be the fastest possible especially when it is done in a batch).

The priority behaviour of ISO-TP layer could be parametized, but since PassThru is a generic API we avoid to add vendor-specific parameter.
Do not hesitate to share your thoughts on that matter.

[projix]

I am using it for measuring, not flashing and most automotive control units tend to use STMin = 0 and BS = MAX.
So yes, in flashing case the flash job can be completed maybe 2% faster. At expence of huge CPU usage.
But outside of batch flashing this is not the case.

You can achieve very similar performance without killing the CPU, by:
1. On reception, asking the device always the full buffer with 0 timeout, and processiong all the CAN Frames that have arrived in a batch.
2. On transmission, as soon as FC is received looking at the current STmin and BS. If STmin is 0, then calling send with 0 timeout for all the frames up to BS, again in a batch.
3. Using NtQueryTimerResolution, NtSetTimerResolution to set the timer resolution to 500uS. Then using CreateWaitableTimer and more importantly SetWaitableTimer (the initial wait time can be specified in 100ns increments, but should be always ~100uS less than resolution, if you set it exactly you will have 500us jitter), to repeatedly signal a wait handle, and then trigger the SetWaitableTimer again.
4. In the message pump loop wait for the Timer. This lets the thread Yield and not cause huge CPU usage.

This way the only place where any efficiency is lost is during waiting to send or receive the FC. With huge blocksizes there is almost no penalty.

Some code:

Code: Select all

private static void TimerTrigger() {
    waitHandle.Set();
    if (isRunning) {
        FireOnce();
    }
}

private static void FireOnce() {
    SetWaitableTimer(handle, ref period, 0, TimerTrigger, IntPtr.Zero, false);
}