Comments

  • No way to mutate CanFrame
    No way to mutate CanFrame

    Sep 30, 2017

    I'm currently writing a rust lib for uavcan. I'm planning to use socketcan as the main testing platform (for convenience reasons).

    The way the CanFrame is currently structured there's no way to mutate the dlc/data after a frame has been created. That means I will have to work with an intermediate structure until the moment I'm ready to transfer, then convert it into a socketcan::CanFrame.

    Would you mind exposing some methods which makes it possible to implement something similar to the following trait?

    pub trait TransferFrame {
    /// Maximum data length the transfer protocol supports.
    const MAX_DATA_LENGTH: usize;
    
    /// Create a new TransferFrame with id: id, and length 0.
    /// Data length can be changed with `set_data_length(&self)`.
    /// Data can be changed with `data_as_mut(&mut self)`.
    fn new(id: TransferFrameID) -> Self;
    
    /// Returns the 28 bit ID of this TransferFrame.
    ///
    /// When deciding which frame that will be transmitted,
    /// the ID is used to prioritze (lower ID means higher priority)
    fn id(&self) -> TransferFrameID;
    
    /// Returns a slice with the data in this TransferFrame
    ///
    /// Length can be found by checking the length
    /// of this slice `self.data().len()`
    fn data(&self) -> &[u8];
    
    /// Returns a mutable slice with the data in this TransferFrame
    /// use this method to set/change the data inside this TransferFrame
    fn data_as_mut(&mut self) -> &mut[u8];
    
    /// Set the data length of this TransferFrame
    ///
    /// ## Panics
    /// `set_data_lengt(&mut self, length: usize)` should panic if `length > T::MAX_DATA_LENGTH`
    fn set_data_length(&mut self, length: usize);
    
    Reply
  • Outdated on crates.io
    Outdated on crates.io

    Feb 8, 2019

    Thanks for the lib! Is there a reason 2.0.0 is not released on crates.io?

    Reply
  • Unmaintained?
    Unmaintained?

    Jul 2, 2019

    This crate appears to be unmaintained. Any plans to continue supporting? If so, I'll consider making some pull-requests. If not, I might fork or consider other options.

    Reply
  • [WIP] Exchange custom netlink fork for neli crate
    [WIP] Exchange custom netlink fork for neli crate

    Nov 21, 2019

    This removes the custom netlink dependency in exchange for the neli-crate. I have tested bring_up and bring_down and it seems to work. There is a minor difference in the send that I have not figured out yet why sa_family is not added in neli or if that is even relevant since it has the intended effect.

    strace -s 100 -f -x of

        let iface = CanInterface::open("vcan0").expect("Failed to lookup vcan0 iface");
        iface.bring_down().unwrap();
    

    netlink-rs fork:

    bind(3, {sa_family=AF_NETLINK, nl_pid=29418, nl_groups=00000000}, 16) = 0
    sendto(3, {{len=32, type=RTM_NEWLINK, flags=NLM_F_REQUEST|NLM_F_ACK, seq=0, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("vcan0"), ifi_flags=0, ifi_change=0x1}}, 32, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 16) = 302
    recvfrom(3, {{len=36, type=NLMSG_ERROR, flags=NLM_F_CAPPED, seq=0, pid=29418}, {error=0, msg={len=32, type=RTM_NEWLINK, flags=NLM_F_REQUEST|NLM_F_ACK, seq=0, pid=0}}}, 4096, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, [16->12]) = 36
    

    neli:

    bind(3, {sa_family=AF_NETLINK, nl_pid=960, nl_groups=00000000}, 12) = 0
    sendto(3, {{len=32, type=RTM_NEWLINK, flags=NLM_F_REQUEST|NLM_F_ACK, seq=0, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("vcan0"), ifi_flags=0, ifi_change=0x1}}, 32, 0, NULL, 0) = 32
    recvfrom(3, {{len=36, type=NLMSG_ERROR, flags=NLM_F_CAPPED, seq=0, pid=960}, {error=0, msg={len=32, type=RTM_NEWLINK, flags=NLM_F_REQUEST|NLM_F_ACK, seq=0, pid=0}}}, 32768, 0, NULL, NULL) = 36
    

    WIP: since this is still waiting for merge of: https://github.com/jbaublitz/neli/pull/61, I will exchange the git link for a version once that is released.

    Reply
  • Using socketcan with asynchronous loop
    Using socketcan with asynchronous loop

    Jun 27, 2017

    Hi Marc,

    For a quick project I have been playing with socketcan, but all my other IO (mainly TCP) were using Metal IO; as a first run I'm using 2 different threads, but in a short future it would be nice to read/write to the CAN socket directly from the async loop!

    2 things are missing at the moment, which I added in a fork in this fork:

    • access to the internal file descriptor
    • API to set as non-blocking. (Directly related to #6)

    Then I wrote this small miocan adapter to make the glue between socketcan 1.6 and mio 0.6.9, plus an example of usage which works nicely on read.

    I don't know yet what would be the best course (integration in socketcan? in mio? 3rd repo as now?), but at least it's pretty cool to bootstrap that work!

    Please comment when you have time. Cheers!

    Reply
  • Setup travis ci
    Setup travis ci

    May 8, 2017

    Setup CI process using travis-ci

    Reply
  • non blocking write_frame
    non blocking write_frame

    May 16, 2017

    I see that write_frame and write_frame_insists serve different purpose. write_frame_insists is supposed to be blocking while write_frame isn't. So, I tried to use write_frame with expectation that it won't block and return immediately, practically just adding can frame to the tx_queue. However, I observed that between each frame, there is a delay about 1 ms. When I read socketcan app in C/C++, I found this little piece of code:

    fcntl(soc, F_SETFL, O_NONBLOCK);

    I forked this repo without informing you first to particularly add that line of code, because I need it right away in my project. So, what do you think to handle this issue? How do we expose this configuration? adding set_nonblocking method to CANSocket struct? Add new parameter open method?

    FYI, I am using v1.6.

    Reply
  • Update to Rust 2018 and update dependencies
    Update to Rust 2018 and update dependencies

    Sep 27, 2019

                                                                                                                                                                                                           
    Reply
  • Use libc types instead of manually choosing i32 or i64
    Use libc types instead of manually choosing i32 or i64

    Jun 24, 2017

    Hi Marc,

    LIBC's timeval struct is defined as this:

    timeval {
        tv_sec: time_t;
        tv_usec: suseconds_t
    }
    

    Those types are available in rust as well, and for that reason should be used.

    I had to fix that to use socketcan on x86_64 macos, where tv_sec is an i64 while tv_usec is an i32. Some differencies may appear on other platforms as well.

    Although macos does not support CAN interface, as we use macbooks for development it is very handy to use socketcan for replaying can dumps

    Note that this patch works well on top of release 1.6.0; on master branch I get even more errors because of the new dependency to netlink-rs. If you accept this change, it would be nice to publish a fixed release 1.6.1!

    Best regards

    Reply
  • Added CanBCMSocket.
    Added CanBCMSocket.

    Apr 19, 2017

    Implement support for SocketCAN's broadcastmanager.

    Reply