On 04/16/2016 08:18 AM, Jonathan Cameron wrote: > On 15/04/16 19:42, Andrew F. Davis wrote: >> Hello all, >> >> I am currently working on a driver for a part similar to the AFE4300. I >> was hoping to get some information on the recommended way to handle a >> mux such as the one in the AFE4300 BCM front-end (page 13 of >> http://www.ti.com/lit/ds/symlink/afe4300.pdf has a good image). > That's marginally bonkers.. > > You do seem to get the weird and wonderful ;) I'd never appreciated > some of these weird devices existed! Much more interesting than > the average ADC. I do wish one of these days they put a regular ADC on my desk, but what fun would that be :) >> >> The top several pins are outputs that can be routed to the OP-AMP, but >> only one at a time, because of this I'm not sure if they should be >> exposed as output channels, or sysfs switches. > So they are outputs the whole time? But sometime internally fed back > in to that amplifier.. both connecting to the input and output... > > Is there a finite list of what the outputs can actually be at any time? > I'm not sure if we can map this onto standard output channels or not. > Yes, the list is technically finite, but any combination of one pin for output and one for feedback is valid. > It's described in the text as selecting between 6 contact points and > 4 impedances so I'll pretend I can see exactly how the circuit is doing that > as this is far too much thinking for a Saturday afternoon. > It's been far to much thinking for my work-week too :) I think in the data sheet they make the assumption that the PR0/1 and RN0/1 will be connected external to a reference load, then any 2 pin combo of IOUTx pins will be used to actually transmit. But this is not a hard requirement so I don't really want to limit the device by not providing a way to connect the combo IOUT3 and RN1, for instance. > If treated as output channels it would have to be done on a last come > basis with the others all being set to 0. That's fine under the ABI that > allows for any value to result in a change to any other but clunky. > This was my concern, it seems kinda odd to automatically disable an output when enabling another, but if it's explicitly allowed I'll do it. > Hmm. Treating it as output channels does kind of match with how the device > is used I think? Fire a current out of pointN and read the resulting > voltage between 2 points (one of which might be a reference)... > I really don't know myself about all this, but the way it was explained to me is that the user will connect a transmitter (for testing they gave me simple resistors, so some kind of resistive load) between the output pins, then they will read the value across a receiver (again probably just some contacts with the subjects skin tied to a pair of input pins), by switching between different transmit/receiver pairs placed at different points and frequencies (and polarities I believe) you can get a map of body impedance. So I would like every combination of pins exposed in some way if I can. > It's all channels, there is just a lot of restrictions on what can happen > at a time. > Yeah, I also like them as channels as you can set the frequency sent to the output pins using the standard IIO_CHAN_INFO_FREQUENCY. >> >> The other issue is with the input pins, I believe the standard way to >> handle this is by exposing every mux setting as a separate channel, then >> only allowing one bit set in the scan mask, but for this part, when all >> differential combinations are exposed we have more than 100 channels, >> and the other part I'm working on makes this several times worse. >> >> Could someone point to any information, or an existing driver, that >> explains the preferred way to handle this? > You have it correct above. At the end of the day there isn't much we can > do to provide a compact yet general interface and occasionally we do end > up with an awful lot of channels. There are some analog devices battery > chargers for example that end up as a cascade resulting in similar numbers > of channels. > > Each channel doesn't cost us that much other than making for a big set of > files. > What about for buffered reads, active_scan_mask seems to be sent as bits in a 64bit variable, does this then lead to a hard limitation of 64 channels? > Doing it as mux switches would work, but be extremely difficult to describe > simply to userspace in any way that would generalize. The resulting programs > would have to know too much about the sensor routing or to have a lot > of complexity decoding how to set up the channel combinations they actually > want. > Maybe: #cat in_voltage3_mux_available VSENSE0 VSENSERP1 etc.. #echo VSENCE4 > in_voltage3_mux or such for each real ADC channel with a mux in-front of it? > As for existing drivers... Hmm. any of the differential ADC drivers provide a > reference of sorts. For high channel counts, the ad7280a driver is still in > staging but the principles are fine... > Okay, I'll give that a look. Thanks, Andrew > Lars, any input on this sort of highly complex device? Looks a bit like some > of the more nuts audio chips in some ways. > > Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
