Jump to content
Sign in to follow this  
yyrkoon

Setting up canutils on Linux

Recommended Posts

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.

 

For example: the package name 'git' should be 'git' on any platform, but package names like build-essential may be named different from platform to platform. In this case, your package manager should warn you, and google works wonders . . .I also use google to hunt down package names a lot. So please do not feel singled out :)

 

Installing the prerequisites:

william@arm:~$ sudo apt-get install git build-essential gcc make autoconf libtool
 Need to get 48.5 MB of archives.
 After this operation, 117 MB of additional disk space will be used.

Optional: Create, and move into newly created directory.

william@arm:~$ mkdir can-dev && cd can-dev

Clone the canutils repo:

william@arm:~/can-dev$ git clone https://github.com/linux-can/can-utils.git
 Cloning into 'can-utils'...
 remote: Counting objects: 1108, done.
 remote: Total 1108 (delta 0), reused 0 (delta 0), pack-reused 1108
 Receiving objects: 100% (1108/1108), 319.51 KiB | 148 KiB/s, done.
 Resolving deltas: 100% (726/726), done.
 Checking out files: 100% (43/43), done.

Prepare, configure, and install canutils:

william@arm:~/can-dev$ cd can-util
william@arm:~/can-dev/can-utils$ ./autogen.sh
 . . .
 --------
 Finished
 --------
william@arm:~/can-dev/can-utils$ ./configure
william@arm:~/can-dev/can-utils$ make
william@arm:~/can-dev/can-utils$ sudo make install

With all of the above done, there are a couple options as to how you can use the newly installed canutils. First option would require having a CAN cape physically attached to a beaglebone, or other suitable CAN capable board. - Which is then physically connected to working external CAN hardware. The second option requires no hardware in addition to computer / board used, but would require a candump log if one would like to simulate CANBus traffic - In order to get familiar with the socketCAN API. Or to develop CANBus software. The canutils utility cansend  could also probably be used to simulate sent frames as well, but you would need to know how to form a proper frames when sending to specific CAN hardware.

 

vcan example:

 

Load driver module:

william@arm:~/can-dev/can-utils$ sudo modprobe vcan

Initialize a vcan interface:

william@arm:~/can-dev/can-utils$ sudo ip link add vcan0 type vcan

Bring the initialized vcan0 interface up:

william@arm:~/can-dev/can-utils$ sudo ip link set vcan0 up

Check if vcan0 is actually up, and working:

william@arm:~/can-dev/can-utils$ sudo ifconfig vcan0
vcan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0   TX bytes:0 (0.0 

Run a previously created candump logfile in an endless loop:

william@arm:~$ canplayer vcan0=can1 -I candump-may-14-2015.log -l i

At this point you could run say $ candump vcan0 , and see the CANBus traffic being displayed on screen.

Share this post


Link to post
Share on other sites

Thanks, useful!

Are you using the can cape or parsing a log?

Both - Created a log file using the beaglebone + can cape - Did a lot of testing using the logfile on an i386 debian virtual machine. Now I've finally come full circle, and have had the code "running" on the BBB.

 

Problem is now. 3.8.x is unstable for this build - It does not like ethernet and CANBus going on at the same time. So can't use it. 4.1.x is fast fast, but they've got a bug related to OTG USB, and the PMIC . . . something about OTG sending pulses once in a while on the floating PMIC input line . . .bad mojo. *AND* to top it all off . . . the board + can cape draws too much power to be used when powered by USB . . . the TI linux-images will *NOT* work with nfsroot . . . and Im starting to get livid because I feel like I'm stuck back in the 90's when Linux was very shoddy . . .

 

All I've been wanting to do it start working on the code all day, but one thing after the other has been thwarting my progress. I really do not want to have to go back to a 3.14.x kernel because they're slower than the 4.1.x kernels . . . But I don't know. I need to take a break before I blow a gasket.

 

Was talking to wulf earlier about shorting VBat to ground in hopes that will stop the auto reboots. IN short 3 lines all floating. VUsb, VBat, and I think VBus. They're not all supposed to be floating at once, but they are.

Share this post


Link to post
Share on other sites

@@bluehash By the way, the only real reason I did not give a physical can example too was because I could not find my notes. It's a bit different, and you have to specify a bitrate to communicate with the external device in question. I've made new notes, so have that handy now.

 

Also Wulf had some USB-A female sockets. SO instead of grounding Vbat, we shorted VUsb to USB ground. On the socket, then connected a male USB-A to MINI-B cable to it, and then the beaglebone. He says that should work. We'll see . . .

Share this post


Link to post
Share on other sites

Yikes.. I'm running Ubuntu. Have to check the kernel version on my BBB. I started it yesterday after 6 months and realized the PGP key had expired. Took some time getting it up.

they both use the same kernel though.

Share this post


Link to post
Share on other sites

For setting up a physical can interface it's a bit different and a bit more complicated. First you need to know the bitrate the external CAN device needs to communicate at. trial and error might be in order, if you can not otherwise find this information out. But once set, and if you issue candump canx from the command line, candump should give an error that will give a clue that the bitrate is set incorrectly, Passed that the only semi complication is using 3 different modules compared to using a vcan interface. Then you may need to guess which interface the CANBus attaches to. This can vary from kernel to kernel and probably distro to distro as well.

 

example:

 

load the modules needed:

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw

Set the interface up, again may need trial and error for bitrate, and canx interface:

sudo ip link set can0 type can bitrate 250000 triple-sampling on
sudo ip link set can0 up

 Once this is done, you can "test" that the interface is up using sudo ifconfig can0. If the interface shows, you can then test the interface with candump. So, if it can not find can0, try can1 as the interface. I've read that you can find the device once connected in the /dev/ directory. But in my case it does not show. Nor does it show in /dev/net/

Share this post


Link to post
Share on other sites

For setting up a physical can interface it's a bit different and a bit more complicated. First you need to know the bitrate the external CAN device needs to communicate at. trial and error might be in order, if you can not otherwise find this information out. But once set, and if you issue candump canx from the command line, candump should give an error that will give a clue that the bitrate is set incorrectly, Passed that the only semi complication is using 3 different modules compared to using a vcan interface. Then you may need to guess which interface the CANBus attaches to. This can vary from kernel to kernel and probably distro to distro as well.

 

example:

 

load the modules needed:

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw

Set the interface up, again may need trial and error for bitrate, and canx interface:

sudo ip link set can0 type can bitrate 250000 triple-sampling on
sudo ip link set can0 up

 Once this is done, you can "test" that the interface is up using sudo ifconfig can0. If the interface shows, you can then test the interface with candump. So, if it can not find can0, try can1 as the interface. I've read that you can find the device once connected in the /dev/ directory. But in my case it does not show. Nor does it show in /dev/net/

 

Ah and right . . .

william@xanbustester:~$ dmesg |grep can
[    3.913948] mip6: mip6_init: can't add xfrm type(destopt)
[   10.933905] c_can_platform 481d0000.can: c_can_platform device registered (regs=fa1d0000, irq=182)
[   14.828712] can: controller area network core (rev 20120528 abi 9)
[   14.981932] can: raw protocol (rev 20120528)
[  137.779328] c_can_platform 481d0000.can can0: setting BTR=1c05 BRPE=0000

Once the modules are loaded, dmesg to the rescue !

Share this post


Link to post
Share on other sites

@@bluehash

 

Just curious. Why are you running Ubuntu on the BBB ? Do you have hdmi output to a monitor or something ? Ubuntu can often present technical hurdles to overcome in the context of the BBB, but it really depends on what you're doing I suppose.

 

By the way, I have an older laptop dedicated to Lubuntu 14.04 I think ( haven't run it in a while ), and for an armv7 cross compile system it works great with "out of the box" ( APT ) packages that *just work*. The desktop also looks nice, and it's very fast. Lubuntu by the way is just Ubuntu defaulted to LXDE instead of the standard window manager typically provided with stock Ubuntu.

Share this post


Link to post
Share on other sites

@@bluehash

 

Just curious. Why are you running Ubuntu on the BBB ? Do you have hdmi output to a monitor or something ? Ubuntu can often present technical hurdles to overcome in the context of the BBB, but it really depends on what you're doing I suppose.

 

 

No reason. It seems stable to me so far. I really don't do much with it. I just need ethernet and some sensors to hook up to. When I'm bored, I fire it up and play around.

Share this post


Link to post
Share on other sites

@@bluehash

 

Ah, gotcha. Yeah sorry late reply . . . act of god let the blue smoke out of an IC which just so happened to be on the PCB of our PoE switch. which is connected to our wireless router . . . going to post a pic soon. pretty amazing really.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×