I use infrared sensors to detect my AGV number of turns the wheel, here is my program, the problem is I made ??a mark on the wheel design, the program will do the counting of the action, I want to control the wheels turn a few laps My program does not do, ask where there are problems, please tell me thank you. (The following program has an infrared sensing program forward and backward counting and AGV).
My program two inside while back how to write before they can read the number of wheel revolutions, I want the wheels turn forward it three times and then again three times.
1.program
const int PIRSensor = 2;
int val = 0;
void setup()
{
Serial.begin(9600);
pinMode(PIRSensor,INPUT);
pinMode(13,OUTPUT);
}
void loop(){
int i;
i = digitalRead(PIRSensor);
if(i == LOW){
digitalWrite(13,HIGH);
val += val + 1;
}
Serial.print(val);
delay(1000);
}
2.program
const int PIRSensor = 2;
int val = 0;
void setup()
{
pinMode(PIRSensor, INPUT);
pinMode(9, OUTPUT);
pinMode(11, OUTPUT);
pinMode(DAC0, OUTPUT);
pinMode(DAC1, OUTPUT);
}
void loop()
{
int t;
t = digitalRead(PIRSensor);
do {
digitalWrite(9, LOW);
analogWrite(DAC0, 110);
digitalWrite(11, LOW);
analogWrite(DAC1, 110);
}
[b]while[/b]?
do {
digitalWrite(9, HIGH);
analogWrite(DAC, 110);
digitalWrite(11, HIGH);
analogWrite(DAC1, 110);
}
[b] while[/b]?
So, val starts at 0. val + 1 is 1, so val is incremented by 1, to 1. Then, val + 1 is 2, so val is incremented by 2, to 3. Then, val + 1 is 4, so val is incremented by 4, to 7.
Is that what you want?
Reading the state of an encoder (homemade) once a second hardly seems like a good idea. GET RID OF THE STUPID DELAY!
You almost certainly do not want to be using do/while. You might want to use a while loop, but I doubt it. It isn't clear what you want to do in the while loop, or what the start or termination condition is.
Mmmm in C and it is C after all, all bar 40 years old it should no longer be undefined, but I tried the following code and got results that I did not expect .... will now go and .....
int i;
void setup() {
Serial.begin(9600);
// put your setup code here, to run once:
i=0;
Serial.print("i= ");
Serial.println(i);
i=0;
i++;
Serial.print("i= (will be 1) )");
Serial.println(i);
i=0;
i=i++;
Serial.print("i= (will be 1) ");
Serial.println(i);
i=0;
i+=i;
Serial.print("i= (should be 1) ");
Serial.println(i);
i=0;
i+=i+1;
Serial.print("i= (should be 2) ");
Serial.println(i);
}
void loop() {
// put your main code here, to run repeatedly:
}
results
i= 0
i= (will be 1) )1
i= (will be 1) 1
i= (should be 1) 0
i= (should be 2) 1
But as a rule of thumb for any language the rules are (in order of application)
holmes4:
Mmmm in C and it is C after all, all bar 40 years old it should no longer be undefined, but I tried the following code and got results that I did not expect .... will now go and .....
There are some incorrect assumptions there:
i=0;
i=i++;
Serial.print("i= (will be 1) ");
This is actually undefined behaviour since a variable may be modified only once per expression.
So your saying that the LHS of the = is evaluated before the RHS? IF so can you give a ref in the C/C++ standard or is this just a "side effect" or just the way gcc doe's it and therefore is as Nick puts it undefined? .
Given the size and detail of the C/C++ standard and the nit picking detail I just don't believe that anything is "undefinded".
holmes4:
So your saying that the LHS of the = is evaluated before the RHS?
No, I'm not saying that at all.
Which example are you referring to?
Given the size and detail of the C/C++ standard and the nit picking detail I just don't believe that anything is "undefinded".
The C++ standard states that a variable shall be modified only once between sequence points.
"i = i++;" is modifying the variable twice. The standard does not allow for this to happen. So any compiler that allows this and doesn't throw an error is by definition implementing "undefined behaviour".
gcc is even nice enough to warn you about it, if you enable all warnings:
$ g++ -W -Wall -pedantic var.cpp
var.cpp: In function ‘int main()’:
var.cpp:7:12: warning: operation on ‘i’ may be undefined [-Wsequence-point]
holmes4:
Given the size and detail of the C/C++ standard and the nit picking detail I just don't believe that anything is "undefinded".
Things are indeed undefined in the standard, in order to allow compiler-writers the latitude to improve execution speed. For example:
i = i++ + i++;
That could have all sorts of results, and if the result was not simply "undefined" you might have to put in slower code to make sure it was defined and gave a predictable result.
To be this is not undefined, the rule are there , uniary op's first (eg ++) then binary ops eg + and () overrides all else this along with left to right (is equal priority) always resolves the RHS.
What I seem to have wrong is = as in (complex LHS = (rhs)) but assuming I'm wrong in saying that the LHS is done before the RHS but that the left to right rule applies because the = is the highest priority operator then it explains the results of my little program and nothing is "undefined"
But it's not a unary arithmetic op; it's a full expression that modifies the variable. Furthermore "i++" is POST-increment, so it's specifically defined to do the increment LATER. An unary op would be like "-i" does not modify the variable, so the "unary first" rule works fine.
For more fun, consider what would be different, based on your rules, between:
holmes4:
To be this is not undefined, the rule are there , uniary op's first (eg ++) then binary ops eg + and () overrides all else this along with left to right (is equal priority) always resolves the RHS.
Nope, sorry, both "i = i++..." and "i++ + ++i" are expressly prohibited by the standard and thus any usage of it is completely undefined. The compilers can do whatever they want with that, format your hard drive, call your mother-in-law, or whatever.
It's at your own peril to use undefined behaviour and there is really no good reason to do so.
