Hi, its been a while since I touched automotive_diag - wanted to syncup with you to follow up on postponed #21 stuff, and possibly more:

• normalizing routine IDs, at least the standard plus possibly manufacturer-specific ones (we can add a sub-namespace for specific ones too)
• units (pressure/temp/...) - how can we consolidate that in the automotive_diag for it to be reusable on all sides
• scaling formulas
  • is scaling documented anywhere?
• any other enums you have that you may not want to maintain because they are (semi-) standard

thx!

Cargo.toml is MIT, but LICENSE is GPL

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`

They are very common but currently not implemented, which makes the interaction via UDS more complicated out of the box.

Possibly some other commands might be needed:

• https://www.embedded-communication.com/en/misc/uds-basic-firmware-download/
• https://uds.readthedocs.io/en/stable/pages/knowledge_base/diagnostic_message.html#service-identifier
• https://piembsystech.com/request-file-transfer-0x38-service-uds-protocol/

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?

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.

Hi, I am thinking of implementing UDS in embedded (no-std) environment, and as always - it is better to have one common code everyone uses than lots of slightly incompatible/buggy projects. Do you think UDS can be refactored to operate without memory allocations, possibly as a standalone (sub-) crate? Thanks!

This is used as another VCI protocol (Similar to J2534-2, but a lot more in-depth)

Use this as a reference for the API's implementation

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.

Don't specify MSRV in the Readme (maybe add it as a badge? But i didn't find anything usable for that). Instead, use msrv Cargo.toml value.

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