Linux CAN development

Linux CAN development – Setup

Below are exact steps instructions I’ve used on i386, and armhf( Debian in both cases ), to get the socketCAN canutils working – In preparation of socketCAN development on Debian Linux. These steps *should* work on any Linux ( or UNIX ) that has access to the tools shown below. However, since package names, and package managers vary from one distro to another. Adjustments would have to be made – With this in mind.

Installing the prerequisites
Optional: Create, and move into newly created directory
Clone the canutils repo
Prepare, configure, and install canutils

At this point, we’ve got everything built, and installed so we can use the various socketCAN utilities. However there are two related but different directions in which we can go from here – Related to CAN interfaces. First, and most useful when using a physical CAN interface, is the canX interface. This requires a system that has some sort of supported hardware – Such as the Beaglebone black, and Logic Supply Serial / CAN cape. For this specific case, both the Beaglebone black, and cape are required. As the AM335X processor does have 2 CAN peripherals, but also requires a CAN transceiver, and proper channel termination – In order to function properly. Also, unless you have an external CAN network to connect / communicate to / with. Using the physical interface will be perhaps less useful.

The second option is using a virtual CAN interface( vcanX ). Which is most useful on an x86 / x86-64 platform, while using a previously created candump log file played back through canplayer. Perhaps this is not readily obvious as to how this is useful. But imagine working with a limited resource embedded Linux system, such as the previously mentioned Beaglebone black. Now imagine continuously compiling code for this system, on flash media, with a slower processor, and less RAM – When compared to something like say: core i7 quad( 8 threads via hyperthreading ) @3Ghz+, and 16G RAM. For small, simple applications, this is largely a moot point – Except for the flash media aspect. Trust me, it does make a difference. However do keep in mind that profiling code using socketCAN, on such an x86 system will not be of much use. Despite the software compiling faster on the x86 platform. The actual binary will use much less CPU on the target – In the case of the Beaglebone black.

So, the good thing about knowing of the two different kinds of CAN interfaces used with socketCAN. Is that they can be used in a way to make development faster, and easier. By initially writing code on an x86 platform. Be it a physical, or virtual system. Get the code exactly how you like it. Then transfer that code over the the embedded platform. On which it should compile / function exactly how it it did on the x86 platform. Useful ? I’ll let you be the judge for yourselves, But I found it extremely useful.

Setting up a physical interface

load the modules needed
Interface setup, and bring interface up
Check to make sure interface is infact up

Setting up a virtual interface

load the modules needed, interface setup, and bring the interface up
Check to make sure interface is infact up

Useful ways to use these two types of interfaces

Use netcat to listen for incoming connections, and pipe the data coming from that connection into a candump log file. Assume this machines IP address is: 192.168.254.163 on a local network.

In the above example, these two separate commands are issued on two seperate systems. The first system is an x86 system of some sort, and is the x86 development counterpart to an embedded Linux system. Running the first command will listen on port 5000, and pipe any data received to the file demonstrated above. /home/william/candump-may-14-2015.log. The second command is issued on the embedded Linux system counterpart. This command takes data from a physical CAN interface, which *should* be connected to a live CANBUS network. Then pipes that data over the network to the listening x86 CAN counterpart. Via netcat.

How is this useful ? Well the embedded system in my case is a Beaglebone black. Without setting up an external USB connected hard drive, or NFS file system. The Beaglebone black only has flash media as disk ( storage space ) – Typically. So instead of using flash media on the Beaglebone black, to store a log file, we simply use on system RAM to buffer the CANBUS directly to a network connected system. This log file can then be used on the x86 system, with the canutils “canplayer” utility. To simulate CANBUS traffic on the virtual interface. In order to do this . . .

1st terminal
2nd terminal
candump output

So, as demonstrated you can run these command in a separate terminal. Also, you can send the canplayer “process” to the background using & as so: william@debian-can:~$ canplayer vcan0=can0 -I candump-may-14-2015.log -l i & – In order to run both commands from the same terminal. Each way has it’s attractions. The option -l i will playback the log file in an infinite loop. Feel free to run the command canplayer –help for more information.

Hopefully the above information is enough to get one started in CAN development using socketCAN. At least as far as initial setup goes. Later I hope to write an article demonstrating the basics of writing code in C. For those who are familiar with Linux TCP, and / or UDP sockets. This will look very familiar. For those who do not have Linux socket API experience. Fret not, as I did not either, but found it mostly very easy to implement. Despite having absolutely zero experience with CANBUS at all. Hardware, or software wise.

Happy beagling !

Linux CAN development