CAN with JAVA

Technical Support
, , ,
1

Hello.

I need to use CAN-communication in my Java-application, running on VF61 (VF50) under yours standard Linux BSP.

The questions are:

Is yours latest BSP-image 2.7b4 ready-to-use for CAN-communication?
Or I should customize Linux-image (oe-core) via “bitbake”-building according this chapter: High performance, low power Embedded Computing Systems | Toradex Developer Center ?

What steps should I to do?

I have already made an app for the communication via Modbus (RS485) through Linux-port “ttyLP2”. I used for this purpose a free Java-library “j2mod”, which already contains native “jSerialComm” libraries for all kinds of OS/architecture.
Do you have similar CAN-library for Java and ARM-Linux?

2

  1. Current BSP releases have CAN as a module precompiled. You have two options: Use SPI and the on-board MCP2515 CAN controller or use the FlexCAN controller inside the Vybrid SoC. If you are using the Evaluation Board V3.2B you can use jumper wires to connect the internal CAN controller to the CAN TX/RX pins of the transceiver. From a software perspective both variants need an altered device tree as described in the [Vybrid section of the CAN article][1]. Once that is in place a CAN interface should appear when running ip link. You can then communicate on the CAN bus using the Linux SocketCAN API.

  2. We do not have a Java CAN library. When search for “SocketCAN Java” some libraries turn up which might work, but we did not test any of them.

[1]: High performance, low power Embedded Computing Systems | Toradex Developer Center)#kernel-318-and-later

3

You wrote:

From a software perspective both variants need an altered device tree as described in the Vybrid section of the CAN article.

Is it possible to alter device tree on the Linux BSP-image, that is already installed and running on VF61/VF50?

Because I did not find neither directory (-ies) /arch/arm/boot/dts/ nor file vf-colibri-eval-v3.dtsi in the folder-tree of installed Linux.

Or I should recompile Linux-kernel for this purpose? If yes - what is the procedure? Is it the same as described in OpenEmbedded (core) or in Build U-Boot and Linux Kernel from Source Code or something else? Or there is a way to edit the file like zImage–4.4-2.7.4-vf610-colibri-eval-v3-20171005022132.dtb, that is present in folder colibri-vf_bin of the Linux-image?

4

Yes you need to build the device tree on your build host. arch/arm/boot/dts/ is the location of device trees within the kernel source tree.

You do not have to build a complete OpenEmbedded image, just follow the steps in Build U-Boot and Linux Kernel from Source Code. You also only need to alter and build the device tree, e.g. by using make <device tree name> or just make dtbs to build all the device trees. Then replace the file on the SD-card and deploy it using run setupdate && run prepare_ubi && run update_fdt.

5

Hello.

Thanks for your support, it helped me.

But I have some questions:

  1. I changed file “vf-colibri-eval-v3.dtsi” by adding can1-section, but I not disabled i2c0-interface (see pic. 1). Is it normal or can bring some hw/sw conflicts?
  2. After loading new Linux the command “ip link” shows CAN-interface as can0 (see pic. 2), despite I have added it as can1 in dtsi-file. Is it normal or it should be shown also “can1”?
  3. Do you have any simple utility for testing CAN-interface, that is already compiled for use under Linux for VFxx? I mead the utility, which can show that CAN works.

[upload|Rv5UfhRd9nOR2oVbf4mIOTwhAz8=]
[upload|yi4++AwxWtzXt9XODOR3n8KknG8=]

6
  1. Device Tree lets you specify such conflicts, however, the Linux kernel checks whether pins have already been claimed. The kernel log (check using dmesg) should report such conflicts. The second device which tries to claim already used pins will fail to probe. The problem is, you don’t know ahead of time which device gets probed first, hence the outcome is not predictable. Therefor, it is good practice to avoid such conflicts already in the device tree (e.g. disable i1c0 in your case).
  2. The device tree node name is not carried over to the Linux kernel. The Linux kernel re-enumerates devices on its own.
  3. Our image comes with canutils preinstalled. You can use candump and cansend to test the CAN bus. See also the Configuration/Testing section in the CAN article.