I’m using an HX711 breakout from Sparkfun. I have it deployed in the real world because the library they link to just seemed to work. I recently found a huge bug in the library though where the code just waits forever until the chip is “ready”. Well, if the chip doesn’t report ready for some reason, your code will just hang forever. The constructor can do this too, so even if you have a watchdog on your system as soon as you instantiate it the library will hang your code.
Well, I fixed that with some simple retry-limit logic. But that got me looking at that code a little more closely which got me looking at the datasheet a little more closely. The code (https://github.com/juano2310/HX711ADC) just bit-bangs the clock line to read the 24 bits of data and then set the gain with the last few clock cycles.
The thing that has me a rocking my head back and forth a little is the timing of it all. There’s absolutely no effort in the library to time the clock line. The datasheet states that the clock shouldn’t be high for longer than 50us with a minimum of 0.2us. Well, the library sets the clock line high, reads the bit, and then sets it low. It does these 3 things 24 times in a row. The logic makes sense, but how can we guarantee those timings. What if an interrupt came along after the clock was high but before it went back to low? That same clock pin is used to power down the chip. If it’s high for more than 60us the chip powers down. So if we’re close to 50us between there already and something hijacks the processor for just 10us, the chip has powered down and we’ll never know it. We’ll then take the clock low, which we think is just getting ready for the next data bit but in reality has powered the chip back on and has reset the gain.
The datasheet is at https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf. Timing chart is on page 5. I’m not good with calculating times of instructions on microprocessors so this stuff concerns me but maybe it just shouldn’t. Could someone smarter than I take a look at that and figure out if it’s really reasonable to think that this chip can be reliably bit-banged in such a way? Unfortunately I don’t have another one to play with. Looking at that timing diagram, it appears that the data bit is shifted out when the clock goes high and will remain unchanged even when the clock goes low. Since there’s no max time on a low clock, would it seem to make more sense to read the bit after setting the clock low. So more like this:
<can’t be more than 50us in here>
Thanks for any insight.