Closed beeb closed 10 months ago
Hi beeb
Thank you for the report. What device are you targeting for this build?
The library intentionally does not take control of the GPIO ISR, since this could prevent a user from defining their own GPIO interrupts in addition to the hx711 pins.
Note the approach in examples/interrupt.rs
, the interrupt handler GPIO()
is called whenever a GPIO interrupt fires, which is actually done at the esp32-hal layer:
#[ram]
#[interrupt]
fn GPIO() {
critical_section::with(|cs| {
let mut bind = HX711_MUTEX.borrow_ref_mut(cs);
let hx711 = bind.borrow_mut().as_mut().unwrap();
if hx711.is_ready() {
HX711_READING_MUTEX.borrow(cs).set(hx711.read());
}
hx711.clear_interrupt();
});
}
If you are reading from multiple hx711s, I would make a mutex for each of them, and then check the relevant pin during the GPIO()
function to see which one triggered the interrupt, then read from it.
Hey! I'm using the library on the esp32 running with esp-idf-hal
so FreeRTOS.
The example will be helpful, but I thought maybe the critical_section
crate could still be used to dictate how and when a critical section must be entered/exited so that users can implement their own logic on top of it in an easier way.
Did you check out the link to the crate docs above?
I am experiencing corrupt values from time to time, and I think it might have something to do with how the library is implemented.
I had a look at an Arduino library for HX711 as a reference and found the following comment:
https://github.com/bogde/HX711/blob/be5e3d251b0aa6c1279edf76ab985825de4ebfd9/src/HX711.cpp#L117-L129
It seems it's important that interrupts are disabled while the SCK pin is high so that timing is accurate. For this, one would either disable interrupts (to later restore them) or use a Critital Section. The comment mentions that mangled data could be read if interrupts trigger during that time, which I believe is what I'm observing.