linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul.cercueil@analog.com>
To: <linux-iio@vger.kernel.org>
Subject: [RFC] LIBIIO
Date: Mon, 3 Mar 2014 12:31:46 +0100	[thread overview]
Message-ID: <53146822.5020602@analog.com> (raw)

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


             reply	other threads:[~2014-03-03 11:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 11:31 Paul Cercueil [this message]
2014-03-05 10:12 ` [RFC] LIBIIO Manuel Stahl
2014-03-05 14:31   ` Lars-Peter Clausen
2014-03-05 15:11     ` Manuel Stahl
2014-03-05 19:18       ` Getz, Robin
2014-03-05 19:20     ` Srinivas Pandruvada
2014-03-05 17:29 ` Jonathan Cameron
2014-03-06  8:59   ` Paul Cercueil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53146822.5020602@analog.com \
    --to=paul.cercueil@analog.com \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).