Understanding accelerometer data

[Nelson Castillo]

On Sun, Nov 1, 2009 at 3:27 AM, Neil Jerram <neiljerram at googlemail.com> wrote:
> 2009/11/1 Nelson Castillo <arhuaco at freaks-unidos.net>:
>>
>> Here I print a direction vector (ignoring Z).
>> It goes from 0 to 100 (instead of 0.0 to 1.0) to avoid floating point.
>> It updates rather fast.
>>
>> http://svn.arhuaco.org/svn/src/openmoko/accelerometers/dir.c
>>
>> If I only care about this vector I think I'll use a thread to keep
>> reading from the accels.
>
> Fine, but have you measured what the CPU cost of that is?

No. I wouldn't care much about reading 1600bytes/second in the FR from
kernel buffers in a C program.
read_all uses blocking reads anyway. I mean: no busy waiting here and
if I use threads I don't need to use locking for the accel data.

>> I tried something (very fast, not polished) in Python but i feel the
>> program lags reading the accels.
>
> Does Python's read have any internal buffering (by default)?  In Guile
> (which does) that was the cause of the lag that I saw; and when I
> added a call to set the buffer size to just sizeof(struct
> input_event), the lag disappeared.

I remember that some time ago I wrote a module to check this and
Python attempted a read of 32K in my PC! No matter how many bytes I
was trying to read. This could be the cause if you are already
experienced this.

In this weblog post I just read that we have to use non-blocking I/O
to avoid this problem.

http://bec-systems.com/site/259/how-to-optimize-python-reads-for-general-data