Using WinAVR and Command Line for AVR Development
Since my V-USB tutorials became popular, a recurring theme in the comments section have been people who are obviously motivated to try out the tutorial, but due to limited exposure to C language and command-line are either having trouble following my short instructions to compile the example .hex files, or being scared of the command-line, have tried to use AVR Studio instead, and fail.
I have to admit that first I was a bit annoyed by these people – why are they trying to follow a challenging project, when they seemingly have no understanding of how command line, makefiles, C compiler and linking process works? Then, comment by comment, I finally realized that not everyone started coding in the nineties where you launched Windows 3.11 mostly to play Solitaire, and biggest thing in coding productivity was 80×50 text mode which allowed you to have 16-color hacking bliss in your Borland Turbo C++ 3.0 IDE (or RHIDE, after DJGPP came around).
So, instead of either ignoring these people, or spending any more hours answering the same questions, I decided to start a new series of tutorials to cover really basics of getting into AVR development the way I like to do it: Old skool.
Navigating the command line
The bar for command-line wizardry in AVR development is low. There are four levels in it:
- Firing up command prompt
- Navigating to a directory and viewings its contents
- Running commands
The first one is really easy. In Windows 7 you can just click the start button, type “cmd”, and you’re there. Or type “command”, as the Command Prompt is usually the first search hit displayed. More hardcore persons use Win+R (that key with flag symbol finally does something useful!) and type “cmd” into the Run dialog as shown in title image of this post.
Once you’ve bitten the blue pill, commanding #2 is also quite easy. First, you need to understand that command prompt is very much like Windows explorer (shown in the above screenshot) – you are always in some directory, and the commands you enter usually work within that directory. In the example above, we are in directory E:\Koodi\AVR\usb_tutorial – let’s try if we can replicate that in command line:
As you can see, you use “X:” to switch to another drive, “cd XXX” to go to directory XXX, and “dir” to display directory contents (a good way to make sure you are in the correct place). By the way, you can go several directories in one go using directory separator \ with commands like “cd koodi\avr\usb_tutorial”. You probably already noticed that Windows command prompt filenames are not case sensitive, because they weren’t that in the 80s, and, you know, who likes change anyways?
To go up one level, you use “cd ..” (“..” essentially means “one up”). To go to the top level directory, “cd \”. Note that backslash ‘\’ is different from normal slash ‘/’ used in Unix-type environments – take your time to find it from your keyboard! You can also combine \ and .. with normal directory names. Now can you guess what these do:
cd ..\.. cd \koodi\avr\..\avr dir \koodi\avr dir ..\
Once you’ve mastered
dir, you should already understand mostly everything there is to know about Windows command line – commands (like “cd” and “dir”) and their parameters (for both those commands, it’s the directory you want to change to, or display the contents of).
Side note: Unrecognized commands and PATH variable
Careful readers note that in the above example command line session, I also tried to run “make” like instructed in the V-USB tutorials. Command line is very friendly and helpful, and in this case it printed out a verbose and easy-to-understand error message: It could not recognize the command that was entered. That means that:
- “make” is not a valid internal command prompt command
- There is no “make.exe” (binary executable) or “make.bat” (text-based batch command file) in the current directory
- …nor is there “make.exe” or “make.bat” in any directory specified by the PATH variable
What does this “PATH variable” mean? It is basically a system-wide variable (to be exact, command prompt “inherits” the global setting and you can then change it locally with “set” command and globally with “setx“) that tells the directories where commands are searched from. You can view/modify the global PATH variable by right-clicking the “Computer” in Start menu, selecting Properties / Advanced system settings / Advanced / Environment Variables.
Now that you read the above paragraph, you can pretty much forget it. The key takeaway is that command-line utilities such as “make”, “avrdude”, and “gcc” get usually installed “somewhere” when you install WinAVR, MinGW and similar compiler packages, and the installer modifies you PATH variable to include that location, so when you type that “make” command, it just automagically works. This means that you do not need to copy make.exe, gcc.exe or anything else to your project directory – if you do, you’re doing it wrong!
WinAVR is a great GNU GCC cross-compiler suite that has all the necessary utilities to do AVR development in C (and assembly) language in Windows. “Cross-compiler” means that it runs on PC hardware, but generates binary code for another platform, in this case 8-bit AVR microcontrollers. GNU GCC is a widely spread, open-source C compiler (also C++ is often included) suite. WinAVR packs the compiler, several useful utilities such as make, and some AVR-specific stuff such as “avrdude” utility which can be used to flash the binary into AVR microcontroller, and change fuse settings of AVR MCUs.
Installing WinAVR is really straightforward: You just head to the WinAVR site, go to download section, and navigate yourself to the latest install.exe (at the time of writing, 2010-01-10 version) and run it. You can pretty much install it where you like, but for safety, one might want to avoid spaces in directory names, as they sometimes cause problams.
After you’ve installed WinAVR, restart command prompt for the PATH changes to take effect, and check that “avr-gcc”, “avrdude” and “make” commands give their own error messages (avrdude actually just displays its command-line options) and you don’t get the generic “command not recognized as…” rant. Now let’s try our “make” process again:
Voilá! Now if you had your USB tutorial project circuit attached to the computer via ISP programmer, and Makefile settings in order, you could just type “make flash” and start enjoying your program. If you don’t stay tuned for next part which will cover compiling, linking and Makefile basics!