* I'm not a fan of TDDing driver code, as you get into being a simulator writer. (If there is NO hardware to test, simulating it in TDD+mock can be valuable.) I'd much rather build test-automation around the HIL test-stand to get coverage on the drivers.
You might look at the imperitive-shell, functional core pattern for this work. Essentially, you build an outer wrapper that performs the hardware interactions, and separate all of the decision making into pure-functions that are easily tested. So you end up with something like

```rust
fn task_loop() {
   let mut state = State::default;
   loop {
      let input = read_from_hardware(); // this function is not TDD'd
      let (new_state, action_opt) = business_logic(state, input); // TDD the crap out of this
      state = new_state;
      if let Some(action) = action_opt {
         output_to_hardware(action);  // this function is not TDD'd
      }
   }
}
```