Question about differential muxing
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).
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.
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?
Thanks,
Andrew
Jonathan Cameron
maintainerQuoted 6 lines · Andrew F. Davis
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.
Quoted 4 lines
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.
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.
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.
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)...
It's all channels, there is just a lot of restrictions on what can happen at a time.
Quoted 9 lines
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.
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.
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...
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
Quoted 8 lines
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · Jonathan Cameron
Quoted 6 lines · Andrew F. Davis
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).
Quoted 5 lines
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 :)
Quoted 10 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 9 lines
Quoted 9 lines
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?
Quoted 9 lines
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?
Quoted 6 lines
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?
Quoted 4 lines
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
Quoted 4 lines
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
On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
[...]
Quoted 23 lines
Quoted 8 lines
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.
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.
Quoted 6 lines
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...
Lars, any input on this sort of highly complex device? Looks a bit like some of the more nuts audio chips in some ways.
In my opinion we need to model MUXs and assorted sequencers properly in IIO and not hide the real hardware topology behind a simplified view. It causes all kinds of trouble since it obfuscates the real behavior of the device and makes it very hard for generic applications to understand what is going on.
It worked somewhat OK, when we had a simple hardware with a single fixed sequencer where you could easily expose the sequencer settings as multiple channels. But even for those what we expose to userspace is wrong. We only get a single scan set for all enabled channels with a single timestamp, even though when you use a sequencer these measurements are not taken at the same time.
More recent hardware usually has a completely freely programmable sequencer, this means it is possible to e.g. have a sample sequence like 1,2,1,3,... this can currently not be modeled. We can't model sequences where one channel is sampled more often than other and we can't model sequences where the channel order is different from the default. Both are valid use cases and not being able to support them hurts framework adoption. And even if we'd model all the possible combinations we get a combinatorial explosion of channels where only a subset can be selected at the same time which requires complex validation routines.
There is also hardware with multiple ADCs, where each ADC has it's own MUX and own sequencer and the ADCs do synchronous conversion. This is a extension of the above case, which we can't model for similar reasons.
And then you have the case where you have external MUXs. These can either be used together with internal sequencer or a external sequencer (e.g. just some GPIOs). We can't model these either with the current approach since the driver for the ADC would need to have support for the specific external MUX, which doesn't really scale if you want to support different types of MUXs.
While this part only has a single ADC, it has multiple chained MUXs. Since they are all internal you could model them as a single MUX and then by extension the single ADC as multiple channels, but as Andrew said that leads to state explosion, especially with the feedback paths.
Btw. I found the Comedi approach quite interesting:
http://www.comedi.org/doc/index.html#acquisitionterminology
Looking back I think this was one of the biggest mistakes we made in the IIO ABI design, thinking that it was OK to hide the hardware complexities behind a simplified view (Part of the problem is that the scope of IIO has grown and back then we didn't really thing about the more complex usecases). If you simplify at the lowest level there it is not possible to get the more complex hardware representation which might be required for certain applications. And to workaround the limitations you end up with all kind of hacks and heuristics and hardware specific interfaces. On the other hand if you adequately describe the hardware itself at the lowest level you can get the information to those applications which need it and for those who don't need it you can built simplified views on top.
Similar approaches can be seen in the e.g. the audio world, where ALSA exposed the raw hardware capabilities and pulseaudio provides a simplified view for simple applications. Or e.g. in the video world you now have the new Vulcan API which exposes the raw hardware capabilities and simplified APIs like OpenGL and DirectX are being built on top of it rather than being at the lowest level themselves.
- Lars
On 04/17/2016 08:44 PM, Andrew F. Davis wrote:
[...]
Quoted 4 lines
What about for buffered reads,
active_scan_maskseems to be sent as bits in a 64bit variable, does this then lead to a hard limitation of 64 channels?
It's a bitmask constructed from an array of 64-bit words. It's only limited by the memory your system has.
Quoted 29 lines · Lars-Peter Clausen
On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
[...]Quoted 27 lines
Quoted 8 lines
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.
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.
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...
Quoted 7 lines
Quoted 2 lines
Lars, any input on this sort of highly complex device? Looks a bit like some of the more nuts audio chips in some ways.
In my opinion we need to model MUXs and assorted sequencers properly in IIO and not hide the real hardware topology behind a simplified view. It causes all kinds of trouble since it obfuscates the real behavior of the device and makes it very hard for generic applications to understand what is going on.
Conversely it makes for an interface that is simple to use. I'd like to maintain that simplicity (but allow for the complexity as well!) Just to make life harder ;)
Quoted 7 lines
It worked somewhat OK, when we had a simple hardware with a single fixed sequencer where you could easily expose the sequencer settings as multiple channels. But even for those what we expose to userspace is wrong. We only get a single scan set for all enabled channels with a single timestamp, even though when you use a sequencer these measurements are not taken at the same time.
The intent there was always to support description of the relative timings - we'd need to do that for any sequencer description anyway. The comedi stuff does precisely that sort of description for example (and includes the various elements that we would need). It got discussed at various times, but hasn't actually gotten implemented yet. Worth keeping in mind that the description of this stuff can obviously get very complex. Setup times can vary depending on the exact sequence for example.
Quoted 10 lines
More recent hardware usually has a completely freely programmable sequencer, this means it is possible to e.g. have a sample sequence like 1,2,1,3,... this can currently not be modeled. We can't model sequences where one channel is sampled more often than other and we can't model sequences where the channel order is different from the default. Both are valid use cases and not being able to support them hurts framework adoption. And even if we'd model all the possible combinations we get a combinatorial explosion of channels where only a subset can be selected at the same time which requires complex validation routines.
The complex sequencer is indeed a case we currently dodge around at the moment. It's actually worse than you describe as we can also have interleved multiple sequences on different clocks that interact with each other and have priority levels... The sort of hardware that I'm not sure can be described in less than a few pages of big diagrams.
I have no problem with proposals to support this sort of complexity - even a wholesale replacement for the scan_elements stuff is fine - though ideally any such new framework would allow that also to work as it does cover the most common case (or would with a little extra description).
There are devices out there that support effectively unlimited sequencer lengths
- how do we support those? They stop being a scan in any sense - but become an arbitrary stream of readings. The meta data itself becomes complex enough that you can't really put it in the buffers either. Perhaps if we restrict things to a 'short' length then things can remain manageable. This stuff gets really hard to describe really quickly - even when you describe the muxes explicitly.
Funnily enough the other really nasty cases to describe generically are internal sequencers. Often, though there is a general MUX in the part supporting any combination, the sequencer only supports a random (complicated) subset of possible sequences. Those would need describing as well... Or we are back to the complex validation logic that currently causes us trouble. That's what drove the available_scan_masks approach in the first place (good old max1363 and friends)
Quoted 4 lines
There is also hardware with multiple ADCs, where each ADC has it's own MUX and own sequencer and the ADCs do synchronous conversion. This is a extension of the above case, which we can't model for similar reasons.
This is also reasonable to want to fully support, but how do you describe it? As you've highlighted the simple read one channel with a given mux setup is straight forward. How do you provide sane meta data to set up a sequence of such readings with multiple muxes switching (possibly several levels deep) to multiple ADCs?
I think you'd have to apply some sort of model that limits what can happen if you want a userspace interface (even via a library) that can describe such muxes. That's kind of where we ended up with a description based on what was actually read, rather than how it was done.
Perhaps step one in any work on this is to define the model we are going to apply. I'm not sure we can make it arbitrary. Even Vulkan defines a fairly strict model it seems.
Quoted 6 lines
And then you have the case where you have external MUXs. These can either be used together with internal sequencer or a external sequencer (e.g. just some GPIOs). We can't model these either with the current approach since the driver for the ADC would need to have support for the specific external MUX, which doesn't really scale if you want to support different types of MUXs.
Sure - this one has been bothering me for a while. Conceptually we could handle this as the mux being a client device of the IIO ADC, effectively reformatting the buffered data as it passes through (In fact I think we may ultimately do it this way, even if we have a better description of muxes in general)
The same is true for any front end device - we ultimately need to invert whatever the front end has done to establish what the original input is. This could be as simple as a potential divider halving the voltage. That could be done as a simple consumer driver that pushes the data straight through but adjusts the reported scale. An external MUX (not driven by a device based sequencer) is much the same. Synchronizing could get a little 'exciting', but shouldn't be impossible using input and output buffers running off the same triggers.
A device driven external sequencer is to my mind the same as one inside the device. It might need a little more description of course and there may be places to sensibly use library code to help handle it (some of which may be shared with the external muxes support).
Quoted 9 lines
While this part only has a single ADC, it has multiple chained MUXs. Since they are all internal you could model them as a single MUX and then by extension the single ADC as multiple channels, but as Andrew said that leads to state explosion, especially with the feedback paths.
Btw. I found the Comedi approach quite interesting:
http://www.comedi.org/doc/index.html#acquisitionterminology
Quoted 11 lines
Looking back I think this was one of the biggest mistakes we made in the IIO ABI design, thinking that it was OK to hide the hardware complexities behind a simplified view (Part of the problem is that the scope of IIO has grown and back then we didn't really thing about the more complex usecases). If you simplify at the lowest level there it is not possible to get the more complex hardware representation which might be required for certain applications. And to workaround the limitations you end up with all kind of hacks and heuristics and hardware specific interfaces. On the other hand if you adequately describe the hardware itself at the lowest level you can get the information to those applications which need it and for those who don't need it you can built simplified views on top.
I still think we need that simple view, even at the kernel boundary. I think that if we'd gone straight for the most complex option we would have ended up with poor adoption due to the barrier to entry that would provide.
The intent was always to fall back to an interface no more complex than hwmon and I think having that was and is vital to the subsystem. When a device is simple, it should look simple.
Quoted 8 lines
Similar approaches can be seen in the e.g. the audio world, where ALSA exposed the raw hardware capabilities and pulseaudio provides a simplified view for simple applications. Or e.g. in the video world you now have the new Vulcan API which exposes the raw hardware capabilities and simplified APIs like OpenGL and DirectX are being built on top of it rather than being at the lowest level themselves.
It's an interesting balance for where you provide the exposure of this complexity.
I have no objection at all to providing a means to describe this complexity. We certainly aren't limited to what we currently have in the way of interface.
However, we are dealing with a nasty case - you could I suppose compare it to an alsa system with dozens of parallel channels - each with a mux / processing description that could be a large number levels deep. Each of which has a variable timing offset wrt to the others. Every element in a scan needs it's own description of how it is muxed... At least in ALSA type devices you tend to have only a few paths going on at a time.
It's fiddly and I'm not certain we can get to an ultimate answer to everything in one go (we certainly haven't so far!).
In the meantime we have to work with what we have. If we have oversimplified a particular device description to make it work with current frameworks, then as long as the defaults are right, nothing stops us adding more interface to describe it better in the future!
Jonathan
Quoted 44 lines · Lars-Peter Clausen
On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
[...]Quoted 23 lines
Quoted 8 lines
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.
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.
Quoted 6 lines
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...
Lars, any input on this sort of highly complex device? Looks a bit like some of the more nuts audio chips in some ways.
In my opinion we need to model MUXs and assorted sequencers properly in IIO and not hide the real hardware topology behind a simplified view. It causes all kinds of trouble since it obfuscates the real behavior of the device and makes it very hard for generic applications to understand what is going on.
It worked somewhat OK, when we had a simple hardware with a single fixed sequencer where you could easily expose the sequencer settings as multiple channels. But even for those what we expose to userspace is wrong. We only get a single scan set for all enabled channels with a single timestamp, even though when you use a sequencer these measurements are not taken at the same time.
Quoted 5 lines
More recent hardware usually has a completely freely programmable sequencer, this means it is possible to e.g. have a sample sequence like 1,2,1,3,... this can currently not be modeled. We can't model sequences where one channel is sampled more often than other and we can't model sequences where the channel order is different from the default. Both are valid use cases
I'm particularly interested in this and working on a proposal to allow some sort of metadata attached with the buffer elements.
For example, this would be very useful with IMU drivers where sampling frequency is different for separate sensors. With the current implementation we either create
different IIO devices for IMU subsensors or use one IIO device with the limitation
that we cannot use different sampling frequencies.
Quoted 35 lines
and not being able to support them hurts framework adoption. And even if we'd model all the possible combinations we get a combinatorial explosion of channels where only a subset can be selected at the same time which requires complex validation routines.
There is also hardware with multiple ADCs, where each ADC has it's own MUX and own sequencer and the ADCs do synchronous conversion. This is a extension of the above case, which we can't model for similar reasons.
And then you have the case where you have external MUXs. These can either be used together with internal sequencer or a external sequencer (e.g. just some GPIOs). We can't model these either with the current approach since the driver for the ADC would need to have support for the specific external MUX, which doesn't really scale if you want to support different types of MUXs.
While this part only has a single ADC, it has multiple chained MUXs. Since they are all internal you could model them as a single MUX and then by extension the single ADC as multiple channels, but as Andrew said that leads to state explosion, especially with the feedback paths.
Btw. I found the Comedi approach quite interesting:
http://www.comedi.org/doc/index.html#acquisitionterminologyLooking back I think this was one of the biggest mistakes we made in the IIO ABI design, thinking that it was OK to hide the hardware complexities behind a simplified view (Part of the problem is that the scope of IIO has grown and back then we didn't really thing about the more complex usecases). If you simplify at the lowest level there it is not possible to get the more complex hardware representation which might be required for certain applications. And to workaround the limitations you end up with all kind of hacks and heuristics and hardware specific interfaces. On the other hand if you adequately describe the hardware itself at the lowest level you can get the information to those applications which need it and for those who don't need it you can built simplified views on top.
Quoted 6 lines
Similar approaches can be seen in the e.g. the audio world, where ALSA exposed the raw hardware capabilities and pulseaudio provides a simplified view for simple applications. Or e.g. in the video world you now have the new Vulcan API which exposes the raw hardware capabilities and simplified APIs like OpenGL and DirectX are being built on top of it rather than being at the lowest level themselves.
Agree with all of these. Let's hope we can make some improvements without increasing the complexity.
Daniel.