CAN bus and Linux kernel drivers

SocketCAN vs. Can4Linux

Is not the best idea in my opinion to make CAN a networking subsystem. CAN bus is tightly bound to hardware it is using, and above all, this bus concept is very strong real-time oriented. Too much overhead is deadly. I observed serious malfunction on D_CAN driver in kernel 3.2.42, where busload of > 30% lead to total failure of the driver. I  had to create a workaround via MCP2515 driver to be able to deliver my product. C_CAN driver, having merged D_CAN functionality in 3.8, appears to be more stable, at least on BeagleBoneBlack.  I’ts drawback is lacking Device Tree support for CAN on BBB – manual intervention into DT is and recompiling is neccesary (for now).

The main problem was the lacking ability to set hardware filter in D_CAN/D_CAN driver. Stock MCP2515 was not any better, but heavy ISR load did not cause a crash – only a rising overrun statistics and frame loss, not dramatic in this appliance.

Alternative to official kernel SocketCAN subsystem is Can4Linux. It seems to have the ability to set hardware filter, at least in case of MCP2515. But ist’s main strength is the old-style chardev interface. The problem is, being not a mainstream project it lacks supporters.

Found something very interesting: http://ortcan.sourceforge.net/lincan/ . C_CAN implementation is included and needs to be adjusted to D_CAN structure. Filtering and chardev structure possible!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s