Re: [RFC] LIBIIO

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

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
>