Skip to contentSkip to conversation

Buffer chrdev API and test

DISCUSSION Maxime Ripard 2 participants 3 messages Nov 30, 2011 – Dec 8, 2011 IIO

lore
Share & tools
lore

Maxime Ripard

author
#0 lore raw

Hi list,

I'm currently trying to test the buffer output, using the chrdev present at /dev/iio:deviceN.

So I looked into the generic_buffer.c file which seems to do exactly that.

By looking into the source code, my understanding is that samples are stored with this frame format :

+--bpe--+--...--+--bpe--+--64 bits--+
| Ch 0  | ..... | Ch N  | timestamp |
+-------+-------+-------+-----------+

the overall "frame" size being stored in /sys/..../buffer/bytes_per_datum.

Now, when I execute generic-buffer, it sets up correctly the driver by enabling the channels, the buffer, setting the trigger, etc, but outputs nothing at all. After some number of trigger firing, it finally exits, having displayed nothing but

# /root/generic-buffer -n at91_adc -t at91_adc-dev0-external
iio device number being used is 0
iio trigger number being used is 3
/sys/bus/iio/devices/iio:device0 at91_adc-dev0-external
#

which seems pretty odd to me.

But when I do a cat directly on /dev/iio:device0, I get some binary data, which indicates that the buffer is filled anyway.

So, is generic_buffer supposed to print something ? If so, what kind of output should I expect ?
Or is it just a poor driver configuration/data storing from me ?

Thanks,
Maxime

Signature · 4 lines
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#1 lore raw
Quoted 31 lines · Maxime Ripard

Hi list,

I'm currently trying to test the buffer output, using the chrdev present
at /dev/iio:deviceN.

So I looked into the generic_buffer.c file which seems to do exactly that.

By looking into the source code, my understanding is that samples are stored with this frame format :

+--bpe--+--...--+--bpe--+--64 bits--+
| Ch 0  | ..... | Ch N  | timestamp |
+-------+-------+-------+-----------+

the overall "frame" size being stored in
/sys/..../buffer/bytes_per_datum.

Now, when I execute generic-buffer, it sets up correctly the driver by enabling the channels, the buffer, setting the trigger, etc, but outputs
nothing at all. After some number of trigger firing, it finally exits, having displayed nothing but

# /root/generic-buffer -n at91_adc -t at91_adc-dev0-external
iio device number being used is 0
iio trigger number being used is 3
/sys/bus/iio/devices/iio:device0 at91_adc-dev0-external
#
Quoted 8 lines

which seems pretty odd to me.

But when I do a cat directly on /dev/iio:device0, I get some binary data, which indicates that the buffer is filled anyway.

So, is generic_buffer supposed to print something ? If so, what kind of output should I expect ?
Or is it just a poor driver configuration/data storing from me ?

Probably something about the data format that it doesn't understand. It is pretty dumb so I would guess you are hitting something it doesn't know about yet.

Quoted 13 lines

Thanks,
Maxime

Signature · 8 lines
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Sent from my Android phone 
with K-9 Mail. Please excuse my brevity.
author
#2 lore raw

Hi,

Just an update to that, in case anyone fall into the same sort of thing. I actually lacked the fix you sent for the fscanf on the output of bytes_per_datum in the iioutils_get_type function.

Maxime

Quoted 57 lines · Jonathan Cameron
Quoted 31 lines · Maxime Ripard

Hi list,

I'm currently trying to test the buffer output, using the chrdev present
at /dev/iio:deviceN.

So I looked into the generic_buffer.c file which seems to do exactly that.

By looking into the source code, my understanding is that samples are stored with this frame format :

+--bpe--+--...--+--bpe--+--64 bits--+
| Ch 0  | ..... | Ch N  | timestamp |
+-------+-------+-------+-----------+

the overall "frame" size being stored in
/sys/..../buffer/bytes_per_datum.

Now, when I execute generic-buffer, it sets up correctly the driver by enabling the channels, the buffer, setting the trigger, etc, but outputs
nothing at all. After some number of trigger firing, it finally exits, having displayed nothing but

# /root/generic-buffer -n at91_adc -t at91_adc-dev0-external
iio device number being used is 0
iio trigger number being used is 3
/sys/bus/iio/devices/iio:device0 at91_adc-dev0-external
#
Quoted 8 lines

which seems pretty odd to me.

But when I do a cat directly on /dev/iio:device0, I get some binary data, which indicates that the buffer is filled anyway.

So, is generic_buffer supposed to print something ? If so, what kind of output should I expect ?
Or is it just a poor driver configuration/data storing from me ?

Probably something about the data format that it doesn't understand. It is pretty dumb so I would guess you are hitting something it doesn't know about yet.

Quoted 13 lines

Thanks,
Maxime

Signature · 8 lines
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com