You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 9, 2020. It is now read-only.
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.
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:
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.ms = s.setupImpl(); simply becomes s.setupImpl();. This is more standard MATLAB system object behavior for hardware (I think?).
return obj after each stepImpl(), and store it back into s.
The text was updated successfully, but these errors were encountered:
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.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
libiio-matlab/iio_sys_obj_matlab.m
Lines 292 to 314 in f8c43e1
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:
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 becomess.setupImpl();
. This is more standard MATLAB system object behavior for hardware (I think?).return
obj
after each stepImpl(), and store it back intos
.The text was updated successfully, but these errors were encountered: