provides asynchronous UDS communication via socketcan.
All communication was designed to be used primarily with ISO 14229-1:2013 definition of UDS.
For correct behaviour make sure to set-up a CAN interface first. You an you a virtual CAN interface for testing purposes, for example with the following command. To make setting-up a CAN interface easier install can-utils-rs package
cargo install can-utils-rsThen use the following command:
can-utils-rsThen select the interface type you want to use. Then make sure to match the name of the interface (can0 in the example) with the one you have set-up.
// To run the example make sure to set-up a CAN interface first!
use embedded_can::StandardId;
use log::{error, info};
use uds_rs::{UdsClient, UdsError, ResetType};
#[tokio::main(flavor = "current_thread")]
async fn main() -> Result<(), UdsError> {
env_logger::init();
// Create client
let c = UdsClient::new(
"can0",
StandardId::new(0x774).expect("Invalid src id"),
StandardId::new(0x70A).expect("Invalid dst id"),
)?;
// read data by identifier (ecu VIN)
let read_data_result = c.read_data_by_identifier(&[0xf18a]).await;
match read_data_result {
Ok(x) => info!("Read data by identifier received {:#x?}", x),
Err(e) => error!(
"Read single data by identifier failed with error: {:#x?}",
e
),
};
// reading dtc
let read_dtc_information = c.report_dtc_by_status_mask(0xff).await;
match read_dtc_information {
Ok(x) => info!("Read dtc by status mask: {:#x?}", x),
Err(e) => error!("Read dtc by status mask failed with error: {:#x?}", e),
}
// clear all stored dtc
let clear_dtc_information = c.clear_diagnostic_information(0xffffff).await;
match clear_dtc_information {
Ok(x) => info!("{:#x?}", x),
Err(e) => error!("Clear diagnostic information failed with error: {:#x?}", e),
};
// ecu reset
let ecu_reset_result = c.ecu_reset(ResetType::KeyOffOnReset).await;
match ecu_reset_result {
Ok(x) => info!("{:#x?}", x),
Err(e) => error!("Ecu reset failed with error: {:#x?}", e),
};
Ok(())
}Current communication architecture is strictly bounded request-response together. It would be much better to have these two interactions separated into queues and adding one producer for writes and one consumer for reads.
Without this functionality the services like ReadDataByPeriodicIdentifier cannot be implemented.
module uds - top module containing UdsClient trough which all interaction is provided for the user services used by UdsClient are stored in separate modules - see for example read_data_by_identifier.rs, where structure of service module is described
module communication - basic communication framework. Purpose of this module is to provide send and receive functionality for UdsClient.
each service consists of three steps
compose function - serializing service method arguments and other needed
data to Vec<u8>
send and receive - passing composed vector as slice to the communication backend and returning raw response
parse function - parsing received raw response &[u8] and serializing it into UdsMessage
For the correct behaviour, you need to have Linux kernel with applied patch: https://lore.kernel.org/linux-can/20230818114345.142983-1-lukas.magel@posteo.net/#r
This project is licensed under the MIT License - see the LICENSE file for details.