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 reason to put any hacks like Sleep(1) into my code, because timeout in my case is CanMax or CanEnhMax and the operation is supposed to block until data is received.
In fact, all the CPU time is taken up by the api call going into your library!
I quote from the J2534 API:
Timeout interval(in milliseconds) to wait for read completion. A value of zero instructs the API/DLL to
read buffered receive messages and return immediately. A nonzero timeout value instructs the API/DLL
to return after the timeout interval has expired. The API/DLL will not wait the entire timeout
interval if an error occurs or the specified number of messages have been read.
I am really disappointed by your response, blaming it on user code. Make a simple benchmark and you will see the problem.
I did not check if your API actually breaks the spec by returning earlier with 0 messages (thus causing much more calls than normally), but it either breaks the spec by returning early instead of blocking or the processing inside is very inefficient.
I do not have the source code for your DLL so I can not see with a profiler where the problem is. It is your job to do.
A 3rd party 15765-4 implementation with your device does not have this high CPU usage problem. Maybe that should ring some alarm bells.