Note this library is still in development. While its current state is usable there might be unknown bugs and I find the callback implementation to be slightly cumbersome, hopefuly I improve it in a later iteration. I also need to check for any memory leaks.
Jay is a C++17 extention for Canary that add higher-layer SEA J1939 features.
It its current state the library is inteded to be run on linux machines were in-cernel j1939 drivers are not included. As was my case when working with Jetson Nano machines and J1939.
Jay depends on Canary as it provides the underlaying raw CAN bus asio sockets. Additionaly Boost-Ext SML is used to implement a state machine for dynamic address managment.
By default, Jay is not configured to use linux j1939.h instead defines its own compatible globals,
but can be configured to use them instead. The LINUX_J1939
macro should make this possible.
Thought I need to test this.
Running tests currently requires GTest, but I might change it to Boost.Core later to reduce the number of dependecies.
Jay is header-only, so you only need to add the include directory to the
include paths in your build system. An install
target is available in CMake
which will install the headers and a CMake find_package
configuration script
for easy consumption in projects built with CMake:
mkdir build
cd build
cmake ..
make install
After installation, a project built with CMake can consume the library using
find_package
:
find_package(jay REQUIRED)
target_link_libraries(my_target PUBLIC jay::jay)
Tests require the existence of 2 virtual CAN interfaces - vcan0
and vcan1
,
which can be created with the following commands:
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
sudo ip link add dev vcan1 type vcan
sudo ip link set up vcan1
Use sudo modprobe vcan
if the vcan drivers are not on.
Tests can be run using the standard test
target generated by CMake:
mkdir build
cd build
cmake ..
make test
Note that the test take some time to complete as testing timeout events adds a little over 1 min to testing.
This library might have some conflicts with the Kernel J1939 implementation of linux. As one ECU address is used the by in-kernel address managment system exclusivly. Some other information to note regarding the in-kernel system is that the mapping of connected devices is not exposed through any api currently as far as i know. Thought can-utils does include the j1939acd tool, so it can be used as code example or as default Address Claiming daemon. The current implementation is on top of Raw CAN. In the future it would be nice if I could find some way of integrating the current code with the linux J1939.