This repo should focus solely on communicating with a HX711. Functionality built on top, such as a scale for measuring weight, is out of scope and should be removed/moved into its own repo.

Restoring the backup gain and channel will be missed for exceptions other than TimeoutException.

Suggest catching base std::exception, restoring config, then rethrowing instead.

openGpioHandle, closeGpioHandle, etc...

Doesn't change and code should reflect that fact.

https://github.com/endail/hx711/search?q=assert

Code has been working for some time now and they are no longer needed.

Try run the HX711 Calibration and occurs the exception

========================================
HX711 Calibration

Find an object you know the weight of. If you can't find anything, try searching Google for your phone's specifications to find its weight. You can then use your phone to calibrate your scale.

1. Enter the unit you want to measure the object in (eg. g, kg, lb, oz): kg

2. Enter the weight of the object in the unit you chose (eg. if you chose 'g', enter the weight of the object in grams): 1

3. Enter the number of samples to take from the HX711 module (eg. 15): 30

4. Remove all objects from the scale and then press enter.

Working...terminate called after throwing an instance of 'HX711::TimeoutException'
what(): timed out while trying to read bytes from HX711
Aborted

Reading from an unconnected GPIO could lead to the process hanging (or another other unpredictable result). It may be of some use to have a method of the HX711 class to "test" whether a HX711 could be detected by using a simple read which times-out after some predefined time. Conversely, it may even be better to implement a configurable timeout within the isReady and readValue methods.

https://github.com/endail/hx711/blob/master/src/HX711.cpp#L53-L58
https://github.com/endail/hx711/blob/master/src/HX711.cpp#L118-L119

Swapping delayMicroseconds for thread sleep resulted in -1 values from the sensor. Unsure of reason why, but it may be that thread sleep functions are not being called or are being prolonged.

In any case, wiringPi's delayMicroseconds functions are working correctly and can stay.

https://en.cppreference.com/w/cpp/chrono/high_resolution_clock

The high_resolution_clock is not implemented consistently across different standard library implementations, and its use should be avoided. It is often just an alias for std::chrono::steady_clock or std::chrono::system_clock, but which one it is depends on the library or configuration. When it is a system_clock, it is not monotonic (e.g., the time can go backwards). For example, for gcc's libstdc++ it is system_clock, for MSVC it is steady_clock, and for clang's libc++ it depends on configuration.

Generally one should just use std::chrono::steady_clock or std::chrono::system_clock directly instead of std::chrono::high_resolution_clock: use steady_clock for duration measurements, and system_clock for wall-clock time.

https://github.com/endail/hx711/search?q=high_resolution_clock shows it being used in contexts where a steady clock (ie. std::chrono::steady_clock) should explicitly be used.

For the sake of consistency and to avoid confusion with Pico/RP2040 HX711 repos, rename this repo to hx711-rpi-cxx.

Note the breaking autobuild notification changes to hx711-rpi-py.

Sleeping for settling time should be separate to powering up.

Timeout should be separate from powering down to allow other/concurrent code to run.

https://elinux.org/RPi_GPIO_Code_Samples#lgpio_.28local_.2Fdev.2Fgpiochip_I.2FF.29

etc...

https://github.com/endail/hx711/blob/master/src/DiscoverTiming.cpp

Timing discovery is not in a working state and should not pollute the current codebase.

HX711 channels are linked-to a fixed, mututally-exclusive gain. See: https://github.com/endail/hx711-pico-c#where-is-channel-a-and-channel-b

Also consider using coarse timing.

Considerations:

• A HX711Collection class?
• While the current code for interfacing a single HX711 pulses the clock pin then reads the data pin, a collection of HX711s may not function properly if this is applied to a collection. Too much time may elapse and cause an individual - or all - HX711 chips to power down.
• A collection will need to pulse the clock pin of each HX711 simultaneously. This may not be an issue if each is connected to the same GPIO pin. But what if multiple HX711's clock pins are connected to different GPIO pins? And are there any other ramifications of using a single GPIO pin connected to multiple HX711 clock pins?
• What should be returned from reading a collection of HX711s? An std::vector< HX711::Value >? Perhaps a new HX711::ValueCollection class?
• lg may also provide some useful group GPIO functions in this context: lgGroupClaimInput, lgGroupClaimOutput, and lgGroupFree.
• How will current implementation be adapted? e.g an overriden HX711::read? etc...

Currently, the clock pin is pulsed with two GPIO write calls through the lg library:

https://github.com/endail/hx711/blob/master/src/HX711.cpp#L88
https://github.com/endail/hx711/blob/master/src/HX711.cpp#L97

Both call lgGpioWrite through the Utility class. But lg also has a lgTxPulse function.

I am wondering if using lgTxPulse to provide a single pulse to the HX711's clock pin may be more efficient than the two lgGpioWrite calls. If it is, it may also help to avoid the 60us power down issue.

AdvancedHX711Test.cpp
Calibration.cpp
SimpleHX711Test.cpp
test.cpp

HX711 has a predefined most significant bit format. HX711::Format is therefore redundant.

If a conversion is in progress, the gain can be altered without waiting for the conversion to complete.

Caveat: a distinction will need to be made between conversion period and input gain selection period.

The waitReady method should busy-wait for a predefined maximum amount of time. If the amount of time is exceeded, a TimeoutException should be thrown. The try-catch in setConfig can then handle accordingly.

Inheriting classes like AdvancedHX711 can then override with something else as needed.

This will also handle the case where DOUT is never "ready" for some unforeseen reason.

Open and close, begin and end, or connect and disconnect.

The high_resolution_clock is not implemented consistently across different standard library implementations, and its use should be avoided. It is often just an alias for std::chrono::steady_clock or std::chrono::system_clock, but which one it is depends on the library or configuration. When it is a system_clock, it is not monotonic (e.g., the time can go backwards). For example, for gcc's libstdc++ it is system_clock, for MSVC it is steady_clock, and for clang's libc++ it depends on configuration.

Generally one should just use std::chrono::steady_clock or std::chrono::system_clock directly instead of std::chrono::high_resolution_clock: use steady_clock for duration measurements, and system_clock for wall-clock time.

https://en.cppreference.com/w/cpp/chrono/high_resolution_clock

Both need to handle empty vectors.

Also update docs

Add a code comment on the result of this

eg. https://www.ebay.com/sch/i.html?_nkw=hx711

Note:

• (typically) green board, as opposed to Sparkfun's red board
• not all HX711 pins are broken-out on the generic board compared to the Sparkfun version
• there is no jumper on the rear of the generic board (or anywhere) for changing/selecting the sample rate
• changing the sample rate on the generic board requires delicate modification of the hardware, specifically the HX711 IC

For the sake of consistency with other repo (hx711-pico-c, etc...).

HX711 uses 24 bits, but in code it's unclear why a 32 bit int is used.

Suggest typedef'ing std::int32_t (or one of the other std ints) with HX711::rawval_t or similar.

Remove it and replace it with a 32 bit signed int. The various methods of the class can be placed in the HX711 class.

Particularly important for time based sampling where the total time does not allow for any samples to be gathered.

https://cdn.sparkfun.com/assets/b/f/5/a/e/hx711F_EN.pdf

"Reset and Power-Down" details on pg. 5 have changed. Code needs to reflect these changes.