I'm assuming this currently only supports the Macchina A0/M2 for OSX/Linux usage?

The M2 seems to be out of stock everywhere unfortunately which makes using this library a bit difficult.

👋 Hey,

I'm trying to use this crate on a embedded device, and we don't have support for libloading.

This PR hides the hardware implementations behind feature flags so that they can be enabled conditionally.

Additionally it removes the env_logger dependency, but that's just because its not used anywhere in the project.

this language is new to me, build error is -

warning: unused imports:BorrowMut,Borrow,LockResult,cell::RefCell,convert::TryInto,default--> src\hardware\passthru\mod.rs:22:14 | 22 | borrow::{Borrow, BorrowMut}, | ^^^^^^ ^^^^^^^^^ 23 | cell::RefCell, | ^^^^^^^^^^^^^ 24 | convert::TryInto, | ^^^^^^^^^^^^^^^^ 25 | default, | ^^^^^^^ 26 | ffi::c_void, 27 | sync::{Arc, LockResult, Mutex, PoisonError}, | ^^^^^^^^^^ | = note:#[warn(unused_imports)]` on by default

warning: unused import: RegValue --> src\hardware\passthru\mod.rs:35:22 | 35 | use winreg::{RegKey, RegValue}; | ^^^^^^^^

warning: unused import: RwLock --> src\hardware\passthru\lib_funcs.rs:5:22 | 5 | use std::sync::{Arc, RwLock}; | ^^^^^^

warning: unused import: winreg::enums::* --> src\hardware\passthru\lib_funcs.rs:9:5 | 9 | use winreg::enums::*; | ^^^^^^^^^^^^^^^^

warning: unused imports: RegKey, RegValue --> src\hardware\passthru\lib_funcs.rs:12:14 | 12 | use winreg::{RegKey, RegValue}; | ^^^^^^ ^^^^^^^^

warning: unused variable: x --> src\hardware\passthru\mod.rs:811:13 | 811 | fn from(x: PoisonError) -> Self { | ^ help: if this is intentional, prefix it with an underscore: _x | = note: #[warn(unused_variables)] on by default

warning: unused variable: x --> src\hardware\passthru\mod.rs:820:13 | 820 | fn from(x: PoisonError) -> Self { | ^ help: if this is intentional, prefix it with an underscore: _x

warning: variable does not need to be mutable --> src\kwp2000\read_dtc_by_status.rs:90:9 | 90 | let mut res: Vec = Vec::new(); | ----^^^ | | | help: remove this mut | = note: #[warn(unused_mut)] on by default

warning: associated function is never used: get_version --> src\hardware\passthru\lib_funcs.rs:291:12 | 291 | pub fn get_version(&self, dev_id: u32) -> PassthruResult { | ^^^^^^^^^^^ | = note: #[warn(dead_code)] on by default

warning: associated function is never used: stop_msg_filter --> src\hardware\passthru\lib_funcs.rs:439:12 | 439 | pub fn stop_msg_filter(&self, channel_id: u32, filter_id: u32) -> PassthruResult<()> { | ^^^^^^^^^^^^^^^

warning: unused Result that must be used --> src\hardware\passthru\mod.rs:464:17 | 464 | self.close(); | ^^^^^^^^^^^^^ | = note: #[warn(unused_must_use)] on by default = note: this Result may be an Err variant, which should be handled

warning: unused Result that must be used --> src\hardware\passthru\mod.rs:636:17 | 636 | self.close(); | ^^^^^^^^^^^^^ | = note: this Result may be an Err variant, which should be handled

warning: 12 warnings emitted`

This is a specific fix for Passthru devices.

This allows for a software based ISO-TP channel to be used, allowing for both CAN+ISOTP communication protocols to be used at the same time.

This is because with the Passthru J2534 API, ISOTP and CAN are listed as conflicting channels, meaning both cannot be run at the same time

Taking inspiration from the D-PDU API, It is probably best to convert the Passthru ISO-TP methodology to software driven.

Currently, Passthru device opens a dedicated ISO-TP channel at a hardware level. This is good for performance, but it means that a dedicated CAN Channel cannot be opened at the same time as they conflict one another.

One down side to this method is it means it is impossible for the tester to send keep alive CAN messages to other ECUs in a vehicle whilst trying to maintain an ISO-TP channel with a target ECU.

Therefore, it is best to create a software ISO-TP channel, which uses a PT CAN channel to operate on. This will allow both ISO-TP messages and regular CAN messages to be exchanged at the same time.

On some older cars that utilize KWP, the ECU will never respond to session control operations, instead, it is required that the tester sends session control on the global bus can ID, which puts EVERY ECU on the network into the specified session mode

Going based off Wikipedia (again, sorry I don't have access to the official standard), it appears the UDSCommand enum is missing SID 0x29 (Authentication) and 0x38 (Request File Transfer). If you have access to the standard, can you please check it to see if these are actually missing standard services?

Background

According to Wikipedia (sorry I don't have access to the actual OBD-II specification):

The PID query and response occurs on the vehicle's CAN bus. Standard OBD requests and responses use functional addresses. The diagnostic reader initiates a query using CAN ID 7DFh, which acts as a broadcast address, and accepts responses from any ID in the range 7E8h to 7EFh. ECUs that can respond to OBD queries listen both to the functional broadcast ID of 7DFh and one assigned ID in the range 7E0h to 7E7h. Their response has an ID of their assigned ID plus 8 e.g. 7E8h through 7EFh.

This approach allows up to eight ECUs, each independently responding to OBD queries. The diagnostic reader can use the ID in the ECU response frame to continue communication with a specific ECU. In particular, multi-frame communication requires a response to the specific ECU ID rather than to ID 7DFh.

This library's current code has you specify a sid/did (tx_id, rx_id) for OBD messages, and uses a single socket (socketCAN ISO-TP kernel interface) to handle sending/receiving messages on just those addresses. However, this causes problems when running against vehicles that follow the spec.

Observed Behavior

On a 2020 Toyota Camry, I tested Service_09::get_vin(), but it causes a timeout error. The reason is that if I set the tx_id to 0x7df, I get the first frame back from the ECU (with CAN ID 0x7e8), but the ECU pauses and waits for a FlowControl frame to be sent with CAN ID 0x7e0 (8 less than the ECU's transmit ID). The ISO-TP kernel sends flow control using the original broadcast address, 0x7df, which the ECU ignores. If I set the tx_id to 0x7e0 and request the VIN, the ECU completely ignores the request.

Other Implementations

I have a scan tool that sends the OBD messages properly, and I looked at the example code for Comma.ai's Panda, and they also send the request to 0x7df and listen on 0x7e8 (which sends the FC frame using ID 0x7e0). Their handling of UDS protocol does similar filtering to ensure the tx addr is changed from 0x7df to something in the range 0x7e0-0x7e7 (based on the first response received).

Proposed Design

The OBD code should have a single transmit socket with tx_id = 0x7df, and eight listening sockets with rx_id in the range 0x7e8 - 0x7ef (and tx_id for FC frames set to a value that is 8 less than the rx_id). This would follow the specification, allowing 8 ECUs to respond to OBD queries simultaneously. If it is a simple request, like to get the VIN, then that function can just take the first response and return it. In order for this to be possible, you will first have to implement the suggestion in Issue #11 to have a software-based ISO-TP channel. The socketcan-isotp crate definitely supports this, as demonstrated in their examples.

Currently, this crate only supports version 04.04 of the J2534-2 API.

There is a recent addition to the J2534-2 API version 05.00: SAE documentation link

Needed for some J2534 devices for ISO-TP.

When an ECU responds with an ISO-TP frame that is not padded with 00 eg:

01A4: [02 10 20 76 54 32 10 99]

The adapter will reject this frame as ISO-TP as it expected the following formatted message:

01A4: [02 10 20 00 00 00 00 00]

Sending an IOCTL SET_CONFIG request of CAN_MIXED_FORMAT to the adapters ISO-TP channel will allow it to read and accept these ISO-TP frames