Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

send utility: bug in scanf

2006-02-24
2013-06-04
  • 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).
    Sergei Sharonov

     
    • same problem with rxtx utility

       
    • Pavel Pisa
      Pavel Pisa
      2006-02-28

      Hello Sergei,

      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

      http://cvs.sourceforge.net/viewcvs.py/ocera/ocera/doc/WP10/D10.5/casestudy/canping/

      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

      http://cvs.sourceforge.net/viewcvs.py/ocera/ocera/doc/WP10/D10.5/D10-5.pdf

      Best wishes

                   Pavel

       
    • Pavel,

      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?

      Sergei

       
    • Pavel Pisa
      Pavel Pisa
      2006-03-01

      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

      http://cvs.sourceforge.net/viewcvs.py/ocera/ocera/components/comm/can/candev/

      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

      http://cvs.sourceforge.net/viewcvs.py/ocera/ocera/components/comm/can/canmon/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
      for that.

      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

        http://cmp.felk.cvut.cz/~pisa/#can

      Best wishes

                    Pavel

       
    • Pavel,

      thanks. Appreciate all the info.

      Sergei