I am not sure how to explain what I am trying to do. So here it goes. I want to return a value and have the returned value print to serial monitor from void loop. I am going to post my code as I am sure the master programmers will get what I am trying to do. Thank you in advance.
int val;
int encoderDT = 2; //dt
int encoderCLK = 3;//clk
int encoderPos = 0;
int encoderPinALast = LOW;
int n = LOW;
void setup()
{
pinMode (encoderDT,INPUT);
pinMode (encoderCLK,INPUT);
Serial.begin (9600);
}
void loop()
{
Serial.print (tempo);
Serial.print ("/");
}
int tempo(int encoderPos)
{
n = digitalRead(encoderDT);
if ((encoderPinALast == LOW) && (n == HIGH))
{
if (digitalRead(encoderCLK) == LOW)
{
encoderPos++;
}
else
{
encoderPos--;
}
return (encoderPos);
}
encoderPinALast = n;
}
Well I am getting closer,,, a bit more modified code and now it counts , but still continuous . It went up to the thousands before I closed the serial monitor. Here is my new code…
int val;
int encoderDT = 2; //dt
int encoderCLK = 3;//clk
int encoderPos = 0;
int encoderPinALast = LOW;
int n = LOW;
void setup()
{
pinMode (encoderDT,INPUT);
pinMode (encoderCLK,INPUT);
Serial.begin (9600);
}
void loop()
{
Serial.print (tempo(encoderPos));
Serial.print ("/");
}
int tempo(int)
{
n = digitalRead(encoderDT);
if ((encoderPinALast == LOW) && (n == HIGH))
{
if (digitalRead(encoderCLK) == LOW)
{
encoderPos++;
}
else
{
encoderPos--;
}
return (encoderPos);
}
encoderPinALast = n;
}
sensai:
Well I am getting closer,,, a bit more modified code and now it counts , but still continuous . It went up to the thousands before I closed the serial monitor.
Super long lines jam serial monitor up for me.
How about only printing changes?
The tempo function only has a return if ((encoderPinALast == LOW) && (n == HIGH))
Exiting without a return should give you garbage.
That tempo() code should not be in a function.
int tempo(int)
{
n = digitalRead(encoderDT);
if ((encoderPinALast == LOW) && (n == HIGH))
{
if (digitalRead(encoderCLK) == LOW)
{
encoderPos++;
}
else
{
encoderPos--;
}
return (encoderPos);
}
encoderPinALast = n;
}
GoForSmoke, are you saying I should leave the code in void loop() ? Then work with it from there?
Sorry you replied moments before I posted the above reply.
I'm just back up and no caffeine but that's kind of the gist of how I felt when I posted.
Either way, that function code is more confusing than not as to what it's supposed to be doing.
The obvious error of exiting without a return is just a clue.
Often it helps to add "debug prints" when you don't have IDE watch windows and step tracing.
Just print symbols and spaces to show what branches the code actually takes and key values at those points or where knowing them tells you what's going on. The dynamic can often be different than what we imagine.
GoForSmoke:
I'm just back up and no caffeine but that's kind of the gist of how I felt when I posted.
Either way, that function code is more confusing than not as to what it's supposed to be doing.
The obvious error of exiting without a return is just a clue.
Often it helps to add "debug prints" when you don't have IDE watch windows and step tracing.
Just print symbols and spaces to show what branches the code actually takes and key values at those points or where knowing them tells you what's going on. The dynamic can often be different than what we imagine.
At the very top of your program, after any #include directives, type in:
#define DEBUG
Now change your tempo() function to:
int tempo(int)
{
n = digitalRead(encoderDT);
if ((encoderPinALast == LOW) && (n == HIGH))
{
if (digitalRead(encoderCLK) == LOW)
{
encoderPos++;
}
else
{
encoderPos--;
}
}
#ifdef DEBUG
Serial.print("At bottom of tempo(): n = ");
Serial.print(n);
Serial.print(" encoderPos = ");
Serial.println(encoderPos);
#endif
encoderPinALast = n;
return (encoderPos);
}
Because you have defined DEBUG, the Serial.print() statements are compiled into the program and you can watch the output on your serial monitor. If you comment out the #define DEBUG line, the Serial.print() statements are no longer compiled into the program. This allows you to leave the debug statements in the source file, but they do not become part of the final executable file.
For me a debug print on Arduino is any print to serial monitor that's to show what my code is doing.
But the #ifdef technique is nice and clean and better.
It's just that I had some kind of problems with one of the #ifdef type lines when I was running 0022 and haven't gone back to them since so I just comment out debug prints when I want to use them.
Thanks for the replies, I appreciate the good knowledge I soaked up through this, especially debug.
I revamped my code now, and it works , though a little slow on the numerical change. I will get to that.
Here is the new updated code.
int eDT = 2;
int eCLK = 3;
int coderPos = 0;
int lastDT = LOW;
int updateDT = LOW;
void setup()
{
pinMode (eDT,INPUT);
pinMode (eCLK, INPUT);
Serial.begin (9600);
}
void loop()
{
setTempo();
}
void setTempo()
{
updateDT = digitalRead(eDT);
if (( lastDT == LOW) && (updateDT == HIGH))
{
if (digitalRead(eCLK) == LOW)
{
coderPos ++;
}
else
{
coderPos -- ;
}
int tempo =(1000/ coderPos)*60;
Serial.print(" BPM");
Serial.print(tempo);
}
lastDT = updateDT;
}
I have no idea what the pins are reading of what values coderPos can reach. Are negatives okay?
You don't have to answer, but it's a consideration. An int is good for -32768 to 32767.
int tempo =(1000/ coderPos)*60;
would be more accurate as
long tempo =( 60000L / (long) coderPos ); // it will fit in a long, be sure!
Yes negatives will work as well,
Thanks GoForSmoke, I didnt even think of running out of range with, int. LOL. Nice catch.
The switch on the rotary encoder will cycle through a series of options, while the encoder itself, will vary choices inside the options. Negatives will work in some places for returning back through the options.
You sound like you're doing okay and can find your way now.
I have never messed with rotary encoders, neat as they seem. The relations you work with there, I haven't figured out.
In all code it's best to either check all bounds or design to stay within them. Also cover every logical possibility and write error code that at least notifies the user. I have written lines into programs that spell out "This should not have happened, notify the programmer!". Don't just go for watertight, go for airtight. May your code run for years on end without a hiccup or bug, but don't count on it or Murphy will get you!
LOL evil Murphy… lol. Thanks again. I think I got it sorted, my encoder counts up and downwards now, on rotation, so I can apply the values to a switch/break case, and take it from there. tx again.