accelerometer code

re: the code given for use of the accelerometer, Memsic 2125 , at http://arduino.cc/en/Tutorial/Memsic2125?from=Tutorial.AccelerometerMemsic2125
re: these lines
pulseX = pulseIn(xPin,HIGH);
pulseY = pulseIn(yPin,HIGH);

reference:
{Description of pulseIn()
Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH, starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds. Gives up and returns 0 if no pulse starts within a specified time out.
The timing of this function has been determined empirically and will probably show errors in longer pulses. Works on pulses from 10 microseconds to 3 minutes in length. } end description

Does this code handle the case when pulse X in one axis and pulse Y in another, overlap. That is, does the code pulseX = pulseIn(xPin,HIGH);
pause the CPU until xPin goes HIGH ? Or is the CPU still waiting for xPin to go HIGH while it simultaneously begins to execute the next line re pulseY ? If yes then what happens when the CPU returns thru the loop and tries to execute the same two lines of code that are already still waiting ?

This code?

/*
   Memsic2125
   
   Read the Memsic 2125 two-axis accelerometer.  Converts the
   pulses output by the 2125 into milli-g's (1/1000 of earth's
   gravity) and prints them over the serial connection to the
   computer.
   
   The circuit:
    * X output of accelerometer to digital pin 2
    * Y output of accelerometer to digital pin 3
    * +V of accelerometer to +5V
    * GND of accelerometer to ground
 
   http://www.arduino.cc/en/Tutorial/Memsic2125
   
   created 6 Nov 2008
   by David A. Mellis
   modified 30 Aug 2011
   by Tom Igoe
   
   This example code is in the public domain.

 */

// these constants won't change:
const int xPin = 2;     // X output of the accelerometer
const int yPin = 3;     // Y output of the accelerometer

void setup() {
  // initialize serial communications:
  Serial.begin(9600);
  // initialize the pins connected to the accelerometer
  // as inputs:
  pinMode(xPin, INPUT);
  pinMode(yPin, INPUT);
}

void loop() {
  // variables to read the pulse widths:
  int pulseX, pulseY;
  // variables to contain the resulting accelerations
  int accelerationX, accelerationY;
 
  // read pulse from x- and y-axes:
  pulseX = pulseIn(xPin,HIGH);  
  pulseY = pulseIn(yPin,HIGH);
 
  // convert the pulse width into acceleration
  // accelerationX and accelerationY are in milli-g's:
  // earth's gravity is 1000 milli-g's, or 1g.
  accelerationX = ((pulseX / 10) - 500) * 8;
  accelerationY = ((pulseY / 10) - 500) * 8;

  // print the acceleration
  Serial.print(accelerationX);
  // print a tab character:
  Serial.print("\t");
  Serial.print(accelerationY);
  Serial.println();

  delay(100);
}

That is, does the code pulseX = pulseIn(xPin,HIGH); pause the CPU until xPin goes HIGH ?

pulseIn is blocking, yes. It doesn't pause the CPU exactly, but the code doesn't return until the condition is met.

Nicks correct. If you want to deal with 2 pulses that may over lap than you need to use interrupts.

Mark

Does that mean that the pulse in the y axis is ignored until the x has gone high ?
Then if the accelerometer only moved in the y axis, the output would be 0 since the CPU is waiting for the x axis high.
I am trying to record the tremor of a human being. Put the instrument on the index finger. We do not know the sequence of planes the finger will move in. Likely every motion will be in multiple planes. How much data are we losing due to pulseIn blocking ? Maybe little since the likelihood of a pure x or y axis motion is low.

Thanks for the help

As suggested above, I suggest you use interrupts.

Thanks

jad1715,
The duty cycle on that chip is about 100 milliseconds. Since you only need to measure the HIGH state, you have a worst-case blocking time of just under 100 ms. That time would represent about a 3 G acceleration. I wonder what the G force of a worst case finger tremor is. It might be worthwhile doing some testing to see whatthe worst-case tremor would produce, and what sort of time is involved. If it turns out to be, say, 5 to 40 milliseconds or so, perhaps it would be sufficient to read the pins sequentially.

The duty cycle on that chip is about 100 milliseconds.

Duty cycle would seem to me to be the wrong term (normally a ratio or percentage), but a 100 millisecond period would make it tough to achieve the claimed 100 Hz update rate.

AWOL:

The duty cycle on that chip is about 100 milliseconds.

Duty cycle would seem to me to be the wrong term (normally a ratio or percentage), but a 100 millisecond period would make it tough to achieve the claimed 100 Hz update rate.

Yes, the total period is 100 ms, and the nominal at-rest HIGH is 5000 microseconds. The update rate is 10 Hz, not 100 Hz.

That being said, I realize now that, since we do not determine the start of the HIGH pulse in our code, but that it free runs from the sensor, the latency would likely average somewhere near 50 ms, and interrupts are probably the best way to proceed.

Yes, the total period is 100 ms, and the nominal at-rest HIGH is 5000 microseconds.

Have you confused your "mu"s (micros) with your "m"s (millis)?

AWOL:

Yes, the total period is 100 ms, and the nominal at-rest HIGH is 5000 microseconds.

Have you confused your "mu"s (micros) with your "m"s (millis)?

Welll I didn't. The article I read did. Of course, I should have known, because the 5000 usec nominal at-rest pulse logically shoulle be half the total cycle time in order to get an equal swing on each side on it. I found a better source of info.

So, to correct it all... the total cycle time is 10 ms, and the nominal centre at-rest is 5 ms. (more if it's ariented to sense normal gravity).