For the electronics enthusiast, programming languages have become a tool almost as ubiquitous as the soldering iron. Just as there’s the old trusty iron on most workbenches, not far away lies some sort of compiler or IDE.

Sure, there are useful and cool things that you can produce without the use of a microcontroller, but there’s also a lot of useful and cool things that would be very difficult or impossible to make without a microcontroller.

One problem is — for those new to electronics at least — that learning to program can be daunting, just like learning to solder for can be daunting some.

However, unlike soldering, programming can be quite complex depending on the language and application. After all, universities have created entire degrees and programs around programming and computers.

But like soldering, programming is something that one can become better at with practice – degree not required.

This post does not focus on any particular language or platform. Some of you may be using Arduino in your projects, while others use PICs. Some may prefer BASIC while others write in C.

Rather than focus on one language or platform, I’ll cover some common programming errors that are not language or platform specific, but likely will apply regardless of your language or platform of choice.

Also, a list of potential programming errors by could fill many volumes by itself, so I’ll go over some of he more common things that can cause problems.

If you’ve been programming for a while, some of these will be a no-brainer to you. If you’re new to programming and microcontrollers, you’ll learn a few good tips that could save you hours of headache and frustration.

Let’s get it started!

The 7 Mistakes to Avoid When Programming Microcontrollers

1. I Have No Comment…
   

Comments in programming are one of the most basic, yet useful things. You can never have too many comments in your code.

Unfortunately, many of us, especially those new to programming don’t see it this way.

The compiler ignores comments. They are descriptive statements meant to be read by humans, so you and others can understand your code. In other words, comments should explain what the code does. Things that are obvious may not need them, but good programming practice says to use comments generously.

I’d bet you money that after a while you will forget what something in your code does and burn hours of time trying to figure out your own program.

Don’t be that person.

In the beginning of your program, have a section of nothing but comments before you write any actual code. You can explain what the program does, how the hardware works, what color wires are for what, etc. You should also add the date, name of the program and any revisions you’ve made in the comments section.

2. Not Using the Right Data Type for Variables
   

You wouldn’t try to put a square into a round hole, nor would you try to put a gallon of water in a paper bag.

Think of variables as a container – each container is designed to hold certain types of things.

Ever dreamed of being Iron Man, having the ability to build anything, anytime? Try Academy for Arduino!

So, declaring a variable like this: int myVariable = 3.14;

would cause the compiler to give you an error as Pi is not an integer and the integer data type only holds integers.

Doing something like: long mySmallNumber = 3;

Would be a waste of program space.

Why?

A long data type (in C) will eat up 4 bytes of data, regardless of the size of the number. Doing something like the above would be silly, unless you expect this number to grow very large.

Similarly, not using a data type with enough room can cause strange errors.

For example, if we add 1 to 32,767 (for an integer in C) we don’t get 32,768, instead it rolls over to -32,768. This is because 32,768 is too big to store as an integer. The value of an integer in C can range from -32,768 to +32,767. If you go outside those bounds, you’re in trouble.

Your language of choice probably has some similar “gotchas.”

When you create any kind of variable, you need to have some idea of what type of value it will hold and how big or small that value will get.

3. Variable Name Nonsense
   

Speaking of variables, give them names that make sense.

Declaring something like: int myInteger;

tells you absolutely nothing about what purpose this variable serves.

Instead, try something like: int currentTemp;

this is much more explanatory and makes it a bit obvious what this variable is for. That’s a good thing.

Also, be careful when using the letter “I” and the number “1” as they may appear to look exactly the same on screen depending on the font you’re using. The computer can tell the difference, you may not be able to. This can cause the compiler to complain about your code.

If the code actually does compile you can be sure you’ll have logical errors that are hard to find.

4. Back it Up, or Else
   

The number of people who fail to backup their computer often amazes me, as do the number of people who don’t backup their programs and code.

If you do backup your PC on a regular basis, your code files should hopefully be backed up also.

If not, you’re one hard drive failure or malware infection away from losing all your work.

Backup your programs with multiple methods. You can use external hard drives, flash drives, Cloud storage, CDs, whatever – just do it.

I keep a clone of my complete hard drive (OS, programs, data, settings and all) on an external hard drive. A new backup is created every week and I keep the three most recent backups, in case the newest one gets corrupted somehow.

I also use Mozy (similar to Carbonite) and Dropbox to keep of-site backups of important individual files for quick recovery. Off-site backups also shine when it comes to fire, floods, burglaries and the like.

5. Not Enough Feedback
   

Get whatever feedback you can when debugging your program. Debuggers are fine when your widget is connected to the PC, but not much help in real-world situations.

To get feedback when not tethered to a PC, use an LCD or speaker or even a few LEDs. That way, you can call the LCD (or whatever) during your various routines and have it send out information regarding the status of your program, so you know what it’s doing.

This may slow your code down a bit, but once you work out all the kinks you can disconnect the feedback device (if you want) and comment out the lines of code that deal with it.

6. Not Recycling Code (Even Though Being Green is in)
   

Keep small working programs for sensors, routines, interrupts etc. that you commonly use.

That way, instead of reinventing the wheel every time you start a new project, you can just drop in the necessary parts of code you need for your sensor or routine.

For example, you may have some code that deals with communicating with an LCD or driving a servo that you commonly use. Instead of writing the code again from scratch, copy and paste the appropriate “mini program” into your main program and adjust any other variables and parameters as necessary.

7. Dealing with New Hardware
   

This one is related to the previous tip.

When adding or experimenting with new or unfamiliar hardware, create a simple program that only tests this new hardware.

After you get it working the way you want it to, you can copy and paste the code for this hardware into your main program.

If you think you’ll be using your particular piece of hardware often, save the code so you can use it on other projects.

Avoiding Common Programming Pitfalls

If you have a lot of programming experience, you may already be doing many of the things on this list.

If you’re not doing them now is the time to start. It will save you headaches, time, frustration and make your life easier in general.

If you’re new to programming, many of the above are recommendations you would get if you were to take a programming course. Now that you know these things, you can go forth and create useful, interesting projects.

Comment and share you best programming tips!

Ever dreamed of being Iron Man, having the ability to build anything, anytime? Try Academy for Arduino!