hx711_spi

Crates.iohx711_spi
lib.rshx711_spi
version0.5.0
sourcesrc
created_at2021-04-14 13:42:48.020749
updated_at2023-03-01 09:17:02.337456
descriptionA platform agnostic driver to interface with the HX711 using SPI
homepage
repositoryhttps://github.com/crjeder/hx711_spi
max_upload_size
id383964
size216,341
Christoph (crjeder)

documentation

https://docs.rs/hx711_spi

README

hx711_spi

Crate License GitHub branch checks state

Maintained dependency status GitHub Repo stars Crates.io

This is a platform agnostic driver to interface with the HX711 load cell IC. It uses SPI instead of bit banging. This [no_std] driver is built using embedded-hal traits. It is developed on Raspberry PI and reported to work on STM32 and ESP32. It is recommended to always use cargo-crev to verify the trustworthiness of each of your dependencies, including this one.

Why did I write another HX711 driver?

In multi-user / multi-tasking environments bit banging is not reliable. SPI on the other hand handles the timing with hardware support and is not influenced by other processes.

Usage

Note: I'm using the reddefined SPI signal names ('see sparkfun's Resolution').

Use an embedded-hal implementation to get SPI. HX711 does not use SCLK, instead clock is provided by the driver using SDO. Make sure that HX711 is the only device on the bus since it does not implemnt CS (Chip Select). Connect the SDO to the PD_SCK and SDI to DOUT of the HX711. SPI clock frequency has to be between 20 kHz and 5 MHz. Since the SPI clock is not used, SPI mode 0 or mode 1 should work. You need test which one gives the best results for you. The library assumes that SDO signal is idle low. If this is not the case you have to use extra hardware to pull it low. In this case you should use the [invert-sdo] feature to send the correct signals to the hx711.

No scales functions (like tare weight and calibration) are implemented because I feel that's not part of a device driver. Power down functions exist just for compatibility. Implementation is not possible with this (ab-) use of SPI since the CPU / MPU would need to constantly send on the bus to power donwn the HX711. This would totally defy the purpose.

TODO

  • Test on more platforms
  • Power down (functions exist just for compatibility. Implementation is not possible with SPI)
  • Reset
  • [no_std]
  • make it re-entrant / thread safe

Examples

Raspberry PI

// embedded_hal implementation
use rppal::{spi::{Spi, Bus, SlaveSelect, Mode, Error},hal::Delay};

use hx711_spi::Hx711;
use nb::block;

// minimal example
fn main() -> Result<(), Error>
{
    let spi = Spi::new(Bus::Spi0, SlaveSelect::Ss0, 1_000_000, Mode::Mode0)?;
    let mut hx711 = Hx711::new(spi);

	  hx711.reset()?;
    let v = block!(hx711.read())?;
 	  println!("value = {}", v);

    Ok(())
}

STM32F1

An example stm32f103 (blue pill) initialization (note mode 1).

    use stm32f1xx_hal::time::U32Ext;
    use cortex_m_rt::entry;
    use stm32f1xx_hal::{pac, prelude::*,
      spi::{Mode, Phase, Polarity, Spi}, };

    let dp = pac::Peripherals::take().unwrap();
    let mut rcc = dp.RCC.constrain();
    let mut gpiob = dp.GPIOB.split(&mut rcc.apb2);
    let clocks = rcc.cfgr.freeze(&mut flash.acr);

    let hx711_spi_pins = (
        gpiob.pb13.into_alternate_push_pull(&mut gpiob.crh),
        gpiob.pb14.into_floating_input(&mut gpiob.crh),
        gpiob.pb15.into_alternate_push_pull(&mut gpiob.crh),
    );
    let hx711_spi = spi::Spi::spi2(device.SPI2, hx711_spi_pins, spi::MODE_1, 1.mhz(), clocks);
    let mut hx711_sensor = Hx711::new(hx711_spi);
    hx711_sensor.reset().unwrap();
    hx711_sensor.set_mode(hx711_spi::Mode::ChAGain128).unwrap(); // x128 works up to +-20mV

Roadmap

1.0 Will implement the embedded_hal::adc::OneShot once it is finalized

Feedback

All kind of feedback is welcome. If you have questions or problems, please post them on the issue tracker This is literally the first code I ever wrote in rust. I am still learning. So please be patient, it might take me some time to fix a bug. I may have to break my knowledge sound-barrier. If you have tested on another platform I'd like to hear about that, too!

Big thanx to 'jbit' for clearing the question about thread safety and 'anddreyk0' for testing on STM32 and both for debugging!

References

License

Licensed under either of

at your option.

Commit count: 253

cargo fmt