supporting both PCAN-USB and PCAN-USB-Pro-FD

[bryancole]

I have a linux (kernel v4.18.10) app using a PCAN-USB / PCAN-USB_Pro_FD device. I've just upgrated the PCAN drivers to v8.4.0.

We're using the PCAN Basic (legacy) API. If I plug in a plain PCAN-USB everything works as normal. However, when I plug in a PCAN-USB-Pro-FD device, the application doesn't work. I see that the Pro-FD device now creates a different device file (/dev/pcanusbfd32, instead of the original /dev/pcanusb32 device created for the standard pcan-usb device).

Is there a way to get the Pro-FD device to register as a standard 2-port pcan-usb, so we get the old behaviour back? We don't use any of the FD features and I don't want to update to the new API (yet).

Thanks.
BC

PS. Compiling on kernel 4.18.10 was a pain but it did work by disabling all the other device types except usb.

[M.Maidhof]

Hi,

as a first step, please always use the latest available driver, when using such a new kernel. At the moment we have released peak-linux-driver-8.7 (see our support-Linux website for more details).

http://www.peak-system.com/fileadmin/me ... /index.htm

Please also use the latest PCANBasic API which you can download from our support website.

When using PCANBasic API, you don´t have to care for the device name. You just call:

Status = CAN_Initialize(PCAN_USBBUS1, PCAN_BAUD_500K, 0, 0, 0);

for the first PCAN-USB channel.

Please also have a look into the driver manual, to see how the device names are defined.

regards

Michael

[bryancole]

OK, I've updated to the latest v8.7.0. This builds all modules fine on my kernel.

Next up, I'm trying to get the 32-bit libraries to build on my 64-bit machine. My gcc supports 32-bit compilation and I have glibc-devel.i686 installed (this is a redhat / Fedora27 machine). What else do I need?

Thanks.

[bryancole]

To answer my second question: the Makefile in the PCAN-USB driver library subfolder has errors:
- line 78 should read "ifeq ($(RT),NO_RT)"
- the define block below needed the "-e" option added to the echo command. Note, this is apparently non-portable but without it the newlines in the define block are not handled correctly.

define LIBC32_NOK
$(shell echo -e "
#include <sys/cdefs.h>\n
int main() { return 0; }" | $(CC) $(GCC_32OPT) -o /dev/null -x c - 2>&1)
endef

Now I've got 32-bit libs, I can get back to debugging my original problem.

[S.Grosjean]

Hello,

Many thanks for your feedback, you're right: line 78 is wrong and will be fixed accordingly.

Regarding the "-e' option: yep, it is actually not portable. Can you tell us what is your Linux system please? We'll include a fix to this too.

Thank you for your help in improving the pcan driver,

[S.Grosjean]

Hi again,

Can you please change "lib/Makefile" by replacing your "echo -e" with "/bin/echo -e", to prevent your make utility from running the "echo" command version of its own $SHELL?

Thank you,

[bryancole]

OK, thanks for the feedback. The change to "/bin/echo -e" works here.

My system (distribution) is Fedora27. uname -a output: Linux pulsef27dev 4.18.19-100.fc27.x86_64 #1 SMP Wed Nov 14 22:04:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Now I'm back to testing my application, the problem I have is that the PCAN-USB-ProFD devices doesn't seem to work at all (tested on two devices so I don't think its a hardware failure). However, the basic PCAN-USB device (single port) works fine.

When I try to test the Pro-FD device using either the pcanfdtst or receivetest/transmitest example programs, these programs hang. The process become "unkillable" (even using kill -9 <PID> doesn't exit it). I guess this means the application is stuck in a sys-call can can't be interrupted. v. v. bad

I was hoping that if I changed my app to use the newer pcanfd API it would work but if the pcanfdtst program doesn't work, then its a more serious problem. I've got no idea what to try next. Please advise!

Thanks,
BC

[S.Grosjean]

Hi,

When the application hangs on the USB-Pro FD, can you please open a new terminal window, then type:

Code: Select all

$ dmesg

Thanks,

[S.Grosjean]

Hello,

Ok I think we get it!

Can you please try this:

Code: Select all

--- a/driver/src/pcan_fops_linux.c
+++ b/driver/src/pcan_fops_linux.c
@@ -1130,7 +1130,8 @@ static long pcan_compat_ioctl(struct file *filep, unsigned int cmd,
                break;

        default:
-               err = __pcan_ioctl(filep, cmd, argp);
+               pcan_put_dev_unlock(dev, 0);
+               return __pcan_ioctl(filep, cmd, argp);
        }

        return pcan_put_dev_unlock(dev, err);

Regards,

[bryancole]

Yes, your patch works! All good now.

What's the likely time-scale for a new release incorporating this fix? While I can continue with the patch in the immediate term, I'd like to use a formal release for our own release-build.

Thanks.