Page 2 of 2

Re: PCANBasic.dll performance

Posted: Mon 18. Nov 2019, 12:18
by PEAK-Support
you wrote:
During transmission another thread is constantly reading data using CAN_read(), another one ditto for the 2nd channel.
what we are talking about? - call read every 1000ms, 100ms, 10ms or some µs ?!?
In the documenation you find some hint that you should read ALWAYS until you get the CAN_ERR_QRCVEMPTY (receive queue of the DRIVER is empty)
Calling for every CAN-Frame a single CAN Read is not correct - change it and you will see that it works (thousends of other applications work like that and work perfectly since many years..)

Re: PCANBasic.dll performance

Posted: Mon 18. Nov 2019, 21:17
by DF1AS
We cannot use interrupts or call-backs, so it's good practice to spend threads for active polling (at the cost of some CPU load). It works perfectly for the PCAN-light version (no noticeable side effects as expected), so we stay with and do not switch to PCAN-basic. PCAN-basic also works that way but slows down. Thank you for helping us.
Kay

Re: PCANBasic.dll performance

Posted: Tue 19. Nov 2019, 08:27
by PEAK-Support
no one say that you need to use interrupt or callbacks (which is definitally the best way) you should simply read ALL CAN MSGs in the queue until it is empty - as we wrote - do not read only single CAN Frames. The DLL implementation is not much changed in the past - beliveie me the PCAN-Light and the PCAN-Basic use both the same driver implementation. Most changes are made inside the driver.
You also did not answer any in of how often you "poll" the queue - as we wrote - not to much (5-10ms) but then read all entries...thousend of application work well .. so why should only your´s doesn´t ?