Still haven't showed the sketch. Sigh
Only works if I do
Serial.begin(9600);
delay(1500);
The while(!Serial) does not remove the square characters ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”
!Serial will always return false, unless you have a board with native USB.
Try increasing the delay, instead.
What part of "show us setup(), please." Was unintelligible? It's not that hard. Snippets are the fastest route to confusion.
So far only a delay of about 1100 ms seem to work. Even 1sec prints some ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā”ā” . Wonder why??
Perhaps we're on ignore. I'll do the similar thing, Tracking -> Normal
The sketch is the 1st post.
The sketch is in the 1st post.
No it's not, unless you hid all Serial. lines??
With neither
while (!Serial);
nor
delay(1000);
We just wanna be sure you can follow the tips correctly. Saying "I did that and it didn't work." leaves us wondering did what? Did not work how?
We aren't there. You needa be eyes and ears, and post code that you've changed, not directions for us to change it like you did. That is fraught.
a7
But you're asking about printing with Serial.begin(), and that command is not included in your post #1 sketch.
void setup() {
Serial.begin(9600);
while(!Serial) {}
delay(1100);
}
Thank you. Now we can all be sure we're all on the same page.
If this is an Uno as depicted, you can lose the while(). But my Uno clone needed no delay to print reliably, so something is different.
Maybe when the setup() delay is over you could empty the buffer without printing any of the chars?
Uno's have given me junk chars on startup.
IIRC the while (!Serial) was introduced with USB/AVR boards Leonardo and Micro.
What I still don't get is how return (btnState == 0xFFF0); returns true in bool debounce(void). Could you explain??
- 0 (zero) is false, non-zero is true
- Above says is btnState equal to 0xFFF0 if it is equal, it is true so return true, otherwise false is returned.
- BTW, sampling a switch connected to an input every 20 to 50ms is all the de-bouncing necessary in most situations.
Always (99.9% of the time) look at an input change in state when handling switches and the like.
That's what I don't get: how does btnState become equal to 0xFFF0??
This was explained in Comment #4: