ivmarkov

The `hx711` driver is implemented using **bit-banging**. What that means is that this driver is doing some write on a pin, then internally using the `Ets` struct to delay, then...

[This example](https://github.com/esp-rs/esp-idf-hal/blob/master/examples/timer_notify.rs) might be a starting point to implement a better `Ets::delay` alternative. Basically you need something like a `TimerDelay` struct, where you'll instantiate and keep a Box-ed timer instance....

> Thanks a lot for the advice. I used FreeRTOS instead of Ets, and the error disappeared. FreeRTOS gives you a delay resolution of 10 ms or more. Might be...

Look [here](https://github.com/DaneSlattery/hx711/blob/main/src/hx711.rs#L39). This driver wants a delay impl with a resolution of 1 microsecond, while `FreeRTOS` is giving a resolution of 10 milliseconds. At the same time, it is *also*...

It looks like a stack overflow to me...

> @ivmarkov any thoughts on the points in the init PR comment? I think the `sync and async driver combined + address len` is pretty neat, but it differs to...

@teamplayer3 I finally have some time now, so I can start looking into this. My first question would be, why not implementing the new driver in a completely separate module...

Ahhhh, you did it except moving the existing driver to `legacy`. Maybe (and in the name of backwards compatibility) keep the old driver under its existing `i2c` module. And then...

Some quick answers here (unfortunately I don't have answers for everything...): > Is it ok to split the drivers into sync and async drivers? Main difference when using async add...

Yes I've heard about this rule before but I have mixed feelings from following it. IMO it results in more maintenance than gains - as users have to issue `cargo...