significant changes to PCAN USB driver

This forum covers PCAN-Linux and Linux development issues concerning our products
Post Reply
pgschwendtner
Posts: 3
Joined: Fri 6. Nov 2020, 19:24

significant changes to PCAN USB driver

Post by pgschwendtner » Fri 6. Nov 2020, 19:49

Hello,

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?

best regards
PG

User avatar
S.Grosjean
Software Development
Software Development
Posts: 302
Joined: Wed 4. Jul 2012, 17:02

Re: significant changes to PCAN USB driver

Post by S.Grosjean » Mon 9. Nov 2020, 08:44

Hello,

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?

Regards,
— Stéphane

pgschwendtner
Posts: 3
Joined: Fri 6. Nov 2020, 19:24

Re: significant changes to PCAN USB driver

Post by pgschwendtner » Mon 9. Nov 2020, 12:14

Hello,

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().

regards
pg

User avatar
S.Grosjean
Software Development
Software Development
Posts: 302
Joined: Wed 4. Jul 2012, 17:02

Re: significant changes to PCAN USB driver

Post by S.Grosjean » Mon 9. Nov 2020, 14:27

Hi,

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 linux@peak-system.com the patch than allows to get the CAN errors from this version.

Regards,
— Stéphane

pgschwendtner
Posts: 3
Joined: Fri 6. Nov 2020, 19:24

Re: significant changes to PCAN USB driver

Post by pgschwendtner » Wed 11. Nov 2020, 18:34

Hi,

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)?

regards
pg

User avatar
S.Grosjean
Software Development
Software Development
Posts: 302
Joined: Wed 4. Jul 2012, 17:02

Re: significant changes to PCAN USB driver

Post by S.Grosjean » Thu 12. Nov 2020, 09:33

Hello,

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
to write a CAN frame with ID=0x123 and 8 data bytes on a 500 kbps CAN bus connected to /dev/pcan32 device. There is no need to configure the device if the default speed is correct.

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
Since delays are mandatory to wait for completion of these commands, this should explain why those delays are longer with the peak-linux-driver than with the mainline one.

Regards,
— Stéphane

Post Reply