PCAN miniPCIe vs Lawicel CANUSB

[mccabehm]

I am using CANopen with Lawicel CANUSB with socketCAN/slcand on Yocto. I occasionally see an unexpected SDO abort. PCAN-View shows I am aborting an SDO initiate download that never made it to the bus, so of course there was no response and I timed out waiting for the response. This occurs when I am transmitting a PDO at nearly the same time. The Lawicel CANUSB documentation mentions a limited USB hardware FIFO and "it can only handle one or two command at a time, meaning before sending the next command to it, you must wait for an answer from the CANUSB unit (OK which is [CR] or Error which is [BELL])". I wonder if the TPDO is overwriting the SDO initiate download in the limited hardware FIFO. I doubt that Linux handling of PF_CAN is aware of the limited USB hardware FIFO.

Would PCAN-miniPCIe avoid this limitation? Has anyone else encountered this limitation with slcand and the Lawicel CANUSB?

[O.Hartkopp]

The Lawicel CANUSB documentation mentions a limited USB hardware FIFO and "it can only handle one or two command at a time, meaning before sending the next command to it, you must wait for an answer from the CANUSB unit (OK which is [CR] or Error which is [BELL])". I wonder if the TPDO is overwriting the SDO initiate download in the limited hardware FIFO. I doubt that Linux handling of PF_CAN is aware of the limited USB hardware FIFO.

I can confirm your doubts.
The slcan driver handles in input and output streams independent from each other.

In slcan_unesc() [CR] and [BELL] are skipped to check for the next ASCII CAN Frame:
http://lxr.free-electrons.com/source/dr ... v=4.5#L227
When no frame is found in slc_bump() it continues.

This is the standard behaviour you also have on slip.c for serial line IP as the handshaking is done on a higher level there. It would be hard to distinguish [CR] and [BELL] between incoming traffic and outgoing traffic.

So with slcan.c reception is fine but the outgoing traffic is send as fast as possible to the serial line.
I did not know that the Lawicel CANUSB would take serial input even if the FIFO is blocked.
So the flow control is not implemented by hardware but has to be managed by the application software (which can not distinguish the [CR]/[BELL] in the input stream).

Would PCAN-miniPCIe avoid this limitation?

Yes. You have a netdev tx queue which is drained only when the CAN Frame is sent on the bus successfully.

Has anyone else encountered this limitation with slcand and the Lawicel CANUSB?

I did not see this issue with a USB232 which was probably 'slow enough' to not run into this issue.
But from your description we can assume that high performance sending with Lawicel CANUSB is probably no good idea as the TX FIFO handling cannot be supported properly (by slcan.c / user application).

Regards,
Oliver

[mccabehm]

Further detail... I see 3 frames being sent to socketCAN in the CANopen library log.
1. The 1st and 3rd frames show on the PCAN-View trace. The 2nd frame does not. The 1st and 3rd frames' timestamps in PCAN-View are separated by 52.9 ms.
2. Again, 1st and 3rd frames show on the PCAN-View trace. The 2nd frame does not. The 1st and 3rd frames' timestamps in PCAN-Vieware separated by 6.3 ms.

CANbus speed is 125 k. I can take the same CANopen master, run it many times on Ubuntu with the Peak's PCAN-USB i/f and never see a single SDO abort.

[O.Hartkopp]

Further detail... I see 3 frames being sent to socketCAN in the CANopen library log.
1. The 1st and 3rd frames show on the PCAN-View trace. The 2nd frame does not. The 1st and 3rd frames' timestamps in PCAN-View are separated by 52.9 ms.
2. Again, 1st and 3rd frames show on the PCAN-View trace. The 2nd frame does not. The 1st and 3rd frames' timestamps in PCAN-Vieware separated by 6.3 ms.

This still smells like a single FIFO overrun.

If you want to confirm the timing issue, you might create a SocketCAN logfile, where the time separation between the frames can be defined by the timestamp value. When you replay this 'forged' logfile with the canplayer you can see which time sequence brakes the FIFO handling.

Code: Select all

(0.00100) slcan0 123#0000000000000000
(0.00200) slcan0 123#0000000000000000
(0.00300) slcan0 123#0000000000000000
(0.00400) slcan0 123#0000000000000000