3 Beginner Arduino Mistakes

36,984

220

38

Published

Introduction: 3 Beginner Arduino Mistakes

About: Becky Stern is a content creator at Autodesk/Instructables. She has authored hundreds of tutorials about everything from microcontrollers to knitting. Before joining Instructables, Becky worked for MAKE Maga...

In my decade of experience building with and teaching Arduino, I see three mistakes more often than any others. Beginners typically:

  1. bite off more than they can chew by attempting to build a project with too many elements at once,
  2. make incorrect assumptions during prototyping,
  3. and underutilize the resources available to them online.

Read more about each one in the Instructable that follows, including how to avoid making these mistakes yourself.

If you're just starting out in Arduino, try my free Instructables Arduino Class! It'll bring you up to speed on the basics and best practices, further enhancing your Arduino fun-to-frustrating ratio.

If you've got tips for beginners, we'd all love to hear about them in the comments!

Step 1: Sensible Bites

The most common beginner Arduino mistake is biting off more than you can chew by attempting to build a project with too many elements at once. You get frustrated and overwhelmed, and the project never gets finished. If you want to build a quadcopter, you need to break it down into simpler systems first. Quadcopters have GPS, inertial measurement units with accelerometers and gyroscopes, not to mention variable speed motor control. You should honestly reflect on your abilities, and then look up examples and tutorials for each component of your project, and build them successfully before attempting to combine them.

Step 2: Don't Assume It's Right

The second mistake I see frequently is making assumptions during prototyping. I know it can be really tough to learn all the things that possibly could go wrong, whether it be your wiring, or your code, or your software settings-- but when you're circuit's not behaving like you expect, don't just assume your wiring is right without checking. Double check the pin number you specified in software is the same pin connected to your LED, or sensor, etc. Double check power and ground, especially. Get into a detective mindset, hunt for missing semicolons, get out your multimeter, add in some serial debugging to your code to help figure out what's going on.

Prototyping resources:

Step 3: Look It Up

The last mistake I see a lot with Arduino beginners is underutilizing the resources available to you online. The Arduino site has a reference section that breaks down the whole programming language by groups of commands with simple samples demonstrating each one. I look up stuff all the time, like how modulo works. But there're also community resources you should be taking advantage of as well, like researching your questions in forums online, and posting Instructables about your projects!

Thanks for reading. Don't forget to check out my free Instructables Arduino Class, IoT Class, and my other projects, too. I look forward to reading your feedback in the comments!

To keep up with what I'm working on, follow me on YouTube, Instagram, Twitter, Pinterest, and Snapchat.

Share

Recommendations

  • Water Contest

    Water Contest
  • Clocks Contest

    Clocks Contest
  • Creative Misuse Contest

    Creative Misuse Contest

38 Discussions

For me it is the coding, cannot make heads or tails about it. Seems very technical and unless I can visualize and actually do it hands on it don’t make sense. Writing the code I see as very difficult, copy someone else’s work is not an issue but to take an idea and put it to code is a whole different story

7 replies

Coding can be a hurdle for lots of hobbyists, especially when it comes to the use of libraries (most of which IMHO are poorly documented).

My usual recommendation when starting to learn how to code is to start small and take baby steps.

This thread is a little old, but for anyone else who has problems, I recommend using tinkercad. They have a block code editor, and sometimes it's easier to understand things when you are clicking blocks together instead of typing code. So there's that. https://www.tinkercad.com/

Larry,

I'm no expert but an easy way to learn coding is to take a known working sketch and then "play around" with it. Use a simple sketch such as moving single servo and make changes to the code and observe the result. Do the same with a LED. These are easy to manipulate and the visual feedback will help you to get a "feel" for the code.

Thanks for your comment,I guess I am just intimidated by writing the code and getting any understanding of all the wording and concepts of the code. This may sound crazy but I can take an IC chip and understand if I put and input on a pin weather it is voltage or current and get the resulting output but to incorporate any coding to this is confusing to me anyway.

I don't know if this will help in your confusion - but when you say, "if I put and input on a pin weather it is voltage or current and get the resulting output" - ask yourself, "is this the 'resulting output'" I expected to get and how did I know what I expected to get ( datasheet )?

Code is just a matter of creating the datasheet. Defining what you expect a 'resulting output' to be and thus it also requires testing ( as you mentioned doing ) that the actual is what you expected as defined by your code.

Might be of interest to you:

The gist of the article is about how we limit our potential to get our head around a subject well within our reach because we have this bias-based assumption that the subject is difficult:
http://lesswrong.com/lw/5a9/learned_blankness/

These are definitely common mistakes, and your suggestions are excellent. I’d like to add that the process is frequently iterative; just because a schematic is available online doesn’t mean that the circuit is robust. Luckily there are fairly knowledgeable people in most of the major forums, and these folks can be very helpful if/when a circuit doesn’t work as expected.

0
user
Seo10

9 months ago

I have a couple of projects I would love todo. On the surface they do not look that complicated. I am however 75 and I also know, as you said, if I get into it and I get overwhelmed If 'lol set it aside and never finish it. Sometimes It's think old dogs can't learn. New tricks.

2 replies

I agree Paul W. is an excellent YouTuber. I have gone most of all his Arduino shows.

As a recent retiree, I decided to learn a new skill. Electronics. I bought heaps of sensors, I'm embarrassed to mention how many different stepper motors I have bought, soldering systems, adjustable power sources and on and on.

I have yet to make anything work. I really appreciate your instructable, I'm off to the hall of mirrors.

My method is to keep things simple and build it up in stages. Start with a basic arrangement that works then save it. You can then add the next stage and if it all goes horribly wrong you can always go back to your previous design and work from there. Keep adding stages until you have something amazing! Also don't be afraid to copy or adapt someone elses ideas.

3 replies

I'm a retired electronics engineer with 40+ years of experience in system design and some programming. What you describe is EXACTLY how engineers go about designing and developing a project. It would be next to impossible to design an entire complicated piece of machinery and test it in final form without making the "building blocks" one at a time and testing each, then going on to gradually link them together into the final working product. This can literally take years for a very large, complex project.

GRADUALLY link them together into the final working product. I still struggle with this and do a lot of refactoring in an effort to create a more perfect model. Can't seem to find the ideal "flowchart" without many refactor attempts. If theirs a secret to this - please share.

I want to add here that even for small development like embedded programming of 8-bit microcontrollers, using git or some other version control system should be embraced for projects; that way, you can always branch and/or roll back as needed.

Thanks for these points

This is sound advice. I have yet to enter the world of custom processors. I've been working on a custom keyboard for a very long time, and someone else suggested that laying out and scanning a set of keys was extremely easy.

The problem was that I needed a massive lookup table to convert the key scan to a code for the PC, as well as driving a small LCD to show specific statuses. How it was going to cope with high enough scanning and performing the lookup followed by generating the code was going to be cumbersome and probably too slow.

I elected, for simplicity, that my output would be PS/2 based so that I don't have to fight with the USB protocol. I know the AT-PS/2 protocol very well, so a simple PS/2 to USB adaptor would suffice for most computers. Eventually, I realized that instead of having to write masses of code to read a key matrix, I could use an existing decoder chip straight off the shelf, and use the PS/2 as the input as well.

So, as you've suggested, I've broken it down into smaller modules. I just need to learn enough code to read PS/2 input, make decisions on that input possibly updating the LCD in the process, and then feeding the translated output back into PS/2.

When I get to the prototyping stage, the only coding that I really have to learn is that which is necessary to interpret the PS/2 signal, and how to drive the LCD. Everything else should just be a huge IF...THEN list.

My best advice is if you are having problems, use rubber duck debugging. It feels a bit silly at first, but it really does work