Meaning of yarp::dev::CanErrors struct members

[PeterBowman]

Hello. I'm having a hard time understanding the meaning of the struct members in yarp::dev::CanErrors, hence I'm asking for clarification. From source code (CanBusInterface.h):

class YARP_dev_API yarp::dev::CanErrors
{
public:
    CanErrors() { /* ... */ }

    int txCanErrors;     //can device tx errors
    int rxCanErrors;     //can device rx errors
    bool busoff;         //bus off
    unsigned int rxCanFifoOvr;   // can device rx overflow
    unsigned int txCanFifoOvr;   // can device tx overflow
    unsigned int txBufferOvr;    // tx buffer overflow
    unsigned int rxBufferOvr;    // rx buffer overflow
};

What is the difference between the rxCanFifoOvr/txCanFifoOvr and txBufferOvr/rxBufferOvr pairs?

The only usage I found across robotology's codebase is PlxCan.cpp and CanBusMotionControl.cpp, both at robotology/icub-main.

[jgvictores]

As indicated at http://wiki.icub.org/wiki/PC104_Linux_Image_-_Support_for_version_prev_5.0#Device_Drivers, inside an iCub 104 image (e.g. http://www.icub.org/download/pc104-images/image1.8-oc.img.tar.bz2 which I downloaded, uncompressed, mounted, and chrooted to preserve the links) we can find /lib/modules/2.6.24-etchnhalf.1-686/iCubDrivers/plxCanApi/. There, in include/ we can find PexApi.h, which is modified from the PLX SDK version (https://www.broadcom.com/products/pcie-switches-bridges/software-dev-kit, because Broadcom acquired PLX Technologies) to #include "plxApiCanHelper.h", which is iCubDrivers-specific and declares:

typedef struct _PLXCAN_MSG
{
    long id;
    unsigned char len;
    unsigned char data[8];
    //    int32_t id;
    //    uint8_t len;
    //    uint8_t data[8];
} PLXCAN_MSG;

//typedef PLXCAN_MSG CMSG;

typedef struct _PLXCAN_ERRORS
{
    unsigned int canOvr;
    unsigned int errors;
    int busoff;
    unsigned int outputBuffOvr;
    unsigned int inputBuffOvr;
} PLXCAN_ERRORS;

Unfortunately, I have not been able to find the source code of lib/libPlxApi.a (e.g. even through http://svn.code.sf.net/p/robotcub/code/trunk/iCub/pc104/, mosty populated by binaries within .tars and .debs; however, haven't parsed all tags/ rather than trunk/). Note that grep does not find symbols such as outputBuffOvr within lib/libPlxApi.a, but that's probably expected from compilation.

On the hardware side and trying to make sense of this, "http://wiki.icub.org/wiki/CFW_card + schematics" confirm the "PCA82C250T (transceiver) + SJA1000/SJA1000_3 + PLX PCI 9030" to be the relevant components, which makes sense at kernel level (1, 2), and the SJA1000 datasheet may help understand its possibilities on error management.

[jgvictores]

What is the difference between the rxCanFifoOvr/txCanFifoOvr and txBufferOvr/rxBufferOvr pairs?

From the SJA1000 datasheet:

6.1.2 TRANSMIT BUFFER (TXB)
The transmit buffer is an interface between the CPU and
the Bit Stream Processor (BSP) that is able to store a
complete message for transmission over the CAN
network. The buffer is 13 bytes long, written to by the CPU
and read out by the BSP.

6.1.3 RECEIVE BUFFER (RXB, RXFIFO)
The receive buffer is an interface between the acceptance
filter and the CPU that stores the received and accepted
messages from the CAN-bus line. The Receive Buffer
(RXB) represents a CPU-accessible 13-byte window of the
Receive FIFO (RXFIFO), which has a total length of
64 bytes.
With the help of this FIFO the CPU is able to process one
message while other messages are being received.

Still, the source code of lib/libPlxApi.a would be very helpful. 😉

[pattacini]

This is quite a peculiar request. Is there anyone into CAN and our related code who's able to give an answer? Maybe @randaz81 ?

[lornat75]

It has been a long long time, but if a remember correctly the rxCanFifo/txCanFifo refer to the small buffers inside the device, whereas the txBuffer/rxBuffer are the ones between the CPU and the device.

The CanFifo buffers are managed by the device and overflow should not occur, whereas the txBuffer/rxBuffer are managed by the driver, overflow may occur if the CPU does not read messages quickly enough (rxBufferOvr) of it it write messages too quickly (txBufferOvr).

This should be how the Plx driver works. The CFW is more complicated but these error messages are mapped in a similar way.

[PeterBowman]

Thank you very much, @lornat75, that explains a lot. And thank you @jgvictores for your research! My question has been answered, this issue can be closed now.