[RFC] LIBIIO

[RFC] LIBIIO

[Paul Cercueil]

Hi there,

I would like to present the project I've been working on for the past 
two weeks: libiio, a library for interfacing IIO devices.
Available here: https://github.com/analogdevicesinc/libiio

As it is still in its infancy, I would like to receive feedback about 
the API, what is good, what would you change etc.

The API provides a couple of top-level functions to create a context, 
either bound to the local IIO devices through sysfs, to a XML 
representation, or to a remote server. This context structure (struct 
iio_context) contains a list of devices and the context-specific 
low-level operations to interact with them.

 From the context structure it is possible to retrieve the structures 
representing the devices (struct iio_device). Devices have an ID, a 
name, attributes and channels.

Attributes essentially correspond to files in sysfs. For instance, the 
attribute "sampling_frequency" of the device with the ID "iio:device0" 
matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
The API provides functions to read or write attributes.

Channels (struct iio_channel) represent a measure channel of a ADC or a 
control channel of an DAC. In the local context, the channels are 
deduced from the filenames in sysfs. For example, the file 
"out_voltage0_vccout_offset" translates to an output channel with ID 
"voltage0", name "vccout" featuring an attribute named "offset".

The following sysfs files, for instance, would create the following tree:

root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
buffer/
dev
...
in_magn_filter_low_pass_3db_frequency
in_magn_scale
in_magn_x_raw
in_magn_y_raw
in_magn_z_raw
name
power/
sampling_frequency
scan_elements/
subsystem
trigger/
uevent

---

IIO context has 1 devices:
	iio:device0: adis16488
		11 channels found:
			...
			magn_x:  (input)
			4 channel-specific attributes found:
				attr 0: calibbias
				attr 1: filter_low_pass_3db_frequency
				attr 2: raw
				attr 3: scale
			magn_y:  (input)
			4 channel-specific attributes found:
				attr 0: calibbias
				attr 1: filter_low_pass_3db_frequency
				attr 2: raw
				attr 3: scale
			magn_z:  (input)
			4 channel-specific attributes found:
				attr 0: calibbias
				attr 1: filter_low_pass_3db_frequency
				attr 2: raw
				attr 3: scale
		1 device-specific attributes found:
				attr 0: sampling_frequency

---

The API provides ways to read and write a stream of values. Either the 
raw stream (basically reading/writing the dev node directly), or a 
processed stream, corresponding to a single channel, with an optional 
conversion step. In this case, the conversion is automatically deduced 
from the attributes, notably the "scale" attribute.

One recurring issue when working with IIO devices, is that only one 
application can use an IIO device at a time. I intend to address that 
issue by developping a network daemon (called iiod, that's original) 
that would use the local backend of the libiio library, and stream the 
data from/to a device from/to all of its connected clients. The clients 
would then just be applications compiled with the libiio library, and 
using the network backend of the library (note that switching between 
backends is just a matter of creating the iio_context structure with a 
different function). Once that works, a specific daemon / libiio backend 
couple could be designed using fast SHM mechanism for high-speed 
concurrent local access to the devices.

As I may be overseeing certain things or missing others, I would like to 
know what is your opinion of the API and the library so far, and if you 
would use such a library. The feedback is important to me so that the 
project moves in the right direction.

Thanks,

Paul

Re: [RFC] LIBIIO

[Manuel Stahl]

Hi Paul,

I didn't read all of your text (will do later), but would like to point out that there is alreay a project going on here:
http://sourceforge.net/projects/iioutils/

You're very welcome to contribute.

Regards,
Manuel Stahl

Am Montag, 3. März 2014, 12:31:46 schrieb Paul Cercueil:
> Hi there,
> 
> I would like to present the project I've been working on for the past 
> two weeks: libiio, a library for interfacing IIO devices.
> Available here: https://github.com/analogdevicesinc/libiio
> 
> As it is still in its infancy, I would like to receive feedback about 
> the API, what is good, what would you change etc.
> 
> The API provides a couple of top-level functions to create a context, 
> either bound to the local IIO devices through sysfs, to a XML 
> representation, or to a remote server. This context structure (struct 
> iio_context) contains a list of devices and the context-specific 
> low-level operations to interact with them.
> 
>  From the context structure it is possible to retrieve the structures 
> representing the devices (struct iio_device). Devices have an ID, a 
> name, attributes and channels.
> 
> Attributes essentially correspond to files in sysfs. For instance, the 
> attribute "sampling_frequency" of the device with the ID "iio:device0" 
> matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
> The API provides functions to read or write attributes.
> 
> Channels (struct iio_channel) represent a measure channel of a ADC or a 
> control channel of an DAC. In the local context, the channels are 
> deduced from the filenames in sysfs. For example, the file 
> "out_voltage0_vccout_offset" translates to an output channel with ID 
> "voltage0", name "vccout" featuring an attribute named "offset".
> 
> The following sysfs files, for instance, would create the following tree:
> 
> root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
> buffer/
> dev
> ...
> in_magn_filter_low_pass_3db_frequency
> in_magn_scale
> in_magn_x_raw
> in_magn_y_raw
> in_magn_z_raw
> name
> power/
> sampling_frequency
> scan_elements/
> subsystem
> trigger/
> uevent
> 
> ---
> 
> IIO context has 1 devices:
> 	iio:device0: adis16488
> 		11 channels found:
> 			...
> 			magn_x:  (input)
> 			4 channel-specific attributes found:
> 				attr 0: calibbias
> 				attr 1: filter_low_pass_3db_frequency
> 				attr 2: raw
> 				attr 3: scale
> 			magn_y:  (input)
> 			4 channel-specific attributes found:
> 				attr 0: calibbias
> 				attr 1: filter_low_pass_3db_frequency
> 				attr 2: raw
> 				attr 3: scale
> 			magn_z:  (input)
> 			4 channel-specific attributes found:
> 				attr 0: calibbias
> 				attr 1: filter_low_pass_3db_frequency
> 				attr 2: raw
> 				attr 3: scale
> 		1 device-specific attributes found:
> 				attr 0: sampling_frequency
> 
> ---
> 
> The API provides ways to read and write a stream of values. Either the 
> raw stream (basically reading/writing the dev node directly), or a 
> processed stream, corresponding to a single channel, with an optional 
> conversion step. In this case, the conversion is automatically deduced 
> from the attributes, notably the "scale" attribute.
> 
> One recurring issue when working with IIO devices, is that only one 
> application can use an IIO device at a time. I intend to address that 
> issue by developping a network daemon (called iiod, that's original) 
> that would use the local backend of the libiio library, and stream the 
> data from/to a device from/to all of its connected clients. The clients 
> would then just be applications compiled with the libiio library, and 
> using the network backend of the library (note that switching between 
> backends is just a matter of creating the iio_context structure with a 
> different function). Once that works, a specific daemon / libiio backend 
> couple could be designed using fast SHM mechanism for high-speed 
> concurrent local access to the devices.
> 
> As I may be overseeing certain things or missing others, I would like to 
> know what is your opinion of the API and the library so far, and if you 
> would use such a library. The feedback is important to me so that the 
> project moves in the right direction.
> 
> Thanks,
> 
> Paul
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] LIBIIO

[Lars-Peter Clausen]

On 03/05/2014 11:12 AM, Manuel Stahl wrote:
> Hi Paul,
>
> I didn't read all of your text (will do later), but would like to point out that there is alreay a project going on here:
> http://sourceforge.net/projects/iioutils/

Well, the iioutils lib is extremely low level. It is basically just a bunch 
of fprintfs and fscanfs. The libiio has a more high level abstraction build 
in. The basic structure of the libiio is the iio_context, it is a (to the 
user transparent) struct that is used for all operations (E.g. like 
get_devices()). If an application wants to do something it first allocates a 
context, there can be multiple contexts per application and each contexts 
tracks is own state, so there is no globally shared state. Each context has 
a backed. One backend is the local backend that performs all operations on 
device the application is running on. But there is also a network backend 
that connects to a sever running on a different device. This allows to run 
the same application on local and remote the devices without the application 
having to have any special code for supporting this.

There is also a IIO daemon that can sit between the application and the IIO 
sysfs. This daemon allows for multiple applications accessing the same 
device without trampling over each others feet and also allows to run the 
application without root rights.

My hopes are that the libiio can eventually replace the iio-utils lib.

- Lars

>
> You're very welcome to contribute.
>
> Regards,
> Manuel Stahl
>
> Am Montag, 3. März 2014, 12:31:46 schrieb Paul Cercueil:
>> Hi there,
>>
>> I would like to present the project I've been working on for the past
>> two weeks: libiio, a library for interfacing IIO devices.
>> Available here: https://github.com/analogdevicesinc/libiio
>>
>> As it is still in its infancy, I would like to receive feedback about
>> the API, what is good, what would you change etc.
>>
>> The API provides a couple of top-level functions to create a context,
>> either bound to the local IIO devices through sysfs, to a XML
>> representation, or to a remote server. This context structure (struct
>> iio_context) contains a list of devices and the context-specific
>> low-level operations to interact with them.
>>
>>   From the context structure it is possible to retrieve the structures
>> representing the devices (struct iio_device). Devices have an ID, a
>> name, attributes and channels.
>>
>> Attributes essentially correspond to files in sysfs. For instance, the
>> attribute "sampling_frequency" of the device with the ID "iio:device0"
>> matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
>> The API provides functions to read or write attributes.
>>
>> Channels (struct iio_channel) represent a measure channel of a ADC or a
>> control channel of an DAC. In the local context, the channels are
>> deduced from the filenames in sysfs. For example, the file
>> "out_voltage0_vccout_offset" translates to an output channel with ID
>> "voltage0", name "vccout" featuring an attribute named "offset".
>>
>> The following sysfs files, for instance, would create the following tree:
>>
>> root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
>> buffer/
>> dev
>> ...
>> in_magn_filter_low_pass_3db_frequency
>> in_magn_scale
>> in_magn_x_raw
>> in_magn_y_raw
>> in_magn_z_raw
>> name
>> power/
>> sampling_frequency
>> scan_elements/
>> subsystem
>> trigger/
>> uevent
>>
>> ---
>>
>> IIO context has 1 devices:
>> 	iio:device0: adis16488
>> 		11 channels found:
>> 			...
>> 			magn_x:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 			magn_y:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 			magn_z:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 		1 device-specific attributes found:
>> 				attr 0: sampling_frequency
>>
>> ---
>>
>> The API provides ways to read and write a stream of values. Either the
>> raw stream (basically reading/writing the dev node directly), or a
>> processed stream, corresponding to a single channel, with an optional
>> conversion step. In this case, the conversion is automatically deduced
>> from the attributes, notably the "scale" attribute.
>>
>> One recurring issue when working with IIO devices, is that only one
>> application can use an IIO device at a time. I intend to address that
>> issue by developping a network daemon (called iiod, that's original)
>> that would use the local backend of the libiio library, and stream the
>> data from/to a device from/to all of its connected clients. The clients
>> would then just be applications compiled with the libiio library, and
>> using the network backend of the library (note that switching between
>> backends is just a matter of creating the iio_context structure with a
>> different function). Once that works, a specific daemon / libiio backend
>> couple could be designed using fast SHM mechanism for high-speed
>> concurrent local access to the devices.
>>
>> As I may be overseeing certain things or missing others, I would like to
>> know what is your opinion of the API and the library so far, and if you
>> would use such a library. The feedback is important to me so that the
>> project moves in the right direction.
>>
>> Thanks,
>>
>> Paul
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] LIBIIO

[Manuel Stahl]

Am Mittwoch, 5. März 2014, 15:31:42 schrieb Lars-Peter Clausen:
> On 03/05/2014 11:12 AM, Manuel Stahl wrote:
> > Hi Paul,
> >
> > I didn't read all of your text (will do later), but would like to point out that there is alreay a project going on here:
> > http://sourceforge.net/projects/iioutils/
> 
> Well, the iioutils lib is extremely low level. It is basically just a bunch 
> of fprintfs and fscanfs. The libiio has a more high level abstraction build 
> in. The basic structure of the libiio is the iio_context, it is a (to the 
> user transparent) struct that is used for all operations (E.g. like 
> get_devices()). If an application wants to do something it first allocates a 
> context, there can be multiple contexts per application and each contexts 
> tracks is own state, so there is no globally shared state. Each context has 
> a backed. One backend is the local backend that performs all operations on 
> device the application is running on. But there is also a network backend 
> that connects to a sever running on a different device. This allows to run 
> the same application on local and remote the devices without the application 
> having to have any special code for supporting this.
> 
> There is also a IIO daemon that can sit between the application and the IIO 
> sysfs. This daemon allows for multiple applications accessing the same 
> device without trampling over each others feet and also allows to run the 
> application without root rights.
> 
> My hopes are that the libiio can eventually replace the iio-utils lib.

That's also what I hope for. But we should try to avoid name clashes. The lib in iioutils is also called libiio. So I propose to merge the repositories somehow.

Regards,
Manuel

Re: [RFC] LIBIIO

[Jonathan Cameron]

Hi Paul

Looks good. I will have a more detailed look at some point.

Just been browsing headers.  One trivial point...
Try to keep function naming consistent.
I would expect create functions to be named like

iio_context_xml_create etc rather than iio_create...

Your destroy etc are that way around. Note I actually had a similar mess in early kernel iio interfaces :)

I haven't look in detail but it would be nice to hide some of the complexity of attribute
 sharing so if someone queries sampling frequency for a channel, the fact it is
 specified for a device is hidden. This might involve one attr appearing in multiple places in your hierarchy. Is this something you
 would consider?  Write semantics are more complex though.
Also beware that according to the abi, any write to an attribute can change any other
 attribute (there are sanity restrictions though)

Just quick thoughts! Sorry for top posting:)

Jonathan


On March 3, 2014 11:31:46 AM GMT+00:00, Paul Cercueil <paul.cercueil@analog.com> wrote:
>Hi there,
>
>I would like to present the project I've been working on for the past 
>two weeks: libiio, a library for interfacing IIO devices.
>Available here: https://github.com/analogdevicesinc/libiio
>
>As it is still in its infancy, I would like to receive feedback about 
>the API, what is good, what would you change etc.
>
>The API provides a couple of top-level functions to create a context, 
>either bound to the local IIO devices through sysfs, to a XML 
>representation, or to a remote server. This context structure (struct 
>iio_context) contains a list of devices and the context-specific 
>low-level operations to interact with them.
>
> From the context structure it is possible to retrieve the structures 
>representing the devices (struct iio_device). Devices have an ID, a 
>name, attributes and channels.
>
>Attributes essentially correspond to files in sysfs. For instance, the 
>attribute "sampling_frequency" of the device with the ID "iio:device0" 
>matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
>The API provides functions to read or write attributes.
>
>Channels (struct iio_channel) represent a measure channel of a ADC or a
>
>control channel of an DAC. In the local context, the channels are 
>deduced from the filenames in sysfs. For example, the file 
>"out_voltage0_vccout_offset" translates to an output channel with ID 
>"voltage0", name "vccout" featuring an attribute named "offset".
>
>The following sysfs files, for instance, would create the following
>tree:
>
>root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
>buffer/
>dev
>...
>in_magn_filter_low_pass_3db_frequency
>in_magn_scale
>in_magn_x_raw
>in_magn_y_raw
>in_magn_z_raw
>name
>power/
>sampling_frequency
>scan_elements/
>subsystem
>trigger/
>uevent
>
>---
>
>IIO context has 1 devices:
>	iio:device0: adis16488
>		11 channels found:
>			...
>			magn_x:  (input)
>			4 channel-specific attributes found:
>				attr 0: calibbias
>				attr 1: filter_low_pass_3db_frequency
>				attr 2: raw
>				attr 3: scale
>			magn_y:  (input)
>			4 channel-specific attributes found:
>				attr 0: calibbias
>				attr 1: filter_low_pass_3db_frequency
>				attr 2: raw
>				attr 3: scale
>			magn_z:  (input)
>			4 channel-specific attributes found:
>				attr 0: calibbias
>				attr 1: filter_low_pass_3db_frequency
>				attr 2: raw
>				attr 3: scale
>		1 device-specific attributes found:
>				attr 0: sampling_frequency
>
>---
>
>The API provides ways to read and write a stream of values. Either the 
>raw stream (basically reading/writing the dev node directly), or a 
>processed stream, corresponding to a single channel, with an optional 
>conversion step. In this case, the conversion is automatically deduced 
>from the attributes, notably the "scale" attribute.
>
>One recurring issue when working with IIO devices, is that only one 
>application can use an IIO device at a time. I intend to address that 
>issue by developping a network daemon (called iiod, that's original) 
>that would use the local backend of the libiio library, and stream the 
>data from/to a device from/to all of its connected clients. The clients
>
>would then just be applications compiled with the libiio library, and 
>using the network backend of the library (note that switching between 
>backends is just a matter of creating the iio_context structure with a 
>different function). Once that works, a specific daemon / libiio
>backend 
>couple could be designed using fast SHM mechanism for high-speed 
>concurrent local access to the devices.
>
>As I may be overseeing certain things or missing others, I would like
>to 
>know what is your opinion of the API and the library so far, and if you
>
>would use such a library. The feedback is important to me so that the 
>project moves in the right direction.
>
>Thanks,
>
>Paul
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

RE: [RFC] LIBIIO

[Getz, Robin]

Manuel Stahl wrote:
> Am Mittwoch, 5. März 2014, 15:31:42 schrieb Lars-Peter Clausen:
> > On 03/05/2014 11:12 AM, Manuel Stahl wrote:
> > > Hi Paul,
> > >
> > > I didn't read all of your text (will do later), but would like to point out that
> there is alreay a project going on here:
> > > http://sourceforge.net/projects/iioutils/
> >
> > Well, the iioutils lib is extremely low level. It is basically just a
> > bunch of fprintfs and fscanfs. The libiio has a more high level
> > abstraction build in. The basic structure of the libiio is the
> > iio_context, it is a (to the user transparent) struct that is used for
> > all operations (E.g. like get_devices()). If an application wants to
> > do something it first allocates a context, there can be multiple
> > contexts per application and each contexts tracks is own state, so
> > there is no globally shared state. Each context has a backed. One
> > backend is the local backend that performs all operations on device
> > the application is running on. But there is also a network backend
> > that connects to a sever running on a different device. This allows to
> > run the same application on local and remote the devices without the
> application having to have any special code for supporting this.
> >
> > There is also a IIO daemon that can sit between the application and
> > the IIO sysfs. This daemon allows for multiple applications accessing
> > the same device without trampling over each others feet and also
> > allows to run the application without root rights.
> >
> > My hopes are that the libiio can eventually replace the iio-utils lib.
> 
> That's also what I hope for. But we should try to avoid name clashes. The lib in
> iioutils is also called libiio. So I propose to merge the repositories somehow.

Changing the name is easy.

Before we can discuss merging things, I think we need to understand the long term license.
I think that we were thinking that eventually the library would be under a pretty permissive license, which might be more embedded friendly than the GPL.

You can debate the top level tools/utils examples that use the library - but I would suspect that lots of folks might want to grab snippets from those (to grok how the library works)??

-Robin

Re: [RFC] LIBIIO

[Srinivas Pandruvada]

On 03/05/2014 06:31 AM, Lars-Peter Clausen wrote:
> On 03/05/2014 11:12 AM, Manuel Stahl wrote:
>> Hi Paul,
>>
>> I didn't read all of your text (will do later), but would like to 
>> point out that there is alreay a project going on here:
>> http://sourceforge.net/projects/iioutils/
>
> Well, the iioutils lib is extremely low level. It is basically just a 
> bunch of fprintfs and fscanfs. The libiio has a more high level 
> abstraction build in. The basic structure of the libiio is the 
> iio_context, it is a (to the user transparent) struct that is used for 
> all operations (E.g. like get_devices()). If an application wants to 
> do something it first allocates a context, there can be multiple 
> contexts per application and each contexts tracks is own state, so 
> there is no globally shared state. Each context has a backed. One 
> backend is the local backend that performs all operations on device 
> the application is running on. But there is also a network backend 
> that connects to a sever running on a different device. This allows to 
> run the same application on local and remote the devices without the 
> application having to have any special code for supporting this.
>
> There is also a IIO daemon that can sit between the application and 
> the IIO sysfs. This daemon allows for multiple applications accessing 
> the same device without trampling over each others feet and also 
> allows to run the application without root rights.
>
> My hopes are that the libiio can eventually replace the iio-utils lib.
>
Now may laptops/tablets have in built sensor hubs, exposing many 
sensors, it is a good idea to develop something as a daemon.
In addition if there is any GNOME component, which provides settings and 
change screen orientation.


Thanks,
Srinivas

> - Lars
>
>>
>> You're very welcome to contribute.
>>
>> Regards,
>> Manuel Stahl
>>
>> Am Montag, 3. März 2014, 12:31:46 schrieb Paul Cercueil:
>>> Hi there,
>>>
>>> I would like to present the project I've been working on for the past
>>> two weeks: libiio, a library for interfacing IIO devices.
>>> Available here: https://github.com/analogdevicesinc/libiio
>>>
>>> As it is still in its infancy, I would like to receive feedback about
>>> the API, what is good, what would you change etc.
>>>
>>> The API provides a couple of top-level functions to create a context,
>>> either bound to the local IIO devices through sysfs, to a XML
>>> representation, or to a remote server. This context structure (struct
>>> iio_context) contains a list of devices and the context-specific
>>> low-level operations to interact with them.
>>>
>>>   From the context structure it is possible to retrieve the structures
>>> representing the devices (struct iio_device). Devices have an ID, a
>>> name, attributes and channels.
>>>
>>> Attributes essentially correspond to files in sysfs. For instance, the
>>> attribute "sampling_frequency" of the device with the ID "iio:device0"
>>> matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
>>> The API provides functions to read or write attributes.
>>>
>>> Channels (struct iio_channel) represent a measure channel of a ADC or a
>>> control channel of an DAC. In the local context, the channels are
>>> deduced from the filenames in sysfs. For example, the file
>>> "out_voltage0_vccout_offset" translates to an output channel with ID
>>> "voltage0", name "vccout" featuring an attribute named "offset".
>>>
>>> The following sysfs files, for instance, would create the following 
>>> tree:
>>>
>>> root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
>>> buffer/
>>> dev
>>> ...
>>> in_magn_filter_low_pass_3db_frequency
>>> in_magn_scale
>>> in_magn_x_raw
>>> in_magn_y_raw
>>> in_magn_z_raw
>>> name
>>> power/
>>> sampling_frequency
>>> scan_elements/
>>> subsystem
>>> trigger/
>>> uevent
>>>
>>> ---
>>>
>>> IIO context has 1 devices:
>>>     iio:device0: adis16488
>>>         11 channels found:
>>>             ...
>>>             magn_x:  (input)
>>>             4 channel-specific attributes found:
>>>                 attr 0: calibbias
>>>                 attr 1: filter_low_pass_3db_frequency
>>>                 attr 2: raw
>>>                 attr 3: scale
>>>             magn_y:  (input)
>>>             4 channel-specific attributes found:
>>>                 attr 0: calibbias
>>>                 attr 1: filter_low_pass_3db_frequency
>>>                 attr 2: raw
>>>                 attr 3: scale
>>>             magn_z:  (input)
>>>             4 channel-specific attributes found:
>>>                 attr 0: calibbias
>>>                 attr 1: filter_low_pass_3db_frequency
>>>                 attr 2: raw
>>>                 attr 3: scale
>>>         1 device-specific attributes found:
>>>                 attr 0: sampling_frequency
>>>
>>> ---
>>>
>>> The API provides ways to read and write a stream of values. Either the
>>> raw stream (basically reading/writing the dev node directly), or a
>>> processed stream, corresponding to a single channel, with an optional
>>> conversion step. In this case, the conversion is automatically deduced
>>> from the attributes, notably the "scale" attribute.
>>>
>>> One recurring issue when working with IIO devices, is that only one
>>> application can use an IIO device at a time. I intend to address that
>>> issue by developping a network daemon (called iiod, that's original)
>>> that would use the local backend of the libiio library, and stream the
>>> data from/to a device from/to all of its connected clients. The clients
>>> would then just be applications compiled with the libiio library, and
>>> using the network backend of the library (note that switching between
>>> backends is just a matter of creating the iio_context structure with a
>>> different function). Once that works, a specific daemon / libiio 
>>> backend
>>> couple could be designed using fast SHM mechanism for high-speed
>>> concurrent local access to the devices.
>>>
>>> As I may be overseeing certain things or missing others, I would 
>>> like to
>>> know what is your opinion of the API and the library so far, and if you
>>> would use such a library. The feedback is important to me so that the
>>> project moves in the right direction.
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] LIBIIO

[Paul Cercueil]

Hi Jonathan,

About function naming, my convention is to name the API functions after 
the structure they work with: iio_device_* accept a iio_device 
structure, iio_channel_* accept a iio_channel, iio_context_* accept a 
iio_context.

In that logic, the create functions are not passed a iio_context, so 
they are not named with the same pattern. However, I really don't mind 
to change that if you think having them named iio_context_create_* would 
be better.

About attributes sharing, what you describe is already implemented, just 
not for all device attributes. Given the following sysfs files:
   in_magn_scale
   in_magn_x_raw
   in_magn_y_raw
   in_magn_z_raw
the local backend of the library will detect that 'in_magn_scale' is a 
device attribute that should be shared between all input channels named 
'magn[0-9]+' or 'magn_{modifier}'. For the 'sampling_frequency' 
attribute, the library has no way to tell whether or not it applies to 
the channels, and so it is left as a device attribute.

Thanks for your comments!

Paul

On 03/05/2014 06:29 PM, Jonathan Cameron wrote:
> Hi Paul
>
> Looks good. I will have a more detailed look at some point.
>
> Just been browsing headers.  One trivial point...
> Try to keep function naming consistent.
> I would expect create functions to be named like
>
> iio_context_xml_create etc rather than iio_create...
>
> Your destroy etc are that way around. Note I actually had a similar mess in early kernel iio interfaces :)
>
> I haven't look in detail but it would be nice to hide some of the complexity of attribute
>   sharing so if someone queries sampling frequency for a channel, the fact it is
>   specified for a device is hidden. This might involve one attr appearing in multiple places in your hierarchy. Is this something you
>   would consider?  Write semantics are more complex though.
> Also beware that according to the abi, any write to an attribute can change any other
>   attribute (there are sanity restrictions though)
>
> Just quick thoughts! Sorry for top posting:)
>
> Jonathan
>
>
> On March 3, 2014 11:31:46 AM GMT+00:00, Paul Cercueil <paul.cercueil@analog.com> wrote:
>> Hi there,
>>
>> I would like to present the project I've been working on for the past
>> two weeks: libiio, a library for interfacing IIO devices.
>> Available here: https://github.com/analogdevicesinc/libiio
>>
>> As it is still in its infancy, I would like to receive feedback about
>> the API, what is good, what would you change etc.
>>
>> The API provides a couple of top-level functions to create a context,
>> either bound to the local IIO devices through sysfs, to a XML
>> representation, or to a remote server. This context structure (struct
>> iio_context) contains a list of devices and the context-specific
>> low-level operations to interact with them.
>>
>>  From the context structure it is possible to retrieve the structures
>> representing the devices (struct iio_device). Devices have an ID, a
>> name, attributes and channels.
>>
>> Attributes essentially correspond to files in sysfs. For instance, the
>> attribute "sampling_frequency" of the device with the ID "iio:device0"
>> matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency".
>> The API provides functions to read or write attributes.
>>
>> Channels (struct iio_channel) represent a measure channel of a ADC or a
>>
>> control channel of an DAC. In the local context, the channels are
>> deduced from the filenames in sysfs. For example, the file
>> "out_voltage0_vccout_offset" translates to an output channel with ID
>> "voltage0", name "vccout" featuring an attribute named "offset".
>>
>> The following sysfs files, for instance, would create the following
>> tree:
>>
>> root:/> ls -1 -p /sys/bus/iio/devices/iio:device0
>> buffer/
>> dev
>> ...
>> in_magn_filter_low_pass_3db_frequency
>> in_magn_scale
>> in_magn_x_raw
>> in_magn_y_raw
>> in_magn_z_raw
>> name
>> power/
>> sampling_frequency
>> scan_elements/
>> subsystem
>> trigger/
>> uevent
>>
>> ---
>>
>> IIO context has 1 devices:
>> 	iio:device0: adis16488
>> 		11 channels found:
>> 			...
>> 			magn_x:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 			magn_y:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 			magn_z:  (input)
>> 			4 channel-specific attributes found:
>> 				attr 0: calibbias
>> 				attr 1: filter_low_pass_3db_frequency
>> 				attr 2: raw
>> 				attr 3: scale
>> 		1 device-specific attributes found:
>> 				attr 0: sampling_frequency
>>
>> ---
>>
>> The API provides ways to read and write a stream of values. Either the
>> raw stream (basically reading/writing the dev node directly), or a
>> processed stream, corresponding to a single channel, with an optional
>> conversion step. In this case, the conversion is automatically deduced
>>from the attributes, notably the "scale" attribute.
>>
>> One recurring issue when working with IIO devices, is that only one
>> application can use an IIO device at a time. I intend to address that
>> issue by developping a network daemon (called iiod, that's original)
>> that would use the local backend of the libiio library, and stream the
>> data from/to a device from/to all of its connected clients. The clients
>>
>> would then just be applications compiled with the libiio library, and
>> using the network backend of the library (note that switching between
>> backends is just a matter of creating the iio_context structure with a
>> different function). Once that works, a specific daemon / libiio
>> backend
>> couple could be designed using fast SHM mechanism for high-speed
>> concurrent local access to the devices.
>>
>> As I may be overseeing certain things or missing others, I would like
>> to
>> know what is your opinion of the API and the library so far, and if you
>>
>> would use such a library. The feedback is important to me so that the
>> project moves in the right direction.
>>
>> Thanks,
>>
>> Paul
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>