thanks a bunch for mentioning the ESP8266 support for the ADS1231 library [1] at the Arduino forum [2], where the original source was taken from. I have had it on my agenda, but there are so many things in flux that this was very much at the bottom of my priority list.
By chance, it seems to have drawn some attention [3], so i have just uploaded some changes [4] to support Atmel SAM (ARM) for Arduino Due.
Cortex M3, ok. I have some Cortex M0 boards here - we had a discussion in the MKR thread - I have today no ADS123x shield for this boards and yet not decided what board could be a good candidate for Open Hive (I think the Autonomo will make it) for a shield. But support for the Cortex M0 could be an issue for the Open Hive / hiveeyes project also in case we will make sound analyzing via I2S and measuring weight with a ADS123x also.
After doing a bit of research on the ADS1231, it appears to me that it also needs to be bit-banged, like the HX711?
At least, this is what I figure when looking at this code.
On this matter, the canonical ADS1231 library by @aerowind, which we are using, may already do that more efficiently by directly manipulating the corresponding registers? Would that even make a difference?
Ah, I see. All the ADS123X needs to be bit-banged.
… and others are even using the same detection macros we added to the HX711 driver the other day. Funny.
Apologies that I got the wrong impression on this detail. It is only the NAU7802, which has a more advanced interface that does not require bit-banging – I²C in this case?
At least, it may have unfortunate consequences on compatibility aspects with other MCUs.
This is why I am thinking about using ThomasRyanDavies/ADS1231 on hiveeyes/arduino instead. However, I haven’t evaluated if that would be feasible, or if some functionality would be missing.
Maybe it is not a good idea, as we apparently added a few production-like adjustments around interrupt masking, or such, to the @aerowind driver we are maintaining. However, the other fix needed to mitigate the type conversion error indeed is about that this routine directly uses CPU registers, instead of Arduino HAL functions, and could have been avoided if the driver would use those instead.
So, we will probably not change too much in this area. However, as I see the chips are really that similar from a software interfacing perspective, and that others are also using the CPU fastness detection macros we introduced to the HX711 driver, I am wondering if “baking a good ADS123X driver” could eventually mean to “just wrap the HX711 driver”, and add a single dedicated power-up/down-by-gpio routine on top, which may be the only effective difference then?
Apologies that I may be a bit late with my understanding of the underpinnings. I’ve actually not looked at ADS123X drivers that much until just now.