Re: IIO Drivers

Re: IIO Drivers

[Lars-Peter Clausen]

On 02/26/2013 08:56 PM, Chris Micali wrote:
> Hello Lars,
> 
> I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.)  I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.)  I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff?  Any pointers would be very much appreciated!
> 
> Thanks,
> Chris

Hi,

I'm afraid except for the the documentation in
drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
documentation available.

The general place to ask questions about IIO is the IIO mailinglist. I've
put it on CC, hope you don't mind.

I think we can help you best if you post your code.

- Lars

Re: IIO Drivers

[Chris Micali]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

Hi Lars,
Thanks a lot for getting back to me. I've attached my code - it's pretty simple, I just copied an existing driver. As I mentioned individual reads are working fine (if i cat in_voltage0_raw) but buffered reads are failing. I've tracked the issue to industrialio-buffer.c in iio_compute_scan_bytes() which always returns zero because, i believe, the mask is 0. I haven't been able to find any docs on what 'scan masks' mean but I have seen a few drivers that supply available scan masks. Should I be specifying scan masks? 
Thanks!
-chris



On Wednesday, February 27, 2013 at 11:07 AM, Lars-Peter Clausen wrote:

> On 02/26/2013 08:56 PM, Chris Micali wrote:
> > Hello Lars,
> > 
> > I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.) I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.) I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff? Any pointers would be very much appreciated!
> > 
> > Thanks,
> > Chris
> 
> 
> 
> Hi,
> 
> I'm afraid except for the the documentation in
> drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
> driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
> documentation available.
> 
> The general place to ask questions about IIO is the IIO mailinglist. I've
> put it on CC, hope you don't mind.
> 
> I think we can help you best if you post your code.
> 
> - Lars 

[-- Attachment #2: ads7945.c --]
[-- Type: application/octet-stream, Size: 5198 bytes --]

/*
 * ADS7945 SPI ADC driver
 */

#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/sysfs.h>
#include <linux/spi/spi.h>
#include <linux/regulator/consumer.h>
#include <linux/err.h>
#include <linux/module.h>

#include <linux/iio/iio.h>
#include <linux/iio/sysfs.h>
#include <linux/iio/buffer.h>
#include <linux/iio/trigger_consumer.h>
#include <linux/iio/triggered_buffer.h>

#define RES_MASK(bits)	((1 << (bits)) - 1)

struct ads7945_state;

struct ads7945_chip_info {
	unsigned int			int_vref_uv;
	struct iio_chan_spec		channels[2];
	void (*reset)(struct ads7945_state *);
};

struct ads7945_state {
	struct spi_device		*spi;

	const struct ads7945_chip_info	*chip_info;

	struct spi_transfer		xfer;
	struct spi_message		msg;
	/*
	 * DMA (thus cache coherency maintenance) requires the
	 * transfer buffers to live in their own cache lines.
	 * Make the buffer large enough for one 16 bit sample and one 64 bit
	 * aligned 64 bit timestamp.
	 */
	unsigned char data[ALIGN(2, sizeof(s64)) + sizeof(s64)]
			____cacheline_aligned;
};

enum ads7945_supported_device_ids {
	ID_ADS7945,
};

static irqreturn_t ads7945_trigger_handler(int irq, void  *p)
{
	struct iio_poll_func *pf = p;
	struct iio_dev *indio_dev = pf->indio_dev;
	struct ads7945_state *st = iio_priv(indio_dev);
	s64 time_ns;
	int b_sent;

	b_sent = spi_sync(st->spi, &st->msg);
	if (b_sent < 0)
		goto done;

	time_ns = iio_get_time_ns();

	if (indio_dev->scan_timestamp)
		((s64 *)st->data)[1] = time_ns;

	iio_push_to_buffers(indio_dev, st->data);
done:
	iio_trigger_notify_done(indio_dev->trig);

	return IRQ_HANDLED;
}

static int ads7945_scan_direct(struct ads7945_state *st)
{
	int ret;

	ret = spi_sync(st->spi, &st->msg);
	if (ret)
		return ret;

	return be16_to_cpup((__be16 *)st->data);
}

static int ads7945_read_raw(struct iio_dev *indio_dev,
			   struct iio_chan_spec const *chan,
			   int *val,
			   int *val2,
			   long m)
{
	int ret;
	struct ads7945_state *st = iio_priv(indio_dev);
	int scale_uv;

	switch (m) {
	case IIO_CHAN_INFO_RAW:
		mutex_lock(&indio_dev->mlock);
		if (iio_buffer_enabled(indio_dev))
			ret = -EBUSY;
		else
			ret = ads7945_scan_direct(st);
		mutex_unlock(&indio_dev->mlock);

		if (ret < 0)
			return ret;
		*val = (ret >> st->chip_info->channels[0].scan_type.shift) &
			RES_MASK(st->chip_info->channels[0].scan_type.realbits);
		return IIO_VAL_INT;
	case IIO_CHAN_INFO_SCALE:
		scale_uv = st->chip_info->int_vref_uv;
		scale_uv >>= chan->scan_type.realbits;
		*val =  scale_uv / 1000;
		*val2 = (scale_uv % 1000) * 1000;
		return IIO_VAL_INT_PLUS_MICRO;
	}
	return -EINVAL;
}

static const struct ads7945_chip_info ads7945_chip_info_tbl[] = {
	[ID_ADS7945] = {
		.channels[0] = {
				.type = IIO_VOLTAGE,
				.indexed = 1,
				.channel = 1,
				.scan_type = {
						.sign = 's',
						.realbits = 14,
						.storagebits = 16,
						.shift = 2,
						.endianness = IIO_BE,
				},
				.info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT,
		},
		.channels[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
		.int_vref_uv = 2500
	},
};

static const struct iio_info ads7945_info = {
	.driver_module = THIS_MODULE,
	.read_raw = &ads7945_read_raw,
};

static int ads7945_probe(struct spi_device *spi)
{
	struct ads7945_state *st;
	struct iio_dev *indio_dev;
	int ret;

	indio_dev = iio_device_alloc(sizeof(*st));
	if (indio_dev == NULL) {
		ret = -ENOMEM;
		goto error_ret;
	}

	st = iio_priv(indio_dev);
	st->chip_info =
		&ads7945_chip_info_tbl[spi_get_device_id(spi)->driver_data];

	spi_set_drvdata(spi, indio_dev);

	st->spi = spi;

	/* Establish that the iio_dev is a child of the spi device */
	indio_dev->dev.parent = &spi->dev;
	indio_dev->name = spi_get_device_id(spi)->name;
	indio_dev->modes = INDIO_DIRECT_MODE; // | INDIO_BUFFER_TRIGGERED;
	indio_dev->channels = st->chip_info->channels;
	indio_dev->num_channels = 2;
	indio_dev->info = &ads7945_info;

	/* Setup default message */

	st->xfer.rx_buf = &st->data;
	st->xfer.len = st->chip_info->channels[0].scan_type.storagebits / 8;

	spi_message_init(&st->msg);
	spi_message_add_tail(&st->xfer, &st->msg);

	ret = iio_triggered_buffer_setup(indio_dev, NULL,
			&ads7945_trigger_handler, NULL);

	if (ret)
		goto error_free_dev;

	if (st->chip_info->reset)
		st->chip_info->reset(st);

	ret = iio_device_register(indio_dev);
	if (ret)
		goto error_ring_unregister;

	return 0;

error_ring_unregister:
	iio_triggered_buffer_cleanup(indio_dev);
error_free_dev:
	iio_device_free(indio_dev);
error_ret:
	return ret;
}

static int ads7945_remove(struct spi_device *spi)
{
	struct iio_dev *indio_dev = spi_get_drvdata(spi);

	iio_device_unregister(indio_dev);
	iio_triggered_buffer_cleanup(indio_dev);

	iio_device_free(indio_dev);

	return 0;
}

static const struct spi_device_id ads7945_id[] = {
	{"ads7945", ID_ADS7945},
	{}
};
MODULE_DEVICE_TABLE(spi, ads7945_id);

static struct spi_driver ads7945_driver = {
	.driver = {
		.name	= "ads7945",
		.owner	= THIS_MODULE,
	},
	.probe		= ads7945_probe,
	.remove		= ads7945_remove,
	.id_table	= ads7945_id,
};
module_spi_driver(ads7945_driver);

MODULE_AUTHOR("cm");
MODULE_DESCRIPTION("Texas Instruments ADS7945 and similar 1-channel ADCs");
MODULE_LICENSE("GPL v2");

Re: IIO Drivers

[Lars-Peter Clausen]

On 02/27/2013 05:21 PM, Chris Micali wrote:
> Hi Lars,
> Thanks a lot for getting back to me. I've attached my code - it's pretty simple, I just copied an existing driver. As I mentioned individual reads are working fine (if i cat in_voltage0_raw) but buffered reads are failing. I've tracked the issue to industrialio-buffer.c in iio_compute_scan_bytes() which always returns zero because, i believe, the mask is 0. I haven't been able to find any docs on what 'scan masks' mean but I have seen a few drivers that supply available scan masks. Should I be specifying scan masks? 
> Thanks!
> -chris

Hi Chris,

You need to enable the channels you want to sample in sysfs. If you are
using the command server you can for example do this by doing a 'write
ads... scan_elements/in_voltage0_en'

- Lars


> 
> 
> On Wednesday, February 27, 2013 at 11:07 AM, Lars-Peter Clausen wrote:
> 
>> On 02/26/2013 08:56 PM, Chris Micali wrote:
>>> Hello Lars,
>>>
>>> I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.) I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.) I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff? Any pointers would be very much appreciated!
>>>
>>> Thanks,
>>> Chris
>>
>>
>>
>> Hi,
>>
>> I'm afraid except for the the documentation in
>> drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
>> driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
>> documentation available.
>>
>> The general place to ask questions about IIO is the IIO mailinglist. I've
>> put it on CC, hope you don't mind.
>>
>> I think we can help you best if you post your code.
>>
>> - Lars 

Re: IIO Drivers

[Lars-Peter Clausen]

On 02/27/2013 06:15 PM, Chris Micali wrote:
> Lars, 
> 
> Thanks..  when I write 1 to scan_elements/in_voltage0_en via iio_cmdserv i get -2, from shell (echo 1>) i see write error: Invalid argument.  No output in dmesg that indicates what the error is/could be though.
> 
> -c

In your driver you commented out the INDIO_BUFFER_TRIGGERED mode flag, did
you add that back? Without it this won't work.

- Lars

> 
> 
> On Wednesday, February 27, 2013 at 11:34 AM, Lars-Peter Clausen wrote:
> 
>> On 02/27/2013 05:21 PM, Chris Micali wrote:
>>> Hi Lars,
>>> Thanks a lot for getting back to me. I've attached my code - it's pretty simple, I just copied an existing driver. As I mentioned individual reads are working fine (if i cat in_voltage0_raw) but buffered reads are failing. I've tracked the issue to industrialio-buffer.c in iio_compute_scan_bytes() which always returns zero because, i believe, the mask is 0. I haven't been able to find any docs on what 'scan masks' mean but I have seen a few drivers that supply available scan masks. Should I be specifying scan masks? 
>>> Thanks!
>>> -chris
>>>
>>
>>
>> Hi Chris,
>>
>> You need to enable the channels you want to sample in sysfs. If you are
>> using the command server you can for example do this by doing a 'write
>> ads... scan_elements/in_voltage0_en'
>>
>> - Lars
>>
>>
>>>
>>>
>>> On Wednesday, February 27, 2013 at 11:07 AM, Lars-Peter Clausen wrote:
>>>
>>>> On 02/26/2013 08:56 PM, Chris Micali wrote:
>>>>> Hello Lars,
>>>>>
>>>>> I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.) I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.) I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff? Any pointers would be very much appreciated!
>>>>>
>>>>> Thanks,
>>>>> Chris
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I'm afraid except for the the documentation in
>>>> drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
>>>> driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
>>>> documentation available.
>>>>
>>>> The general place to ask questions about IIO is the IIO mailinglist. I've
>>>> put it on CC, hope you don't mind.
>>>>
>>>> I think we can help you best if you post your code.
>>>>
>>>> - Lars 
> 
> 

Re: IIO Drivers

[Chris Micali]

lars, 

I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)  When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger  Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  

Is there a guide anywhere that captures the steps to setup and read from a driver that perhaps I missed?

-c


On Wednesday, February 27, 2013 at 12:34 PM, Lars-Peter Clausen wrote:

> On 02/27/2013 06:15 PM, Chris Micali wrote:
> > Lars, 
> > 
> > Thanks.. when I write 1 to scan_elements/in_voltage0_en via iio_cmdserv i get -2, from shell (echo 1>) i see write error: Invalid argument. No output in dmesg that indicates what the error is/could be though.
> > 
> > -c
> 
> In your driver you commented out the INDIO_BUFFER_TRIGGERED mode flag, did
> you add that back? Without it this won't work.
> 
> - Lars
> 
> > 
> > 
> > On Wednesday, February 27, 2013 at 11:34 AM, Lars-Peter Clausen wrote:
> > 
> > > On 02/27/2013 05:21 PM, Chris Micali wrote:
> > > > Hi Lars,
> > > > Thanks a lot for getting back to me. I've attached my code - it's pretty simple, I just copied an existing driver. As I mentioned individual reads are working fine (if i cat in_voltage0_raw) but buffered reads are failing. I've tracked the issue to industrialio-buffer.c in iio_compute_scan_bytes() which always returns zero because, i believe, the mask is 0. I haven't been able to find any docs on what 'scan masks' mean but I have seen a few drivers that supply available scan masks. Should I be specifying scan masks? 
> > > > Thanks!
> > > > -chris
> > > 
> > > 
> > > 
> > > 
> > > Hi Chris,
> > > 
> > > You need to enable the channels you want to sample in sysfs. If you are
> > > using the command server you can for example do this by doing a 'write
> > > ads... scan_elements/in_voltage0_en'
> > > 
> > > - Lars
> > > 
> > > 
> > > > 
> > > > 
> > > > On Wednesday, February 27, 2013 at 11:07 AM, Lars-Peter Clausen wrote:
> > > > 
> > > > > On 02/26/2013 08:56 PM, Chris Micali wrote:
> > > > > > Hello Lars,
> > > > > > 
> > > > > > I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.) I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.) I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff? Any pointers would be very much appreciated!
> > > > > > 
> > > > > > Thanks,
> > > > > > Chris
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I'm afraid except for the the documentation in
> > > > > drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
> > > > > driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
> > > > > documentation available.
> > > > > 
> > > > > The general place to ask questions about IIO is the IIO mailinglist. I've
> > > > > put it on CC, hope you don't mind.
> > > > > 
> > > > > I think we can help you best if you post your code.
> > > > > 
> > > > > - Lars 

Re: IIO Drivers

[Jonathan Cameron]

On 02/27/2013 05:36 PM, Chris Micali wrote:
> lars, 
> 
> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)

Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
for buffered reads (just effects naming).  Might have caused issues with userspace expecting a channel 0
though...

>  When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger  Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  


> 
> Is there a guide anywhere that captures the steps to setup and read from a driver that perhaps I missed?
Saddly there was a while back but it got so out of date that it because counter productive.

userspace wise, buffer_generic.c is the example of the steps.

Briefly.

1) Enable some channels via /sys/bus/iio/devices/iio:device0/scan_elements
2) Associate a trigger with the device.  For the failed to write above are you specifying
a trigger?  If not it'll guess the device is supplying one and try looking for that.
(which doesn't exist).  Hmm. that error message could probably do with some detail!
3) Enable the buffer
4) Read from the associated chrdev.



> 
> -c
> 
> 
> On Wednesday, February 27, 2013 at 12:34 PM, Lars-Peter Clausen wrote:
> 
>> On 02/27/2013 06:15 PM, Chris Micali wrote:
>>> Lars, 
>>>
>>> Thanks.. when I write 1 to scan_elements/in_voltage0_en via iio_cmdserv i get -2, from shell (echo 1>) i see write error: Invalid argument. No output in dmesg that indicates what the error is/could be though.
>>>
>>> -c
>>
>> In your driver you commented out the INDIO_BUFFER_TRIGGERED mode flag, did
>> you add that back? Without it this won't work.
>>
>> - Lars
>>
>>>
>>>
>>> On Wednesday, February 27, 2013 at 11:34 AM, Lars-Peter Clausen wrote:
>>>
>>>> On 02/27/2013 05:21 PM, Chris Micali wrote:
>>>>> Hi Lars,
>>>>> Thanks a lot for getting back to me. I've attached my code - it's pretty simple, I just copied an existing driver. As I mentioned individual reads are working fine (if i cat in_voltage0_raw) but buffered reads are failing. I've tracked the issue to industrialio-buffer.c in iio_compute_scan_bytes() which always returns zero because, i believe, the mask is 0. I haven't been able to find any docs on what 'scan masks' mean but I have seen a few drivers that supply available scan masks. Should I be specifying scan masks? 
>>>>> Thanks!
>>>>> -chris
>>>>
>>>>
>>>>
>>>>
>>>> Hi Chris,
>>>>
>>>> You need to enable the channels you want to sample in sysfs. If you are
>>>> using the command server you can for example do this by doing a 'write
>>>> ads... scan_elements/in_voltage0_en'
>>>>
>>>> - Lars
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wednesday, February 27, 2013 at 11:07 AM, Lars-Peter Clausen wrote:
>>>>>
>>>>>> On 02/26/2013 08:56 PM, Chris Micali wrote:
>>>>>>> Hello Lars,
>>>>>>>
>>>>>>> I'm doing a bit of hacking on a IIO driver based on some of your drivers on a 3.8 kernel (specifically writing a driver for a TI SPI adc.) I've been able to get a driver up and working such that I can read directly from the in_voltage0_raw on sysfs and get the correct values but I can't seem to get buffered access working (via iio_cmdsrv.) I've had a hard time finding any docs on this stuff and I was wondering if you could give me any pointers on where to look or who else perhaps to ask about this stuff? Any pointers would be very much appreciated!
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm afraid except for the the documentation in
>>>>>> drivers/staging/iio/Documentation/, the kernel doc comments and the skeleton
>>>>>> driver (drivers/staging/iio/iio_simple_dummy*) there is not much additional
>>>>>> documentation available.
>>>>>>
>>>>>> The general place to ask questions about IIO is the IIO mailinglist. I've
>>>>>> put it on CC, hope you don't mind.
>>>>>>
>>>>>> I think we can help you best if you post your code.
>>>>>>
>>>>>> - Lars 
> 
> 
> --
> 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: IIO Drivers

[Lars-Peter Clausen]

On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> On 02/27/2013 05:36 PM, Chris Micali wrote:
>> lars, 
>>
>> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> 

Yea, you are right I missed the iio_triggered_buffer_setup part.

> Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> for buffered reads (just effects naming).  Might have caused issues with userspace expecting a channel 0
> though...

I guess the scan_index had nothing to do with this, but I suggested to set
scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
.channel being 1.

> 
>>  When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger  Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  

You can't change the trigger if the buffer is currently enabled. Make sure that
he buffer is disabled (check the buffer/enable attribute).

- Lars
u

Re: IIO Drivers

[Chris Micali]

Guys, =20

Thanks a lot for the help=21  I finally tracked down issues, it was a com=
bination of a few things:

1. The .channel had to be 0, not 1 in the driver (scan=5Findex didn't mat=
ter)
2. 1 or more scan=5Felements have to be enabled as you mentioned
2. When echoing into the sysfs files it has to have a space after the num=
ber (cat 1 > in=5Fvoltage0=5Fen and not cat 1>in=5Fvo=E2=80=A6)  (duh=21)=

3. The generic=5Fbuffer.c program had a few bugs in it causing crashes.  =
I updated the iio=5Futils.h to a newer version I found here: https://gith=
ub.com/analogdevicesinc/iio-oscilloscope and then made a few modification=
s (the newer iio=5Futils did not parse a few things right in the channel =
details like bigendian/littleendian)

So generic=5Fbuffer is now correctly sampling (although it crashes after =
a couple, it's probably another iio=5Futils issue)

Thanks=21=21

-chris


On Wednesday, =46ebruary 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:

> On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > lars, =20
> > > =20
> > > I was under the impression that flag gets added automatically by ii=
o=5Ftriggered=5Fbuffer=5Fsetup (industrialiio-triggers.c:77) - I actually=
 am now able to enable the scan=5Felement after changing my channel .chan=
nel and .scan=5Findex to 0 (trying to match exactly the other drivers.)
> =20
> Yea, you are right I missed the iio=5Ftriggered=5Fbuffer=5Fsetup part.
> =20
> > Strange, scan=5Findex should have defaulted to zero and the .channel =
value shouldn't have mattered
> > for buffered reads (just effects naming). Might have caused issues wi=
th userspace expecting a channel 0
> > though...
> =20
> =20
> =20
> I guess the scan=5Findex had nothing to do with this, but I suggested t=
o set
> scan=5Felements/in=5Fvoltage0=5Fen to 1, so this clearly wouldn't have =
worked with
> .channel being 1.
> =20
> > =20
> > > When i run general=5Fbuffer (from the docs dir) with that scan elem=
ent enabled it can no longer read the trigger (Could not open /trigger/cu=
rrent=5Ftrigger =46ailed to write current=5Ftrigger file) - this succeeds=
 if that scan=5Felement is not enabled. =20
> =20
> You can't change the trigger if the buffer is currently enabled. Make s=
ure that
> he buffer is disabled (check the buffer/enable attribute).
> =20
> - Lars
> u

Re: IIO Drivers

[Chris Micali]

Last question :)  I'd like to sample from this device as quickly as possible - so I'm assuming I need to trigger quickly?  Should I use iio-trig-periodic-rtc?  Any hints/instructions on how to use that?  Should the driver supply it's own trigger that uses an hrtimer instead?

Thanks!
Chris


On Wednesday, February 27, 2013 at 2:32 PM, Chris Micali wrote:  
> Guys,  
>  
> Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
>  
> 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> 2. 1 or more scan_elements have to be enabled as you mentioned
> 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
> 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
>  
> So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
>  
> Thanks!!
>  
> -chris
>  
>  
> On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
>  
> > On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > > lars,  
> > > >  
> > > > I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> >  
> >  
> > Yea, you are right I missed the iio_triggered_buffer_setup part.
> >  
> > > Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> > > for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
> > > though...
> >  
> >  
> >  
> >  
> >  
> > I guess the scan_index had nothing to do with this, but I suggested to set
> > scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
> > .channel being 1.
> >  
> > >  
> > > > When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
> >  
> >  
> > You can't change the trigger if the buffer is currently enabled. Make sure that
> > he buffer is disabled (check the buffer/enable attribute).
> >  
> > - Lars
> > u
>  

Re: IIO Drivers

[Lars-Peter Clausen]

On 02/27/2013 08:50 PM, Chris Micali wrote:
> Last question :)  I'd like to sample from this device as quickly as possible - so I'm assuming I need to trigger quickly?  Should I use iio-trig-periodic-rtc?  Any hints/instructions on how to use that?  Should the driver supply it's own trigger that uses an hrtimer instead?
> 
> Thanks!
> Chris

Hi,

There is a generic hrtimer based trigger:
https://github.com/lclausen-adi/linux-2.6/commit/a3b5c3f7aafbcac562d6f00a6589b110bd9fb71c

Unfortunately it's not upstream ready yet.

I can be registered via a platform_device

static struct platform_device iio_trigger_hrtimer = {
	.name = "iio-trigger-hrtimer",
	.id = 0,
};

- Lars

> 
> 
> On Wednesday, February 27, 2013 at 2:32 PM, Chris Micali wrote:  
>> Guys,  
>>  
>> Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
>>  
>> 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
>> 2. 1 or more scan_elements have to be enabled as you mentioned
>> 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
>> 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
>>  
>> So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
>>  
>> Thanks!!
>>  
>> -chris
>>  
>>  
>> On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
>>  
>>> On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
>>>> On 02/27/2013 05:36 PM, Chris Micali wrote:
>>>>> lars,  
>>>>>  
>>>>> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
>>>  
>>>  
>>> Yea, you are right I missed the iio_triggered_buffer_setup part.
>>>  
>>>> Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
>>>> for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
>>>> though...
>>>  
>>>  
>>>  
>>>  
>>>  
>>> I guess the scan_index had nothing to do with this, but I suggested to set
>>> scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
>>> .channel being 1.
>>>  
>>>>  
>>>>> When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
>>>  
>>>  
>>> You can't change the trigger if the buffer is currently enabled. Make sure that
>>> he buffer is disabled (check the buffer/enable attribute).
>>>  
>>> - Lars
>>> u
>>  
> 
> 
> 
> --
> 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: IIO Drivers

[Chris Micali]

Thanks lars - i'm actually on 3.8, you don't happen to have a DT example do you?    


On Wednesday, February 27, 2013 at 3:02 PM, Lars-Peter Clausen wrote:

> On 02/27/2013 08:50 PM, Chris Micali wrote:
> > Last question :) I'd like to sample from this device as quickly as possible - so I'm assuming I need to trigger quickly? Should I use iio-trig-periodic-rtc? Any hints/instructions on how to use that? Should the driver supply it's own trigger that uses an hrtimer instead?
> >  
> > Thanks!
> > Chris
>  
>  
>  
> Hi,
>  
> There is a generic hrtimer based trigger:
> https://github.com/lclausen-adi/linux-2.6/commit/a3b5c3f7aafbcac562d6f00a6589b110bd9fb71c
>  
> Unfortunately it's not upstream ready yet.
>  
> I can be registered via a platform_device
>  
> static struct platform_device iio_trigger_hrtimer = {
> .name = "iio-trigger-hrtimer",
> .id = 0,
> };
>  
> - Lars
>  
> >  
> >  
> > On Wednesday, February 27, 2013 at 2:32 PM, Chris Micali wrote:  
> > > Guys,  
> > >  
> > > Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
> > >  
> > > 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> > > 2. 1 or more scan_elements have to be enabled as you mentioned
> > > 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
> > > 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
> > >  
> > > So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
> > >  
> > > Thanks!!
> > >  
> > > -chris
> > >  
> > >  
> > > On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
> > >  
> > > > On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > > > > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > > > > lars,  
> > > > > >  
> > > > > > I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> > > >  
> > > >  
> > > >  
> > > > Yea, you are right I missed the iio_triggered_buffer_setup part.
> > > >  
> > > > > Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> > > > > for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
> > > > > though...
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > I guess the scan_index had nothing to do with this, but I suggested to set
> > > > scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
> > > > .channel being 1.
> > > >  
> > > > >  
> > > > > > When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
> > > >  
> > > >  
> > > >  
> > > > You can't change the trigger if the buffer is currently enabled. Make sure that
> > > > he buffer is disabled (check the buffer/enable attribute).
> > > >  
> > > > - Lars
> > > > u
> > >  
> >  
> >  
> >  
> >  
> >  
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo@vger.kernel.org (mailto:majordomo@vger.kernel.org)
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>  

Re: IIO Drivers

[Lars-Peter Clausen]

On 02/27/2013 09:06 PM, Chris Micali wrote:
> Thanks lars - i'm actually on 3.8, you don't happen to have a DT example do you?    

uhm, should be just as simple:

hrtimer-trigger@0 {
	compatible = "iio-trigger-hrtimer";
};

You need to add the proper of match table to the driver though.

- Lars

> 
> 
> On Wednesday, February 27, 2013 at 3:02 PM, Lars-Peter Clausen wrote:
> 
>> On 02/27/2013 08:50 PM, Chris Micali wrote:
>>> Last question :) I'd like to sample from this device as quickly as possible - so I'm assuming I need to trigger quickly? Should I use iio-trig-periodic-rtc? Any hints/instructions on how to use that? Should the driver supply it's own trigger that uses an hrtimer instead?
>>>  
>>> Thanks!
>>> Chris
>>  
>>  
>>  
>> Hi,
>>  
>> There is a generic hrtimer based trigger:
>> https://github.com/lclausen-adi/linux-2.6/commit/a3b5c3f7aafbcac562d6f00a6589b110bd9fb71c
>>  
>> Unfortunately it's not upstream ready yet.
>>  
>> I can be registered via a platform_device
>>  
>> static struct platform_device iio_trigger_hrtimer = {
>> .name = "iio-trigger-hrtimer",
>> .id = 0,
>> };
>>  
>> - Lars
>>  
>>>  
>>>  
>>> On Wednesday, February 27, 2013 at 2:32 PM, Chris Micali wrote:  
>>>> Guys,  
>>>>  
>>>> Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
>>>>  
>>>> 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
>>>> 2. 1 or more scan_elements have to be enabled as you mentioned
>>>> 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
>>>> 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
>>>>  
>>>> So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
>>>>  
>>>> Thanks!!
>>>>  
>>>> -chris
>>>>  
>>>>  
>>>> On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
>>>>  
>>>>> On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
>>>>>> On 02/27/2013 05:36 PM, Chris Micali wrote:
>>>>>>> lars,  
>>>>>>>  
>>>>>>> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
>>>>>  
>>>>>  
>>>>>  
>>>>> Yea, you are right I missed the iio_triggered_buffer_setup part.
>>>>>  
>>>>>> Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
>>>>>> for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
>>>>>> though...
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> I guess the scan_index had nothing to do with this, but I suggested to set
>>>>> scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
>>>>> .channel being 1.
>>>>>  
>>>>>>  
>>>>>>> When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
>>>>>  
>>>>>  
>>>>>  
>>>>> You can't change the trigger if the buffer is currently enabled. Make sure that
>>>>> he buffer is disabled (check the buffer/enable attribute).
>>>>>  
>>>>> - Lars
>>>>> u
>>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majordomo@vger.kernel.org (mailto:majordomo@vger.kernel.org)
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>  
> 
> 
> 

Re: IIO Drivers

[Chris Micali]

I'll give it a shot - thanks!  


On Wednesday, February 27, 2013 at 3:15 PM, Lars-Peter Clausen wrote:

> On 02/27/2013 09:06 PM, Chris Micali wrote:
> > Thanks lars - i'm actually on 3.8, you don't happen to have a DT example do you?  
>  
>  
>  
> uhm, should be just as simple:
>  
> hrtimer-trigger@0 {
> compatible = "iio-trigger-hrtimer";
> };
>  
> You need to add the proper of match table to the driver though.
>  
> - Lars
>  
> >  
> >  
> > On Wednesday, February 27, 2013 at 3:02 PM, Lars-Peter Clausen wrote:
> >  
> > > On 02/27/2013 08:50 PM, Chris Micali wrote:
> > > > Last question :) I'd like to sample from this device as quickly as possible - so I'm assuming I need to trigger quickly? Should I use iio-trig-periodic-rtc? Any hints/instructions on how to use that? Should the driver supply it's own trigger that uses an hrtimer instead?
> > > >  
> > > > Thanks!
> > > > Chris
> > >  
> > >  
> > >  
> > >  
> > >  
> > > Hi,
> > >  
> > > There is a generic hrtimer based trigger:
> > > https://github.com/lclausen-adi/linux-2.6/commit/a3b5c3f7aafbcac562d6f00a6589b110bd9fb71c
> > >  
> > > Unfortunately it's not upstream ready yet.
> > >  
> > > I can be registered via a platform_device
> > >  
> > > static struct platform_device iio_trigger_hrtimer = {
> > > .name = "iio-trigger-hrtimer",
> > > .id = 0,
> > > };
> > >  
> > > - Lars
> > >  
> > > >  
> > > >  
> > > > On Wednesday, February 27, 2013 at 2:32 PM, Chris Micali wrote:  
> > > > > Guys,  
> > > > >  
> > > > > Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
> > > > >  
> > > > > 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> > > > > 2. 1 or more scan_elements have to be enabled as you mentioned
> > > > > 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
> > > > > 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
> > > > >  
> > > > > So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
> > > > >  
> > > > > Thanks!!
> > > > >  
> > > > > -chris
> > > > >  
> > > > >  
> > > > > On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
> > > > >  
> > > > > > On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > > > > > > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > > > > > > lars,  
> > > > > > > >  
> > > > > > > > I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > Yea, you are right I missed the iio_triggered_buffer_setup part.
> > > > > >  
> > > > > > > Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> > > > > > > for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
> > > > > > > though...
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > I guess the scan_index had nothing to do with this, but I suggested to set
> > > > > > scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
> > > > > > .channel being 1.
> > > > > >  
> > > > > > >  
> > > > > > > > When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > You can't change the trigger if the buffer is currently enabled. Make sure that
> > > > > > he buffer is disabled (check the buffer/enable attribute).
> > > > > >  
> > > > > > - Lars
> > > > > > u
> > > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > > > the body of a message to majordomo@vger.kernel.org (mailto:majordomo@vger.kernel.org)
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >  
> >  
>  

Re: IIO Drivers

[Jonathan Cameron]

On 02/27/2013 07:32 PM, Chris Micali wrote:
> Guys,  
> 
> Thanks a lot for the help!  I finally tracked down issues, it was a combination of a few things:
> 
> 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> 2. 1 or more scan_elements have to be enabled as you mentioned
> 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…)  (duh!)
> 3. The generic_buffer.c program had a few bugs in it causing crashes.  I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
> 
> So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
> 
If you do track down why this is happening, please do report back
so we can get it fixed.  I wasn't previously aware of any particular
issues in the example code so any feedback is helpful!

Looking foward to seeing the driver code when you are happy with it.

Jonathan
> Thanks!!
> 
> -chris
> 
> 
> On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
> 
>> On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
>>> On 02/27/2013 05:36 PM, Chris Micali wrote:
>>>> lars,  
>>>>  
>>>> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
>>  
>> Yea, you are right I missed the iio_triggered_buffer_setup part.
>>  
>>> Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
>>> for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
>>> though...
>>  
>>  
>>  
>> I guess the scan_index had nothing to do with this, but I suggested to set
>> scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
>> .channel being 1.
>>  
>>>  
>>>> When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
>>  
>> You can't change the trigger if the buffer is currently enabled. Make sure that
>> he buffer is disabled (check the buffer/enable attribute).
>>  
>> - Lars
>> u
> 
> 
> 

Re: IIO Drivers

[Chris Micali]

[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]

Jonathan,  

Thanks - I'll share back my findings this week.

One thing i've run into is throughput - it seems like the linux spi subsystem has a non-deterministic 50-150us delay before an spi_sync or spi_async command is processed.  I can't seem to find any way around this - so if i use larger multi-byte transfers using spi_async and DMA I get great, stable throughput, but that is broken up by these 50-150us delays between transfers (i'm using the beagle bone, so AM3359 that has a dedicated SPI controller and DMA.)   

Have any of you guys had success getting reliable >1MSPS throughput via IIO over SPI?  It seems like this inherent delay in the SPI subsystem would make this pretty difficult.

-chris


On Saturday, March 2, 2013 at 11:27 AM, Jonathan Cameron wrote:

> On 02/27/2013 07:32 PM, Chris Micali wrote:
> > Guys,  
> >  
> > Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
> >  
> > 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> > 2. 1 or more scan_elements have to be enabled as you mentioned
> > 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
> > 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
> >  
> > So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
> If you do track down why this is happening, please do report back
> so we can get it fixed. I wasn't previously aware of any particular
> issues in the example code so any feedback is helpful!
>  
> Looking foward to seeing the driver code when you are happy with it.
>  
> Jonathan
> > Thanks!!
> >  
> > -chris
> >  
> >  
> > On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
> >  
> > > On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > > > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > > > lars,  
> > > > >  
> > > > > I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> > > Yea, you are right I missed the iio_triggered_buffer_setup part.
> > >  
> > > > Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> > > > for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
> > > > though...
> > > >  
> > >  
> > >  
> > >  
> > >  
> > > I guess the scan_index had nothing to do with this, but I suggested to set
> > > scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
> > > .channel being 1.
> > >  
> > > >  
> > > > > When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
> > > >  
> > > >  
> > >  
> > >  
> > > You can't change the trigger if the buffer is currently enabled. Make sure that
> > > he buffer is disabled (check the buffer/enable attribute).
> > >  
> > > - Lars
> > > u
> > >  
> >  
> >  
>  
>  
>  



[-- Attachment #2: Type: text/html, Size: 5096 bytes --]

Re: IIO Drivers

[Lars-Peter Clausen]

On 03/04/2013 09:37 PM, Chris Micali wrote:
> Jonathan,  
> 
> Thanks - I'll share back my findings this week.
> 
> One thing i've run into is throughput - it seems like the linux spi subsystem has a non-deterministic 50-150us delay before an spi_sync or spi_async command is processed.  I can't seem to find any way around this - so if i use larger multi-byte transfers using spi_async and DMA I get great, stable throughput, but that is broken up by these 50-150us delays between transfers (i'm using the beagle bone, so AM3359 that has a dedicated SPI controller and DMA.)   
> 
> Have any of you guys had success getting reliable >1MSPS throughput via IIO over SPI?  It seems like this inherent delay in the SPI subsystem would make this pretty difficult.

No, not really, I think I never used more than 100kHz so far. Are you sure the
delay is really in the SPI subsystem and not just random interrupts kicking in?

I'm also curious did you implement your own IIO buffer, or are you just
starting a large SPI transfer which samples multiple samples at once?

- Lars

> 
> 
> On Saturday, March 2, 2013 at 11:27 AM, Jonathan Cameron wrote:
> 
>> On 02/27/2013 07:32 PM, Chris Micali wrote:
>>> Guys,  
>>>  
>>> Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
>>>  
>>> 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
>>> 2. 1 or more scan_elements have to be enabled as you mentioned
>>> 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
>>> 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
>>>  
>>> So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
>> If you do track down why this is happening, please do report back
>> so we can get it fixed. I wasn't previously aware of any particular
>> issues in the example code so any feedback is helpful!
>>  
>> Looking foward to seeing the driver code when you are happy with it.
>>  
>> Jonathan
>>> Thanks!!
>>>  
>>> -chris
>>>  
>>>  
>>> On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
>>>  
>>>> On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
>>>>> On 02/27/2013 05:36 PM, Chris Micali wrote:
>>>>>> lars,  
>>>>>>  
>>>>>> I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
>>>>>>  
>>>>>  
>>>>>  
>>>>  
>>>>  
>>>> Yea, you are right I missed the iio_triggered_buffer_setup part.
>>>>  
>>>>> Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
>>>>> for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
>>>>> though...
>>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>> I guess the scan_index had nothing to do with this, but I suggested to set
>>>> scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
>>>> .channel being 1.
>>>>  
>>>>>  
>>>>>> When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.  
>>>>>  
>>>>>  
>>>>  
>>>>  
>>>> You can't change the trigger if the buffer is currently enabled. Make sure that
>>>> he buffer is disabled (check the buffer/enable attribute).
>>>>  
>>>> - Lars
>>>> u
>>>>  
>>>  
>>>  
>>  
>>  
>>  
> 
> 
>