On Sun, Nov 1, 2009 at 3:27 AM, Neil Jerram <neiljer...@googlemail.com> wrote: > 2009/11/1 Nelson Castillo <arhu...@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 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community