I use PCAN-USB box (IPEH-002022) and recently updated the driver from an older version to actual version.
Communication is realized by SocketCAN and libsocketcan.
Since driver update, starting and stopping the interface using can_do_start and can_do_stop needs significantly more time than before.
I would like to understand root cause and consequences for the difference.
Has driver initialization / configuration an effect to this behavior?
In order to better help you, can you please give us more info about the old and the new "versions" and specifically, which driver you use. Are you talking about the mainline driver (peak_usb) or the peak-linux-driver (aka pcan) driver?
Moreover, can you also give us the output of "uname -a" please?
old driver was the mainline driver drivers/net/can/usb/peak_usb/ Version 4.1.15
new driver is peak-linux-driver 8.10.0
kernel version (uname -a) is Linux 4.1.15-rt17 #1 SMP PREEMPT RT 2016-11-01 armv7l GNU/Linux
we noticed differences for can_do_start / can_do_stop (same as set_link("can0", "IF_UP", NULL) / set_link("can0", "IF_DOWN", NULL)
we also noticed differences concerning error notifications that are provided by reading recvmsg().
Since drivers aren't the same then it's difficult to compare both of them.
First, try to download latest version 8.10.2 of the peak-linux-driver from the PEAK-System website to compare.
Then, you'll be able to request by email to email@example.com the patch than allows to get the CAN errors from this version.
many thanks for your feedback.
We tested peak-linux-driver version 8.10.2 and found the same impacts.
We understand thate there are too much differences to compare with the mainline driver.
Our problem is that there is another CAN device that continues sending messages while the peak box has been switched off and on again there will be errors on the CAN bus. We can see form errors and retries in PCAN-View when active in listening mode.
These errors will happen throughout a perid of about 130 milliseconds when messages will be sent from the other node throughout this period.
When CAN is compietely disabled, we don*t have these errors (only retries).
When switching off/on using the mainline driver there is only a very small window during which ariving CAN messages can cause an error.
We found some delays in the peak linux driver that indicate that switching off and on again will take some time.
Is there a possiblity to improve the behaviour of peak linux driver for that use case (prevent errors / speedup switching on/off)?
The big difference between both drivers stands in how and when the controllers are configured.
The peak-linux-driver does exist for age and proposes an interface that allows user to simply write:
Code: Select all
$ echo "m s 0x123 0 1 2 3 4 5 6 7" > /dev/pcan32
You won't be ale to to do that with any mainline driver without configuring the device first.
On the other hand, that choice means that if user wants to operate with a different baudrate than the default one, then the driver will configure TWICE the controller:
- open() => configure with default baudrate + put the controller UP.
- init() => put the controller DOWN + configure with baudrate + put the controller UP.
- close() => put the controller DOWN