So, I am trying to add elements to my (working) code and decided to test them standalone before adding them in.
I want to have a simple toggle high, toggle low, that will eventually toggle one led high when the other goes low and vice versa. I digress.
I started trying to write my own code using my dummies book, and two sample sketches. It wasn't going well.
So I went to youtube to get a working tutorial and went to town.
Below is the code.
const int buttonPin = 14; // the number of the pushbutton pin
const int ledPin = 9; // the number of the LED pin
// Variables will change:
int ledState = -1; // the current state of the output pin
int buttonState = LOW; // the current reading from the input pin
int lastButtonState = LOW; // the previous reading from the input pin
// the following variables are long's because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long lastDebounceTime = 0; // the last time the output pin was toggled
long debounceDelay = 250; // the debounce time; increase if the output flickers
void setup() {
pinMode(buttonPin, INPUT);
pinMode(ledPin, OUTPUT);
// set initial LED state
digitalWrite(ledPin, ledState);
}
void loop() {
buttonState = digitalRead(buttonPin);
if( (millis() - lastDebounceTime) > debounceDelay) {
if ( (buttonState == HIGH) && (ledState < 0) ){
digitalWrite(ledPin,HIGH);
ledState = -ledState;
lastDebounceTime = millis();
}
else if( (buttonState == HIGH) && (ledState > 0) ){
digitalWrite(ledPin,LOW);
ledState = -ledState;
lastDebounceTime = millis();
}
}
}
It works, except there is a blinking action if I hold the pushbutton down.
Did I do something wrong or is there a different way of writing the code?
I'm thinking there's a simple "something" that can be added to make the soggle not go to the next state unless the pushbutton goes low again first.
Did I do something wrong or is there a different way of writing the code?
Yes and yes.
The problem is that it is doing exactly what you wrote. When posting code it is important to say what you want it to do.
To stop it doing things until the button is released then you can use:-
JimboZA:
True, but being smart should mean you aren't a dummy. I think that's the point cjd was making.
Well, let me tell you... The "dummies" books aren't written for true dummies. Well, at least not this one. It's a book that talks down to the average reader using far too much programmer lingo.
Imagine me telling someone how to measure their house using points, picas, mutts and nutts. (I'll give you a hint, it's printing lingo)
JimboZA:
True, but being smart should mean you aren't a dummy. I think that's the point cjd was making.
Well, let me tell you... The "dummies" books aren't written for true dummies. Well, at least not this one. It's a book that talks down to the average reader using far too much programmer lingo.
Imagine me telling someone how to measure their house using points, picas, mutts and nutts. (I'll give you a hint, it's printing lingo)
I found it funny a self confessed genius reading dummies books, no insult intended.
Either increase the debounce delay, or while button state is high, do nothing like mike said but is it really that much of an issue?
cjdelphi:
I found it funny a self confessed genius reading dummies books, no insult intended.
Either increase the debounce delay, or while button state is high, do nothing like mike said but is it really that much of an issue?
As Sheldon Cooper would say... "They had me tested."
I'm not self confessed. 8)
Yes, it is that much of an issue because I have a lot more going on than just a single switch. I will try to work in Mike's suggestion. I figured there was something like that to put in there but couldn't get it through the gray matter.
Thank you, but no hint needed, I know what those are. And although they have a printing connotation, they are at the end of the day, just more units of measure.. I'm an engineer, and units of measure are things that engineers deal with all the time, including conversion between systems. So as long as I can look up somewhere that there are X Y's in a Z, (eg 72 points in an inch) then I can quite happily convert between Ys and Zs or Zs and Ys. No magic there.
Now, if I didn't know how to measure in the first place, perhaps having no concept of quantity of length, that would be a different discussion.
Well, for some... and by some I mean the general population, the idea of programming code might as well be written in a lost language.
As i've said before. I had to learn so much in my life. Much more than the average Joe. Although, to you, programming language comes easy, imagine that you now have to learn German (if you don't know German already).
I'm learning the language. The logic is somewhat simple to grasp.
On a different note. I discovered a simple solution to a problem that's been dogging me. The pinouts on my Arduino (maybe all) are sometimes tricky to handle. When I first turn on the board it sometimes sets a pin high.It appears that the upload triggers that pin the same as it does 13. Though it wouldn't be an issue in my real world application, it's frustrating.
I think part of why I'm having a difficult time is because the code reads somewhat like Excel code. I spent a great deal of time learning and using Excel (and Access with SQL components) and my mind is trying to validate statements using existing knowledge and translating it into Arduino code.
Whereas Excel uses cells and qualifiers, Arduino seems to use other references and brackets.
It's a matter of time and patience but I should get it over time. (especially with help from the great tutors in these forums)
the idea of programming code might as well be written in a lost language.
I have held the view for decades, that teaching of programming languages often gets it back asswards. When I learned Fortran exactly 40 years ago when I was a 1st year student here in 1974, we started with flowcharts. Get down on paper exactly what it is you want to do. Later when I learned Cobol, they used structure charts- different from flowcharts, but same idea: get your mind round what it is you're trying to do before you think of the code. Only once the thoughts are clear, do you hit the code.
Coding without a design is like building a house with no plans.... you might get to the roof and think shit, if we make the roof out of these heavy slates the whole thing's going to collapse. Never mind, we'll just unbuild the last week's work and make stronger trusses.
The coding is relatively straight forward once you have the plan in place.....
I think nowadays, the teaching goes into the syntax and rules and grammar and crap too early: fine if you're a seasoned user of another language, and know about the thought process.
I couldn't agree more.
I know what I want to do but am still learning the processes.
I can't very well learn the entirety of my needed code while trying to build my first complete project (10 inputs and 34 outputs, all with steady, random, and I/O results).
So I'm building it like I built my house. First I did the blueprint, then I did the layout on the ground. But while I was waiting for the foundation to be poured, I went shopping for tile and appliances.
My success is being able to take things in a different direction when I'm "hung up" to maximize timeframe efficiency. This means that linear (learning) processes sometimes get in the way.
JimboZA:
Get down on paper exactly what it is you want to do. (..) get your mind round what it is you're trying to do before you think of the code. Only once the thoughts are clear, do you hit the code.
I vote we put this in a sticky topic or faq! As a seasoned programmer, i agree so much with this. I think a lot of beginners could benefit from a little planning ahead.
JimboZA:
Get down on paper exactly what it is you want to do. (..) get your mind round what it is you're trying to do before you think of the code. Only once the thoughts are clear, do you hit the code.
I vote we put this in a sticky topic or faq! As a seasoned programmer, i agree so much with this. I think a lot of beginners could benefit from a little planning ahead.
Flavour of the month on the forum right now, is state machines. I guess especially in physical computing, as we have here, state machines could be used almost all the time, so maybe the approach should be to encourage folk to plan things out in states. But whatever the tool, a bit of up-front thinking never hurt.
EDIT: Instead of asking for code and circuits, we'll soon be asking for design docs before offering to help. 8) Where's the URS?
Believe it or don't, I do have a plan all diagrammed out. I have two excel spreadsheets that are for the sole purpose of explaining the relationship between each input and each output.
And I have another (with multiple sheets) I I use to assemble repetitive code (and it will be refined once I get the clunky code to work).
I use Excel because I'm familiar with it and can assemble strings pretty easy. I can also do search and replace if I need to and, combining it with notepad (as a text editor) and using import functions, I can get stuff done in half the time, when those tools can be used.
So, as I learn the nuances of the code, I place them in a few test sketches. Once I'm done I will build it all together.