On Mon, Aug 19, 2024 at 6:33 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote: > > On 8/19/24 1:47 AM, Alexandru Ardelean wrote: > > The AD7606C-16 and AD7606C-18 are pretty similar with the AD7606B. > > The main difference between AD7606C-16 & AD7606C-18 is the precision in > > bits (16 vs 18). > > Because of that, some scales need to be defined for the 18-bit variants, as > > they need to be computed against 2**18 (vs 2**16 for the 16 bit-variants). > > > > Because the AD7606C-16,18 also supports bipolar & differential channels, > > for SW-mode, the default range of 10 V or ±10V should be set at probe. > > On reset, the default range (in the registers) is set to value 0x3 which > > corresponds to '±10 V single-ended range', regardless of bipolar or > > differential configuration. > > > > Aside from the scale/ranges, the AD7606C-16 is similar to the AD7606B. > > > > And the AD7606C-18 variant offers 18-bit precision. The unfortunate effect > > of this 18-bit sample size, is that there is no simple/neat way to get the > > samples into a 32-bit array without having to do a home-brewed bit-buffer. > > The ADC must read all samples (from all 8 channels) in order to get the > > N-th sample (this could be reworked to do up-to-N-th sample for scan-direct). > > There doesn't seem to be any quick-trick to be usable to pad the samples > > up to at least 24 bits. > > Even the optional status-header is 8-bits, which would mean 26-bits of data > > per sample. > > That means that when using a simple SPI controller (which can usually read > > 8 bit multiples) a simple bit-buffer trick is required. > > > Maybe it would be better to just use .bits_per_word = 18 for the 18-bit > ADC and not worry about "simple" SPI controller support for that one? > +cc Mark Brown for some input on the SPI stuff I'm generally fine with choosing to not support SPI controllers that can't do padding to 16/32 bit arrays But, at the same time: would it be an interesting topic to implement (in the SPI framework) some SW implementation for padding a series of 18-bit samples to 32-bit arrays? (Similarly, this could work for 10-15 bit samples into 16 bit arrays). Apologies if this is already implemented and I missed it. But if there isn't such a functionality (padding done in SW inside the SPI framework), then I could probably spin-up a proposal. I think that the functionality could be spun-up in a separate patch-set/discussion; and this patchset would just go with "bits_per_word = 18". It could be done as a new field in the "struct spi_transfer", or something else like "spi_pad_rx_to_nbits(struct spi_device *)" Or other suggestions welcome Thanks Alex
