I am currently developing a Rust-based firmware for a robotics platform that relies on a high-speed IR phototransistor array for precision navigation. The main challenge I am facing is implementing a non-blocking sampling strategy that doesn't interfere with the high-priority PID motor control loops. In traditional C++, this often leads to messy interrupt-driven state machines, so I am exploring the async/await ecosystem in Rust, specifically using the embedded-hal-async traits and the Embassy executor. I am particularly interested in how to best structure the ADC sampling to handle noise—whether to process it via a DMA-backed buffer that signals a task or to use individual async futures for each sensor read.

One of my primary concerns is the balance between software safety and hardware reliability. Since IR LEDs and phototransistors are prone to failure if the timing or current limits are handled incorrectly during high-frequency switching, I am looking for the most 'idiomatic' Rust way to implement safety guards within the driver. Should these safety checks be baked into the async poll function, or is it better to handle them in a separate supervisor task? I’ve been referencing hardware-software interface principles to ensure the PCB survives these high-frequency transients, and I would appreciate any advice on how to translate these low-level protection strategies into robust Rust abstractions. (I am not very good in english so I used the translation tool for this post)

1 post - 1 participant

Read full topic