Added support for ADS1119 and updated documentation with new section

[markterrill]

Have previously signed google CLA.

Note, adding a new separate ads1119_read function was deliberate. The old read shortcut uses the concept of channels, however the ADS1119 requires a MUX index as the read can be single ended or differential via a single read call. It consequently made more sense to me to keep it separate.

I've updated the documentation thoroughly and split it out to reflect the new approach TI has taken with the 1119. It's most likely they'll follow this new approach for new chipsets.

[pimvanpelt]

Hi Mark, thanks a lot for the work here and sorry about the slight delay, I had been summer vacationing and only got back into my normal routing this week.

I took a look at the PR and have a few high level comments, bear with me. The addition of these new functions violates the API definition - the purpose of having one repo with all these ICs supported was to create an easier user experience for developers, they would have to learn only "create", "read", "destroy" primitives, and not concern themselves with implementation details of the ICs themselves. Adding special casing for ads1119 leaks the abstraction.

So may I suggest that we:

• Add ads1119 to mgos_ads1x1x_create() with sensible defaults (majority users may use defaults, and we can provide gain/scale/vref as setters).
• Add single ended reads from ads1119 to mgos_ads1x1x_read() and differential reads from ads1119 to mgos_ads1x1x_read_diff(), returning an error if the pair of channels is not available in the ads1119 mux. There's a few examples there already of casing behavior per chip type.
• Add any specific getter/setter (like {get,set}_fsr()) in an abstract way, even if that means the function will return false for all-but ADS1119:

I am trying to avoid this driver, which has a single interface for any chip it drives, turning into a grab bag of drivers each with their own interface. I'm happy to put in the work for you, if you have a reference to where I can pick up an ADS1119 (so far I've found only discrete parts at digikey/mouser).

Thanks again for the contribution.

[pimvanpelt]

FWIW, gain exists also in the other chips, so this can be a shared enum, probably hidden behind an ads1x1x_{get,set}_gain() API.

[pimvanpelt]

singleshot vs continuous mode exists also in some other versions in the ads1x1x family, so this can be a shared enum, probably hidden behind an ads1x1x_{get,set}_mode() API;

[pimvanpelt]

helpers do not go into the public API, as they are not meant to be called by users. This should go into a src/*_internal.h file.

[pimvanpelt]

(see my comment on abstraction leak in #1)

[pimvanpelt]

See rationale in #1

[markterrill]

Hi!

I did consider hiding it under the existing functions. My simple rationale is the ADS1119 is quite different to the other chips in how its setup and written to. I didn't want to pollute the existing code with extensive logic. If you'd like to take the existing functions back a step and create a legacy function for the older chips with logic to call the 1119 code as appropriate, that may be a good way to go. I didn't want all the logic in the same function and I didn't want to tear apart your functions the first time I contribute.

The other thing is create with a 1119 is substantially different. I added the mux/gain/rate etc to the properties of the device so it's set once and remembered. Currently its multiple function calls which doesn't make sense in a 1119 world as you don't set the various mux/gain separately, it's just ONE call to the device.

I do recommend two things:

• ADS1119 is clearly the way TI is going to go, once you're used to it it's a lot better way of going about setup and writing. It's kind of weird, but it really makes sense once you start using it. The technical advantages of the 1119 are huge as well.
• A redo of the create function for legacy devices so you set mux/gain/etc at the start. You can then have different logic to implement legacy via multiple calls and 1119 via one call.

Let me know your paypal and I'll send you the $ for a https://www.digikey.com.au/product-detail/en/texas-instruments/BOOSTXL-ADS1119/296-50794-ND/9686119

Hugely appreciate your library, hope it helps!

[markterrill]

Howdy. I provided a link to the boostxl dev board. Let me know a paypal address and happy to send funds.

It may be the too hard basket. It may be easier and better for everyone to have a separate 'new' TI ADS library for 1119+. Otherwise to make the existing library a swiss army knife you'd need to suffix existing 1x1x functions with _legacy, then with the old function names put traffic direction logic in to the relevant processing code. It's why I didn't want to mess with it because you'd have been wondering why your library was completely refactored. Otherwise with large if/else/case splitting it's going to become quite messy imho.

I'd be interested to hear differently, but I don't see material benefit in separating FSR / DR etc settings as logically you only call that setup once. I also put the gain/DR/CM etc as object properties so the object knows it's desired state. It's far neater imho to have all that in create.

Let me know if I should just split out a new 1119+ library for the new TI boards.