Send utility has a bug where scanf uses %x format specifier for message.data pointer casted to (int *). Note that message.data is an array of (unsigned char).
same problem with rxtx utility
thanks for notice of this problem.
Correction sent to the CVS.
The rxtx and send utilities are heritage from older
CAN drivers versions and I have not noticed these bugs.
I have not used these myself, we use sendburst
and readburst for testing of correct communication
and CAN bus load.
If you want really torture LinCAN, chip drivers and your hardware,
try CANping from OCERA case studies
It can run many ping-pong style communications in parallel
with different CAN driver multi open scenarios.
Usage should be clean from --help output, but you can
find full documentation in
thanks for the tip. I got (alpha) version of my spi CAN controller driver working with your lincan framework and now am testing it. I wonder what will it take to get CANOpen master working on top of that?
The library routines to build both (CANopen masters and CANopen slaves)
are part of VCA Library. There are two example/application
utilizing CANopen master routines from VCA library,
CANmaster and CANblaster programs located in directory
The CANmaster is older code, which contains main loop and select
directly in the main code and utilizes VCA in the simple functions
call manner. Monitoring client can communicate with it
through one FIFO connection. There exists bridge/multiplexer for
this FIFO based communication to the TCP network - CANmond
The single FIFO based approach has been selected to enable divission
of parts into RT-domain (RT-Linux) and regular Linux user space with TCP
connection. The code has been tested in the Linux user-space only till now.
More CANmonitors or other clients could connect to the open TCP port.
The second incarnation of master side application is CANblaster.
It utilizes higher CAN network and event driven concept found
in VCA library as well. We focused more on this code lately.
It has advantage, that only one application has to be started
to have full CAN<->Ethernet proxy. But it could be more difficult
to understand this code at first time and CANmaster could help with
VCA utilization understanding.
The infrastructure is laid and we think, that it is more flexible,
than most of other CANopen open source solutions. The basic functionality
is tested, on the other hand, there is reasonable amount of work
which needs to be done to consider implementation as finished.
We think, that we know what to do now, but we need to find
others to cooperate on the project or receive some funding
(grant/company/sponsor) to could allocate time university stuff
There is one issue with our TCP serialization/deserialization
code. Actual version of the code does unaligned accesses.
This can be solved on Linux ARM kernels by enabling
kernel fixup of these accesses. Then it works.
I need to find some student who rewrites serialization
code generation routines. Other possibility is to
introduce some CORBA based solution. But it could be overkill
for small embedded systems.
If you need simpler solution which is considered as more
finished, you can try CanFestival with LinCAN driver.
Tested interfacing of LinCAN for CanFestival2 is on my homepage.
I have sent my initial trial for Canfestival-3 to CanFestival maintainer,
but there is necessary to resolve some configuration and header file
issues to achieve clean integration state. We hope, that LinCAN
interfacing could be included as one of more possibilities
to the official CanFestival releases in the future.
If you want to try our code, start from CVS version,
it contains accumulated fixes and enhancements.
You do not need to checkout whole OCERA tree.
Quick start is described on my homepage
thanks. Appreciate all the info.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.