2. Check that the sensor is present in the I2C Bus by including the following lines at the appropriate place of the sketch:
Wire.beginTransmission(7);
byte busStatus = Wire.endTransmission();
if(busStatus !=0)
{
Serial.print("Sensor is not found...!");
while(1); //wait for ever
}
Serial.print("Sensor is present.");
3. Read 2-byte data from the sensor by by including the following lines at the appropriate place of the sketch.
Wire.requestFrom(7, 2);
int SLPM = ((Wire.read()<<8)|Wire.read())/1000; //edit:
4. Show the valueof SLPM on Serial Monitor by including the following lines at the appropriate place of the sketch.
GolamMostafa:
The OP has already given the computation formula.
... But not the protocol for retrieving data from the "sensor". Do you need to trigger a "sense" operation before retrieving the data? Does the sensor provide multiple reading types? Do you need to send a register address first? Does it support the "repeated start" convention? Does it support auto-increment to read multiple registers per I2C transaction? Does it support 100 KHz clock rate or higher?
Bottom line -- a good engineer would never say "this is how you do it" without first reading the datasheet.
1.... But not the protocol for retrieving data from the "sensor".
It is given -- the I2C Bus.
2. Do you need to trigger a "sense" operation before retrieving the data?
The question is not well understood.
3. Does the sensor provide multiple reading types?
Yes! The sensor sends 2-byte data with MSByte first.
4. Do you need to send a register address first?
The question would raise if the given tentative approach does not give rational result.
5. Does it support the "repeated start" convention?
The sensor is a passive I2C device having (probably) no processor. It is also probable that the I2C Bus does not contain any other processor that can attempt to acquire the Bus and thus interrupts the data transaction between the I2C Master and sensor.
6. Does it support auto-increment to read multiple registers per I2C transaction?
In general, all passive I2C sensors/devices support auto-increment.
7. Does it support 100 KHz clock rate or higher?
This is the standard I2C speed.
8. Bottom line -- a good engineer would never say "this is how you do it" without first reading the datasheet.
Paraphrase: a good engineer would say "this is how you should try it taking utmost care for the safety of yourself and major equipments" when all other advices/efforts seem to be not helping/working.
GolamMostafa: 3. Read 2-byte data from the sensor by by including the following lines at the appropriate place of the sketch.
Wire.requestFrom(7, 2);
int SLPM = ((Wire.read<<8)|Wire.read)/1000;
That’s not how you read two bytes (MSB then LSB).
First, it’s Wire.read(), not Wire.read. The latter takes the address of the Wire.read function.
Second, the compiler doesn’t guarantee any order of evaluation of the functions in that expression. The compiler is free to call the two Wire.read()s in either order. If the compiler chooses the “wrong” order (the one the programmer doesn’t “expect”), then the second Wire.read() is called first and the first one second, which effectively treats the first byte as the LSB and the second byte as the MSB. You need to call Wire.read() in two separate statements (separated by sequence points). Try something like this:
Wire.requestFrom(7, 2);
int SLPM = Wire.read()<<8; // MSB
SLPM |= Wire.read(); // LSB
float f = SLPM / 1000.0; // preserve the fractional part
christop:
The compiler is free to call the two Wire.read()s in either order. If the compiler chooses the "wrong" order (the one the programmer doesn't "expect"), then the second Wire.read() is called first and the first one second, which effectively treats the first byte as the LSB and the second byte as the MSB. You need to call Wire.read() in two separate statements (separated by sequence points). Try something like this:
Is the evaluation not from left to right? This document of Microsoft says that "Precedence and associativity" of Bitwise-inclusive-OR (|) operator is from 'left to right'. I believe that the Compiler writers adhere to this rule.
Nope, associativity and order of evaluation are two separate issues. Associativity is how the result is computed by the operators (left-to-right or right-to-left). Order of evaluation is the order in which subexpressions are evaluated. The two are not necessarily the same. A compiler must adhere to the associativity rules but there are no rules for order of evaluation (the order of evaluation is unspecified).
