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 ...
Search found 10 matches
- Mon 23. Aug 2021, 14:49
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
- Mon 23. Aug 2021, 11:13
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
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 ...
- Sun 22. Aug 2021, 21:27
- Forum: PCAN-PassThru API
- Topic: Multiple applications using same PCAN USB device
- Replies: 3
- Views: 5203
Re: Multiple applications using same PCAN USB device
This is a general J2534 issue because J2534 DLL's are not meant to be accessed by more than one process. The API spec says so.
The only workaround is to have one process as the gateway and then have other processes communicate with this process to send the packets.
Most likely you will have to ...
The only workaround is to have one process as the gateway and then have other processes communicate with this process to send the packets.
Most likely you will have to ...
- Sat 21. Aug 2021, 23:03
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
The extended mode seems to work now, but when using ISO-TP with high bus load the CPU usage is very high, it maxes 1.5 cores on a high end Ryzen processor.
If I switch to raw can mode and use my own ISO15765 stack then I have less than 2% CPU usage.
In my ISO15765 stack I am using a multimedia ...
If I switch to raw can mode and use my own ISO15765 stack then I have less than 2% CPU usage.
In my ISO15765 stack I am using a multimedia ...
- Thu 29. Apr 2021, 13:08
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
1 month passed.
News?
News?
- Tue 30. Mar 2021, 14:30
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
Hello,
Not really have had the time to look into this further.
Is there any ETA on the update?
I downloaded the latest version and I see that the files inside the archive are still last modified 10.02.2021.
Not really have had the time to look into this further.
Is there any ETA on the update?
I downloaded the latest version and I see that the files inside the archive are still last modified 10.02.2021.
- Tue 16. Mar 2021, 17:33
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
Re: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
Hello,
No, the problem is not my application. I wrote it. The application is used by hundreds of clients with more than 20 different J2534 interfaces.
Something happens to the PCAN J2534 DLL where even if I clear it and reset everything, I do not get any data back anymore from the J2534 DLL until I ...
No, the problem is not my application. I wrote it. The application is used by hundreds of clients with more than 20 different J2534 interfaces.
Something happens to the PCAN J2534 DLL where even if I clear it and reset everything, I do not get any data back anymore from the J2534 DLL until I ...
- Tue 16. Mar 2021, 15:11
- Forum: PCAN-PassThru API
- Topic: BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
- Replies: 14
- Views: 16759
BUG: J2534 API does not set ISO15765_ADDR_TYPE on reception
When using ISO15765 extended addressing and the channel configured for it, the PeaK library does not set the 0x80 flag on reception.
J2534 call trace via shim about how the channel is set up and the exchange:
0.000s ++ PTOpen(*NULL*, 0x070AE760)
returning DeviceID: 81
3.067s 0:STATUS_NOERROR
3 ...
J2534 call trace via shim about how the channel is set up and the exchange:
0.000s ++ PTOpen(*NULL*, 0x070AE760)
returning DeviceID: 81
3.067s 0:STATUS_NOERROR
3 ...
- Sun 24. Jan 2021, 10:11
- Forum: PCAN-PassThru API
- Topic: Very high CPU usage when continously calling GetMessages with a lot of data.
- Replies: 5
- Views: 6126
Re: Very high CPU usage when continously calling GetMessages with a lot of data.
You assume wrong.
I use exactly the same code with all my hardware . User can freely select J2534 device in dropdown before beginning communication.
I have 4 J2534 devices and only your device exhibits the problem and only when there is a lot of data received.
Is that more clear?
There is zero ...
I use exactly the same code with all my hardware . User can freely select J2534 device in dropdown before beginning communication.
I have 4 J2534 devices and only your device exhibits the problem and only when there is a lot of data received.
Is that more clear?
There is zero ...
- Mon 18. Jan 2021, 00:28
- Forum: PCAN-PassThru API
- Topic: Very high CPU usage when continously calling GetMessages with a lot of data.
- Replies: 5
- Views: 6126
Very high CPU usage when continously calling GetMessages with a lot of data.
Hello,
My code is basically:
while (true) {
GetMessageResults results = Channel.GetMessages(1, timeout);
// Do stuff with result here...
}
When processing many messages the CPU usage is very high using your DLL. It hits 100% on one core.
I am using ISO15765-4.
If I use any of my other devices ...
My code is basically:
while (true) {
GetMessageResults results = Channel.GetMessages(1, timeout);
// Do stuff with result here...
}
When processing many messages the CPU usage is very high using your DLL. It hits 100% on one core.
I am using ISO15765-4.
If I use any of my other devices ...