1st field (69-68) is the value from sensor
2nd field is the loop amount
3rd field is the total result (adding all the results together)
WHY is the total amount suddenly going negative at loop number 1422???
PLease can someone explain i tried this on an uno and leonardo same result.
int i;
void setup() {
Serial.begin(115200); // put your setup code here, to run once:
int tot;
for (i=0;i<1500;i++){ // begin loop
int CO_pin = analogRead(0);
Serial.print(CO_pin);
tot += CO_pin;
Serial.print("<--> ");
Serial.print(i);
Serial.print("<--> ");
Serial.println(tot);
delay(100);
} //einde loop
tot = tot/1500;
Serial.println(tot);
} // einde setup
void loop() {
}
@track
tot = basicly values 40-100 depending what value come from sensor.
so it starts with 0 and just add up all the (values from sensor) 68+68+69+65 etc
I just noticed as soon as the addition of the numbers come to around 327xx it goes nagative and start adding numbers to the negative value as seen in above output.
can you describe a standard way for a loop? imo the way i did it is pretty standard, but please correct me if im wrong.
without declaring tot i get an error while compiling.
We're trying to help him learn by working it out as it's a fundamental error.
@OP, as AWOL hinted, what is the range of values a 16 bit int can hold? Next, consider the maximum value you will be assigning to it with your 1500 additions.
Awesum !!!
That long int solved my problem
must do some more reading on 16bit and range value
Thank you guys
UPDATE:
i did some reading
On the Arduino Uno (and other ATMega based boards) an int stores a 16-bit (2-byte) value. This yields a range of -32,768 to 32,767 (minimum value of -2^15 and a maximum value of (2^15) - 1).
malawi:
Awesum !!!
That long int solved my problem
Thank you guys
But what have you learnt by being given the (wrong) answer?
We were trying to help you learn the fundamentals of variable type appropriate to what you wish to assign to it.
In this case the answer is not a 'long', although it does fix your issue it is actually overkill. You are now using a 32 bit variable where a 16 bit one would be sufficient, and hence using 2 more bytes of that precious 2kB of SRAM that isn't required.
BareMetal has not helped you with that answer really.
But you don't need long int, as has been mentioned.
What range of numbers can an int hold ?
HINT - part of the range is negative. Do you need negative numbers ?
If only you did not need to take negative numbers into account then maybe an int could hold a larger number.
If only that negative sign was not there and all the numbers were positive an int could hold a number twice as big maybe.
@UKHeliBob
i see, so i am using only half of int when i dont use negative numbers.
so how would i describe an int with no negatives? or is that not possible?
But you don't need long int, as has been mentioned
Chaps, yes, you almost certainly do - 1500 readings of any analogRead over 43 is going to require 32 bits.
True. I was just looking at his quoted example of the rollover at 1420, but actually it would appear that is his second rollover!
So BareMetal was right on the long type. My apology there. One of the downsides to being on a phone and just using the info presented without checking personally.
It would still help malawi to think about the original question and it's aim to consider the right type for application, and whether he requires negative values.
Understanding each data type and it's value range is useful basic understanding.
16 bit "int" range -32768 to 32767
16 bit "unsigned int" range 0 to 65535.
There are no 24 bit datatypes.
An analogRead cannot return a negative number, so using an unsigned value is pointless, so if your analogRead averages over 43, you're going to need a 32 bit datatype.
There's also nothing wrong with the declaration of your loop counter variable.
BareMetal:
Sorry for the overkill, peeps, I was shooting from the hip
Apology is mine. You were right, although unsigned long would be more appropriate. I only looked at the data posted and a rollover at 1420 loops, but he must have had another rollover earlier already as the total should have been about 96000 odd.
My train of thought was unsigned int due to that and only seeming like 80 more loops required.
No apology required. Uint would have been better learning...we are all here to help each other out, and/ or amuse! Nice to meet u. The guy got sorted, thats what matters.
One small change will fix it.
