AD400x: Add support for AD400x series

[threexc]

• Add AD400x/Base.m class, refactor AD4020
• Add AD4021, AD4022
• Add AD4000, AD4004, AD4008
• Add AD4001, AD4005
• Add AD4002, AD4006, AD4010
• Add AD4003, AD4007, AD4011
• Update docs, metadata

[threexc]

Updated to match the current version of the ad400x driver.

[ribdp]

Just to confirm - have the drivers added as part of this PR been tested with the AD4020 example script (after changing the class name in the example script)?

[threexc]

Just to confirm - have the drivers added as part of this PR been tested with the AD4020 example script (after changing the class name in the example script)?

I've tested that example flow manually in the MATLAB terminal. The AD4020 example script doesn't quite work as-is right now - it seems that when rx.Voltage() is called after rx(), it outputs this error:

Error using matlabshared.libiio.base/cstatus
Attribute read failed for : raw

Error in adi.common.Attribute/getAttributeRAW (line 145)
                cstatus(obj,status,['Attribute read failed for : ' attr]);

Error in adi.AD400x.Base/get.Voltage (line 83)
                rValue = obj.getAttributeRAW('voltage0', 'raw', obj.isOutput);

I was planning on submitting a follow-up PR afterwards to remove that. Do you think that should be submitted first?

EDIT: Specifically, the example script does this:

rx();

% Retrieve ADC voltage, scale and offset
rx.Voltage();

Which results in the error mentioned above. This makes sense at the driver level, but I'm not sure why it's in the example script.

[threexc]

I suppose I could also just add that fix to this PR... :)

[ribdp]

I suppose I could also just add that fix to this PR... :)

Oh yes, that'd work too.
I was just going through the scripts trying to figure out why that error crops up in the first place...I wonder if this issue can be reproduced using a different IIO client (data capture, followed by attribute read). That would tell whether it originates from the MATLAB driver, or the firmware/Linux.

[threexc]

I suppose I could also just add that fix to this PR... :)

Oh yes, that'd work too. I was just going through the scripts trying to figure out why that error crops up in the first place...I wonder if this issue can be reproduced using a different IIO client (data capture, followed by attribute read). That would tell whether it originates from the MATLAB driver, or the firmware/Linux.

I think it's the kernel driver - if I do rx() in MATLAB and then try to read the raw voltage0 value with iio_info, I get ERROR: Device or resource busy (16). But this makes sense, since a buffer is enabled for rx() and you can't do the single conversion read when that's the case.

I've pushed an update that removes the line from the example script. I'm wondering if the Voltage() function should really be in there at all, though.

[CLAassistant]

All committers have signed the CLA.

[ribdp]

I suppose I could also just add that fix to this PR... :)

Oh yes, that'd work too. I was just going through the scripts trying to figure out why that error crops up in the first place...I wonder if this issue can be reproduced using a different IIO client (data capture, followed by attribute read). That would tell whether it originates from the MATLAB driver, or the firmware/Linux.

I think it's the kernel driver - if I do rx() in MATLAB and then try to read the raw voltage0 value with iio_info, I get ERROR: Device or resource busy (16). But this makes sense, since a buffer is enabled for rx() and you can't do the single conversion read when that's the case.

I've pushed an update that removes the line from the example script. I'm wondering if the Voltage() function should really be in there at all, though.

I think it should be possible to destroy the buffer for rx channels, and then do attribute reads/writes. Something like this, perhaps - https://github.com/analogdevicesinc/ToolboxCommon/blob/be769e5517eea786eb4c0b32e231d6a03be6c105/RxTx.m#L195 ?

[threexc]

I suppose I could also just add that fix to this PR... :)

Oh yes, that'd work too. I was just going through the scripts trying to figure out why that error crops up in the first place...I wonder if this issue can be reproduced using a different IIO client (data capture, followed by attribute read). That would tell whether it originates from the MATLAB driver, or the firmware/Linux.

I think it's the kernel driver - if I do rx() in MATLAB and then try to read the raw voltage0 value with iio_info, I get ERROR: Device or resource busy (16). But this makes sense, since a buffer is enabled for rx() and you can't do the single conversion read when that's the case.
I've pushed an update that removes the line from the example script. I'm wondering if the Voltage() function should really be in there at all, though.

I think it should be possible to destroy the buffer for rx channels, and then do attribute reads/writes. Something like this, perhaps - https://github.com/analogdevicesinc/ToolboxCommon/blob/be769e5517eea786eb4c0b32e231d6a03be6c105/RxTx.m#L195 ?

I've made a local change to inherit the RxTx contents and tried to call releaseChanBuffers/destroyBuf, but both give "Cannot access method" results (which seems reasonable). I'm not overly familiar with MATLAB's object-oriented quirks though - do you know if I'm missing something with the use of those functions, or do you mean that I should re-define them inside the AD400x Base.m module?

[ribdp]

I suppose I could also just add that fix to this PR... :)

Oh yes, that'd work too. I was just going through the scripts trying to figure out why that error crops up in the first place...I wonder if this issue can be reproduced using a different IIO client (data capture, followed by attribute read). That would tell whether it originates from the MATLAB driver, or the firmware/Linux.

I think it's the kernel driver - if I do rx() in MATLAB and then try to read the raw voltage0 value with iio_info, I get ERROR: Device or resource busy (16). But this makes sense, since a buffer is enabled for rx() and you can't do the single conversion read when that's the case.
I've pushed an update that removes the line from the example script. I'm wondering if the Voltage() function should really be in there at all, though.

I think it should be possible to destroy the buffer for rx channels, and then do attribute reads/writes. Something like this, perhaps - https://github.com/analogdevicesinc/ToolboxCommon/blob/be769e5517eea786eb4c0b32e231d6a03be6c105/RxTx.m#L195 ?

I've made a local change to inherit the RxTx contents and tried to call releaseChanBuffers/destroyBuf, but both give "Cannot access method" results (which seems reasonable). I'm not overly familiar with MATLAB's object-oriented quirks though - do you know if I'm missing something with the use of those functions, or do you mean that I should re-define them inside the AD400x Base.m module?

On second thoughts - I'd say we can leave it be, and drop the rx.Voltage() for now. There's probably a way (can't think of one off the top of my head atm) to make the single conversion read work in that manner - but it's likely to be kinda messy, breaking the software layering in a dozen places.

It's better if I create an issue, and think through any refactoring that needs to be done to have an elegant solution that works for all the supported parts.

[threexc]

I pushed a new version that removes the Voltage() function entirely, but left VoltageScale() and VoltageOffset(), which both work OK. Going to do a bit more testing and then I'll ping here when I think it's fully ready.

[threexc]

Should be good to go now. The version I pushed yesterday fixes datatypes for the AD4001 and AD4005, which I had mistakenly listed as int16 when refactoring to use the AD400x base class.

[ribdp]

Lgtm

[threexc]

Thanks!