BEGINNERS: Troubleshooting your project

BEGINNERS: Troubleshooting

It's probably hardware!
Well in the early learning stages at least.
This is not a programming or debugging tutorial - someone may think about that later.

THIS IS REALLY IMPORTANT, because if you stuff up the hardware (wiring/power/voltages etc), not only will the software NEVER work, but you have a very good chance of smoking* your Arduino and/or shields / connected devices.

There are already several threads in this forum section that discuss VIN, (Common) 0V/GND, voltages, and voltage regulators. No point in repeating them here, just scroll down the topics.

Once you know the hardware is working to some extent, you can try the product tutorials. e.g. Blinking a LED, or driving a motor. (yes, there are guides and tutorials for these!)
While they don’t match your exact project requirements, they will usually 'do something' to validate the hookup.
Then you can get on with your own code.

If you need help with checking your hardware setup, prepare the following items when asking.

A description of what you are hoping to achieve. (Try reading it back to yourself - twice!)
A clearly drawn block diagram (easy), or schematic (better) that follows soe meaningful convention.
Typically higher voltages are drawn from the top of the sheet, 0V/GND, and lower voltages at the bottom.
Signal / logic flow from left-to-right e.g. sensors, switches & inputs o the left, with outputs, drivers and motors etc toward the right.

Not only will it help people that are helping you - but you may even identify the problem yourself.

SOFTWARE TROUBLESHOOTING
Verify the hardware first! (above) No software will work if the hardware is borked.
The language to learn is C, or if you want to get in deeper C++

Don’t try to write or fix the whole program in one chunk.
Break it down into manageable pieces.

Work on (or logically isolate) chunks of your code as a FUNCTION() - so you can complete each element by itself, abnd prove it does what you want it to.
Comment out anything that is not funcdamental to the logic of your code.

THEN //COMMENT OUT THAT NEWLY WORKING FUNCTION <<
And move on to the next piece of code as another separate mini-project.
Only when each function() has been verified as working should you try uncommenting them one piece at a time. (Gluing them together )

Sprinkle Serial.print() liberally - so you can see what’s happening with your code,variables and calculations. You can remove or /comment/ them out later.

You will get new compilation errors each time - this is your chance to read the error messages and learn! Often related to undeclared, or unbalanced {} pairs.
(Various people will disagree with this, and it may be tedious, but at least you know where yo stand when each piece begins to work.)

ADD COMMENTS for every block of code or function(), and use MEANINGFUL variable names.

At this point you should be very close to a working program.
There will be subtleties which can't be explained in this tutorial (like delay(), scope of variables etc).

One thing you might encounter are RUNTIME errors. These can be sneaky buggers, as there is no error message! The code just crashes, stops or restarts. These are partly addressed by breaking your code into parts, but just as importantly, ‘catching’ invalid conditions in your code - and becoming more familiar with the language over btime.

If you post what you've done after following this guide - anyone will be willing to help you.

*smoking - let's the white smoke out with an occasional spark or flame!

very simple block diagram.png

Arduino Analog Inputs:

  1. Disconnect the Arduino Analog Input from the Device Analog Output
  2. Connect the Device Analog Output to a voltmeter
  3. Verify the Device Analog Output works based on reading from the voltmeter
  4. Reconnect the Device Analog Output to the Arduino Analog Input
  5. Verify with a voltmeter the voltage at the Arduino Analog Input to ensure the device is still working as expected.
  6. Begin to troubleshoot the analog reading in your arduino sketch.

I have spent half my life tracking down coding errors and syntax errors.
If I am compiling and I get an error in a certain function and can't for the life of me understand what the error message is on about, I select all the code lines in the function and then comment out the lines. I then uncomment a few lines or a block, and then try a compile. It that compile goes well I then continue uncommenting lines and blocks and trying a compile again, and so on. Eventually I will uncomment a line, or block, and the compiler will fail. This narrows things down for me

Steve