When using the channel.read function, the function will return a timeout error if the size of the buffer is larger than the number of actually received messages.

For instance, if the size of the buffer is 32, and 2 messages are received, eventually the function will wait timeout miliseconds and then return back a timeout error while waiting for 30 more messages.

Recommend handling the timeout error such that the buffer does not need to be <= the number of expected response messages.

What kind of cable is needed to read J2534? I'm aware of OBD-II to DB9, OBD-II to DB25, OBD-II to USB, OBD-II to Ethernet.

Also, are there protection methods at play that prevent J2534 over CAN access in the wild?

J2534 uses the WinAPI convention. It is defined in Windows header files as WINAPI, which is in turn defined using the Win32 declarator __stdcall. To make this crate work correctly the function pointer definitions in "j2534-0.1.2\src\cpp\j2534.cpp" need to be modified accordingly.

i.e. typedef int32_t (*PassThruOpen_t)(void *, uint32_t *); need to be changed to
typedef int32_t (WINAPI *PassThruOpen_t)(void *, uint32_t *);

Use libloading for loading PassThru DLLs instead of a C wrapper.

Seems like the latest Rust complier does not like how the references in impl Debug for PassThruMsg are unaligned.

Here's an error for &self.protocol_id specifically:

error[E0793]: reference to packed field is unaligned
   --> <redacted>\.cargo\registry\src\index.crates.io-1cd66030c949c28d\j2534-0.3.1\src\lib.rs:377:39
    |
377 |                 .field("protocol_id", &self.protocol_id)
    |                                       ^^^^^^^^^^^^^^^^^
    |
    = note: packed structs are only aligned by one byte, and many modern architectures penalize unaligned field accesses
    = note: creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
    = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

I was able to clear the compiler error by changing this code:

impl Debug for PassThruMsg {
    fn fmt(&self, f: &mut Formatter) -> fmt::Result {
        unsafe {
            f.debug_struct("PassThruMsg")
                .field("protocol_id", &self.protocol_id)
                .field("rx_status", &self.rx_status)
                .field("tx_flags", &self.tx_flags)
                .field("timestamp", &self.timestamp)
                .field("extra_data_index", &self.extra_data_index)
                .field("data", &&self.data[..self.data_size as usize])
                .finish()
        }
    }
}

to:

impl Debug for PassThruMsg {
    fn fmt(&self, f: &mut Formatter) -> fmt::Result {
        let protocol_id = self.protocol_id;
        let rx_status = self.rx_status;
        let tx_flags = self.tx_flags;
        let timestamp = self.timestamp;
        let extra_data_index = self.extra_data_index;
        unsafe {
            f.debug_struct("PassThruMsg")
                .field("protocol_id", &protocol_id)
                .field("rx_status", &rx_status)
                .field("tx_flags", &tx_flags)
                .field("timestamp", &timestamp)
                .field("extra_data_index", &extra_data_index)
                .field("data", &&self.data[..self.data_size as usize])
                .finish()
        }
    }
}

Hi there,

I'm the author of OVD (https://github.com/rnd-ash/OpenVehicleDiag), and wrote a similar J2534 API based on some of your work (Except I'm also unofficially supporting UNIX / OSX).

I found that using extern "C" fn and extern "system" fn causes issues with the i686-pc-windows-msvc target (ACCESS_VIOLATION error being triggered). Changing the function calls to extern "stdcall" fn fixes the issue

The example "examples\receive.rs" uses println!("Message: {}", msg); where msg is a j2534::PassThruMsg, but the std::fmt::Display trait is currently only implemented for j2534::Error and not for j2534::PassThruMsg.