For anyone who finds themselves in a similar situation: I used rmodbus instead which is a bit more verbose, but lets me change pin voltage between writing and receiving over UART.

@ViliamVadocz, I'd also be interested in this. Could you by any chance share some (pseudo) code on how you used rmodbus to accomplish this?

@fredrik-jansson-se

Pseudocode:

let mut direction_pin = gpio.get(DIRECTION_PIN)?.into_output();
let mut modbus_request = ModbusRequest::new(SLAVE_ADDRESS, ModbusProto::Rtu);

let mut request_buffer = Vec::new();
let mut response_buffer = Vec::new();
let mut uart_buffer = [0u8; 128];

// example: get registers
modbus_request.generate_get_holdings(address, num_registers, &mut request_buffer)?;

direction_pin.set_high();
uart.write(&request)?;
// sleep (~ 1ms) to let device see that the pin is high and read data
direction_pin.set_low();
// sleep (~ 10ms) to let the device process request and send response

let read = uart.read(&mut uart_buffer)?;
modbus_request.parse_u16(&uart_buffer[..read], &mut response_buffer)?;
// use data in `response_buffer`

Of course, be sure to .clear() the Vecs and .fill(0) the UART buffer before or after use.

Fantastic, thank you!!

@fredrik-jansson-se

Pseudocode:

let mut direction_pin = gpio.get(DIRECTION_PIN)?.into_output();
let mut modbus_request = ModbusRequest::new(SLAVE_ADDRESS, ModbusProto::Rtu);

let mut request_buffer = Vec::new();
let mut response_buffer = Vec::new();
let mut uart_buffer = [0u8; 128];

// example: get registers
modbus_request.generate_get_holdings(address, num_registers, &mut request_buffer)?;

direction_pin.set_high();
uart.write(&request)?;
// sleep (~ 1ms) to let device see that the pin is high and read data
direction_pin.set_low();
// sleep (~ 10ms) to let the device process request and send response

let read = uart.read(&mut uart_buffer)?;
modbus_request.parse_u16(&uart_buffer[..read], &mut response_buffer)?;
// use data in `response_buffer`

Of course, be sure to .clear() the Vecs and .fill(0) the UART buffer before or after use.

What is uart in this pseudocode?

@amreo, full disclouse, I ended up hacking this demo in Python. But I assume the uart instance is e.g. an instance of SerialPort from https://crates.io/crates/serial.

Does that help?

This is a valid use case. Unfortunately the current, method-style request/response API does not support to inject custom code between sending the request and receiving the response.

If anyone has ideas how the API could be modified or extended to support this use case, please make a proposal. A low-level API that decouples sending and receiving would be an option. Ideally, these low-level methods would be invoked and reused by the existing high-level API.

Please check if #289 enables your use case.