Beginners - Solving project problems (yes - you too!)

UPDATED: added rules & detail

It’s very common to see beginners trying to develop a complete hardware + software solution on day one - often using gadgets and libraries they have very little understanding of.

Yes it may work, and you’ll certainly learn a lot, but there’s a huge chance the project will fall over, kill the dog, or just ‘not work’ the way you had hoped.

Here are some hardware ideas…
Hooking up Arduino hardware

Rule 1
Break your hardware build into small pieces - so you can verify each element works the way you expect and need it to.
Buttons, LEDs, motors, buzzers, LCD… everything.
None of them will work properly until you understand why you connect them up the way you have!
And - there are some things an Arduino simply can’t do. Whether it’s not enough of the right i/o, or the processing power / word size just isn’t up to the intended application. That’s why they make 16/32/64 bit processors with 64GB of memory!

Rule 2
Only try to use parts in combination - after you know they work by themselves as intended. It could even be a dead component.
This why your first project on new hardware is ‘blink a LED’. It’s not ‘blink a LED with a pushbutton’!
Until you know the LED and button work separately, why would you make your problem twice as complicated?

Rule 3
Use meaningful variable names and constants.
This will help enormously in understanding your spaghetti code.
door_switch says a lot more than inputpin2, or switch-11
(be careful - in some contexts, this could be evaluated as subtract eleven from the value of ‘switch’ !)

Rule 4
Software IS magic. Start with the simplest one or three line programs to understand fundamentals.
Writing 14 if/else conditions may not be as simple to debug and maintain as a single switch() statement.
This is a good time to add some form if debugging code…
Simple print() to the serial monitor, or light-up some ‘extra’ LEDs can help inform where your program is at any given time.
(Don’t quote me - god forbid!, but you might set some LEDs, and add a delay() temporarily to see your code stepping through different states.
But get rid of those delays once it all works! )

Rule 5
When you have the short blocks of code that work… separate them - so they don’t cloud your view of the program flow/logic. Create functions()

About now - take a break and read more here…
What to learn next

Rule 6
No matter how clever you think you are, write meaningful comments alongside your meaningful variable, constant and function names.
Three weeks after you finish the code, you’ll be struggling to remember what Pin_2, or load_get_one() does…

Rule 7
Arduinos and other digital devices are painfully logical. If they don’t perform as expected - it is rarely the Arduino’s problem. It’s yours. It is doing what your code told it to do… like it or not.
If that isn’t what you want it to do - then your logic, methods or expectations need to be reviewed.

Rule 8
Code may look right, and sometimes it’s hiding in the simplest things. Break apart the simplest logic, and walk through your code line-by-line, working out the results on paper (instead of the the Arduino) and write the progress on a piece of paper before carrying the results forward to the next line of ‘code’. Computers are remarkable for making mistakes faster than people can.

Each of these suggestions is not a solution of ‘how to write software’, but will help you build better, more readable projects that won’t get you laughed out of the hackerspace.

Finally… unless you have a really, REALLY good reason, don’t use delay() any time after setup() has completed. Use timers/millis().
You’re asking for problems if you want to make your project more responsive and multi-functional. Don’t argue!

Thx Weedpharma: If all else fails and you have to ask for help on this forum, give full details including links, circuit and in the manner required.
Write the question in plain language using normal punctuation.

SCHEMATICS:
There are as many style guides as there are schematics…
Answer #3 on THIS PAGE gives some helpful hints

Some more discussion from an old thread - with a number of worthy contributors.

Well put.

Then add:

If all else fails and you have to ask for help on this forum, give full details including link, circuit and program in the manner required. Write the question in plain language using normal punctuation.

Weedpharma

All excellent points. Now if we can just get them to read it instead of posting the traditional "Help!!!" message with no details :slight_smile:

I would also make use of the serial (if enabled) interface for debugging as well as my favorite for hardware only - have a pin or led you can blink or toggle at various points in the code. That way you know where it is.

mikey

Hi,
Good post, but where is your code and links? lol

Tom.... :slight_smile:

This won't compile... Why not?

my code

Please see my project here... (not)
[a link](http://a link)
:slight_smile:

Hi,
link

@lastchancename, excellent. I will bookmark it so I can refer others to it.

May I suggest "door_switch_pin" in Rule3 (or doorSwitchPin) rather than "door_switch"

May I suggest another couple of rules.

RuleN
When your program runs you can be 100% sure that the Arduino will be doing what your code told it to do. If that is not what you want it to do your program needs to be changed.

RuleM
If you are not sure why your program is not doing what you want follow through the code line by line working out the calculations with your brain (instead of the the Arduino) and write the result on a piece of paper before moving to the next line.

...R
Planning and Implementing a Program

Robin2:
@lastchancename, excellent. I will bookmark it so I can refer others to it.

May I suggest "door_switch_pin" in Rule3 (or doorSwitchPin) rather than "door_switch"

May I suggest another couple of rules.

RuleN
When your program runs you can be 100% sure that the Arduino will be doing what your code told it to do. If that is not what you want it to do your program needs to be changed.

RuleM
If you are not sure why your program is not doing what you want follow through the code line by line working out the calculations with your brain (instead of the the Arduino) and write the result on a piece of paper before moving to the next line.

...R
Planning and Implementing a Program

Those are much higher level rules Robin. Especially M. Brain following code is an art akin to classical music performance. The actions are precise and prescribed, but an individual performer's result is a product of their skill and how much they practice.

On your first point, I too append "pin" to names that refer to pins. Although I use infixedCapitals to separate words, rather than under_scores. I find it to be easier to read, especially when multiple lines contain underscored names - my eye tends to follow the underscore characters, rather than the actual lines. That might just be me though.

Thanks guys…
i paraphrased the various suggestions into the body of the original post, along with some links to previous threads where we’ve discussed novices getting in to skills.

Pin name aliases are very personal, as are capitalisation and use of underscores…
We all have our preferences.

ChrisTenone:
Those are much higher level rules Robin.

I see many questions which imply that the OP thinks the Arduino is making a mistake. That sort of thinking is a complete waste of time.

I don't think it requires any great feat of brainpower to read

val1 = 7;
val2 = 23;
myVal = val1 + val2;

and write down "myVal is now 30"

I do agree that reading code (in the sense of reading a book) and figuring it out is an art. I can't do it. But that is not what I am suggesting.

...R

@Robin2...
sorry, i can't see the points you're hitting here.
i'll gladly change the post if i know which lines you're referring to.

I see many questions which imply that the OP thinks the Arduino is making a mistake. That sort of thinking is a complete waste of time.

lastchancename:
sorry, i can't see the points you're hitting here.

I was referring to Reply #7.

Your Rule7 now covers the point very well (if it always did, I apologize for the confusion).

...R

One of the suggestions that I've seen here, that I really like, is to get a stuffed animal, and explain your code to the stuffed animal. The act of reading the code, and explaining what it is doing, even to a stuffed animal, has caused a lot of ah-ha moments. And, if it doesn't help, you have something soft to throw across the room 8).

PaulS - Repeating in order to teach is a great way of learning.
Often articulating a problem for someone else, makes us 'dumb it down' so that we can see our own mistake!

I like the stuffed animal... not sure if i'd admit it publicly!

(thanks Robin - all good)

PaulS:
One of the suggestions that I've seen here, that I really like, is to get a stuffed animal, and explain your code to the stuffed animal. The act of reading the code, and explaining what it is doing, even to a stuffed animal, has caused a lot of ah-ha moments. And, if it doesn't help, you have something soft to throw across the room 8).

Yep - it is amazing how many time (after hours of trying to find the problem), it becomes obvious as soon as I try to explain it to someone else. You know, that sentence where you go "and the this .... oh ... never mind!!"
Going to have to try the stuffed animal though - I have a Linux Penguin above my desk - he is usually a good listener :slight_smile:

Not sure about a set of rules, but I would suggest this as the No 1 tip.

Tip 1

If you want meaningful answers about how to implement your project, please realise that you do need to actually describe it to the forum, we cannot guess exactly what you are up to.

Do not leave it till post No 10 to describe the project.

At the risk of getting shot down in flames, there should also be some rules for the gurus who answer the questions!

The most obvious ones I can think of include....

  1. Try to keep the scorn and sarcasm to a minimum. Remember those old teachers we used to have who would chuck board rubbers at you and shout a lot - don't be like one of them!

  2. Answer the question asked, not the question you happen to have an answer to!

  3. Try to set the intellectual level of the answer at a similar level to the question - don't give a degree answer to a 1st grade question.

Ducking back under the parapet now....

I agree with 1) and 3) in Reply #16

Point 2) is a little more complex because it can sometimes be obvious that a different approach to the problem would be a lot more sensible.

...R

  1. can be difficult if the OP fails to actually tell us what they want to do. We then take guesses at what they want.

Weedpharma

Fulliautomatix:
At the risk of getting shot down in flames, there should also be some rules for the gurus who answer the questions!

The most obvious ones I can think of include....

  1. Try to keep the scorn and sarcasm to a minimum. Remember those old teachers we used to have who would chuck board rubbers at you and shout a lot - don't be like one of them!

  2. Answer the question asked, not the question you happen to have an answer to!

  3. Try to set the intellectual level of the answer at a similar level to the question - don't give a degree answer to a 1st grade question.

Ducking back under the parapet now....

you are actually more on target here than you might think. These multipe rant threads about how people who wil never read them need to know what is in them are a good place to vent constructively, but really more for the teacher than the student.

your #2 is so on target here it should be posted as a tag line from every beginner.

I see posts " I have to use X and got one, but am having a hard time " and responses of get Y becuase I know how t help you with Y.

someone posted they came to figure how to light an LED, were asked what color then told to buy a flashlight.