iio_sys_obj_matlab persistence between step calls

[icchalmers]

Currently, iio_sys_obj_matlab has no persistence in state between step calls. This is an issue when calling stepImpl() with changes in attribute values. The attributes are always compared to the default initialized values of 0, and not to what attributes were previously written as.

The code to write to IIO attributes shows this:

https://github.com/analogdevicesinc/libiio-matlab/blob/f8c43e1ca121c9e3bd9c338ae67af089938ef0e6/iio_sys_obj_matlab.m#L292-L314

obj.num_cfg_in(i) will always be zero in the comparison on line 296. This means even attributes that haven't changed will always get written. For me, this bug became apparent when I was actually trying to write a 0 to an attribute - the write never happens as it assumes the attribute is already 0.

There are two potential solutions:

1) Have iio_sys_obj_matlab inherit from the 'handle' class. This makes sense to me, as the object represents a piece of hardware anyway. This would also get rid of needing to return and store the object when you call setup i.e in the example ad9361_ModeS.m s = s.setupImpl(); simply becomes s.setupImpl();. This is more standard MATLAB system object behavior for hardware (I think?).

2) return obj after each stepImpl(), and store it back into s.

[tfcollins]

We are migrating everything to use standard system objects which are currently in a development branch here: https://github.com/analogdevicesinc/MathWorks_tools/tree/new-sys-objs (under the +adi folder). Example usages here: https://github.com/analogdevicesinc/MathWorks_tools/blob/new-sys-objs/test/AD9361Tests.m

In terms of this current issue, it might be easier to just initialize the attributes to empty elements which would fix that initialization issue. Let me look at a few options including the ones you suggested.

Thanks for reporting.