AVRDude does not play well with the new Atmel ICE controller on OSX — the OS enumerates the device and makes it impossible for AVRDude to access. If you’re here, it’s likely because of this. The following two methods both place all of the files in the /usr/local/bin directory in the hard driver. Unfortunately that directory is not in the default path. That means that when you type avrdude into the terminal it cant figure out where to look. In this prep-step you'll change the profile of your Terminal to add /usr/local/bin to the path. Find the Terminal program, you'll be using.
- Then you edit the Makefile
Free AVR fuse programmer for Mac OS X by Jason von Nieda. AVRFuses is a simple fuse programmer for the AVR series of microcontrollers from Atmel. It is written to mimic the look, feel and utility of the AVR Studio fuse programmer. The primary useful feature of AVRFuses is that it lets you intelligently select which fuses to set just like in AVRStudio. Runs on Mac OS X 10.6 and higher. Supports 8 bit AVR microcontrollers including XMEGA devices. Includes patches to gcc for new devices not yet supported by gcc's main distribution.
Install Necessary Software for AVR Programming:
For the electronics units in the Fab Academy, you will need:
- Avrdude (for programming AVR microcontrollers)
- GCC (to compile C code)
Jump to the instructions for your Operating System:
Ubuntu Software Install
Get and install avrdude / GCC software and dependencies:
Open Terminal and type:
Then type:- type 'y' when asked to do so by your system
Then type: Then type (may already be installed):
Download and Unzip the Firmware:
Move to the desktop
Download the firmware from the Fab Academy Electronics Production page.
Unzip the firmware
Mac OS Software Install
Get and install avrdude / GCC software and dependencies:
- Download and Install Crosspack AVR - Has an installer.
- Get Make (via XCode):
- If you are running Lion or higher - you can download XCode from the Apple App store.
- If you are running a pre-Lion OSX - Get the install disks that came with your mac and install the developer tools.
Download the firmware (right click on the link below and save it to your desktop):
Open terminal navigate to the desktop:
Unzip the fabISP_0.8.2_firmware.zip directory:
Move into the newly created firmware directory on your desktop
Windows Software / Drivers Install
Get and install avrdude / GCC software and dependencies and drivers:
- Warning, WinAVR is abandoned.You can use the installer, but before you start, take note of your current system path.
Installing it can destroy your systems path variable! - Furthermore, WinAVR may require additional packages to function on Windows 10. (Some programs are broken and do not run.) avr-gcc and other development tools can be installed in the Bash on Ubuntu on Windows 10 environment, follwing the same instructions as Ubuntu. However, I don't think a working avrdude can be installed this way. Using a Linux machine (or a Linux virtual machine) might be the easiest option for Windows 10 users right now. (If you have discovered better ways to make this work, please update this documentation!)
- Download and Install WinAVR - Has a (broken) installer.
- Here is a step-by-step set of instructions - After installing check your systems path variable, if it only contains the path to the winavr installation:
- copy those values
- restore your old path
- add the windavr path back to it
- close any commandprompt window you may have open
- Download the drivers for your version of Windows
- Plug in another FabISP or USBtiny programmer.
- Install the drivers:
Go to the Start menu -> Control Panel -> Device Manager (or run 'mmc devmgmt.msc')- Locate 'FabISP' under 'Other Devices'
- Right click on the 'FabISP'
- Select 'Update Driver Software..'
- Select 'Browse my computer'
- Navigate to the drivers folder you downloaded at step 4 and click on the folder.
- Hit 'ok' to install the drivers for the USBtiny / FabISP
Power the FabISP Board
The board needs power:- Make sure that the mini USB connector for the FabISP you are trying to program is plugged into your computer.
- AND that a separate pogramer is plugged in to the 6-pin programming header. (this could be another working FabISP or the ATAVRISP2, a USBtiny, an AVR Dragon, etc.)
If you are using the ATAVRISP2 programmer, you can skip step 7, you do not need to edit the Makefile, it is already set up to work with the ATAVRISP2 If you are using another programmer you will need to edit the Makefile.
Helpful ATAVRISP2 Programmer Light Indicator Messages
If you are using the ATAVRISP2 programmer only. If you connect the programmer to the 6-pin programming header on your FabISP board and you get:
- Green Light: means that the header is soldered correctly, the board is getting power.
- Yellow Light: means that the board is getting power, but most likely the 6-pin programming header is not soldered correctly (re-flow your solder joints / check for cold joints, check for shorts).
- Red Light: means that the board is not getting power - check for shorts.
Edit the Makefile
The Makefile is in the firmware directory that you downloaded. The Makefile is set up to work with the AVRISP2 by default. If you are using another programmer, you will need to edit the Makefile. Ubuntu:
Mac:
Open the Makefile with TextEdit.
Windows:
Open the Makefile with Notepad++.
Make Changes - All OS:
A window will open containing the Makefile. Go to the line that says:
#AVRDUDE = avrdude -c usbtiny -p $(DEVICE) # edit this line for your programmer
AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer
- If using the USBtiny programmer or another FabISP
- Remove the '#' in front of the line with 'usbtiny' in it
- Add a '#' to beginning the line with the 'avrisp2' in it to comment it out.
- save the Makefile
Program the FabISP (All OS):
Navigate to the directory where you saved the FabISP firmware. If you followed the instructions above, this will be the desktop.
Open your terminal / command line interface and move to the firmware directory.
Ubuntu / Windows type:
For Mac users who downloaded the modified firmware:
Next you need to compile the firmware.
Type:
If you are successful - you will see this response from the system: Type:If you are successful - you will see this response from the system:
Next, you need to set the fuses so your board will use the external clock (crystal)
Type:
If you are successful - you will see the following response from the system:Next you want to program the board to be an ISP.
Then type:
If you are successful - you will see the following response from the system.Wooo! Success!
Errors
- If you get errors - read the errors and follow instructions.
- If avrdude cannot connect to your board's microcontroller - you should follow the 'Troubleshooting Short Circuits' instructions and ask your instructor for help.
To Verify That Your ISP is working correctly:
Ubuntu:
Type:
If your FabISP has been successfully programmed, you should see a list of the USB devices plugged into your computer. The FabISP will be listed in a line like the following:Mac:
Go to the System Profiler > Hardware > USB > Hub:
Step - By - Step:
- Click the 'apple' menu in your main toolbar
- Select 'about this mac'
- Select 'more info'
- Under the 'Contents' menu in the left hand navigation
- Click 'Hardware' to expand the hardware menu (if not already expanded)
- Click 'USB'
- Under the 'USB Device Tree'
- Click 'Hub' to expand the hub menu (if not already expanded)
- 'FabISP' should be listed in the hub menu - Your FabISP device has been successfully programmed and is recognized by your computer.
Windows:
Go to the Start Menu > Hardware and Sound. The FabISP should be listed.
After You Have Programmed the Board:
Remove the 0 ohm resistor and solder bridge as shown in the picture below. Now you can use it as a programmer to program other boards.
Notes on USB and Timing
The USBtiny (on which the FabISP is based), the original FabISP, and all ofthe many variants and improvements use a library called V-USB to handle theUSB communication. USB is a fairly complex protocol, and usually isimplemented with dedicated hardware on a microcontroller with USB support.V-USB implements USB entirely in software, which enables USB on practicallyany AVR microcontroller just using the GPIO pins. The timing requirements aremet by using hand-optimized assembly code.
V-USB works incredibly well, considering how much of a hack it is.However, USB still has fairly stringent timing requirements in order to workproperly. V-USB implements a low-speed USB device, with signaling at1.5 MHz, which is the least demanding type of USB device. However, if thetiming is too far off, this can cause USB communication problems.
Over the years, many people have iterated on the FabISP design to reducethe component count, use cheaper components, and use more readily availablevalues. For example, a ceramic resonator isn't something you'd usually findon a microcontroller that's speaking USB, since the frequency might be tooinaccurate for reliable communication. Yet several FabISP designs use ceramicresonators, and appear to work. This raises questions about how fartolerances can be stretched before a programmer is no longer a reliable USBdevice. As USB ports get faster and faster, USB controllers can also be lesstolerant of timing and frequency variations.
To investigate whether some of the FabISP designs have deviated far enoughfrom the USB spec to start causing widespread problems, I probed severaldifferent FabISP variants with a high-speed oscilloscope. The results arebelow.
The oscilloscope capture shows the differential USB signals from threedifferent FabISP variants. The vertical lines are a 3MHz reference clock.Since low-speed USB signaling occurs at 1.5MHz, each bit should last for twovertical lines. If the timing is accurate, the transitions should happenright on the lines, not before or after.
These captures show the beginning of a packet on the USB bus, sent from theFabISP to the computer. This starts with a synchronization sequence (thehigh/low/high/low/high/low pattern) followed by four bits identifying the typeof packet (in this case, it's an acknoweldgement from the FabISP that the lastmessage from the computer was received).
The three traces, from top to bottom, are:
- An original FabISP, which uses a 12MHz crystal. The 12MHz crystal can be divided evenly down to the low-speed USB 1.5MHz clock. All of the bit transitions occur precisely in sync with the reference.
- A FabISP built with a 20MHz crystal instead. 20MHz is a more standard part in the fab inventory, but it does not divide evenly down to 1.5MHz (there's a third of a cycle left over.) This introduces a little bit of jitter; some of the signal edges are just a little bit late or early. The average frequency is still accurate, but the jitter reduces the tolerance for frequency error just a bit.
- A FabISP built with a 20MHz resonator. In addition to the jitter due to the non-integer clock divisor, resonators are not quite as accurate as crystals in terms of the frequency they generate. This can be seen particularly at the last bit on the screen, where both edges are now late. Over many bits, this error can accumulate.
The transitions for the original FabISP, which used 49Ω bus terminationresistors, are noticeably faster and more square. In later designs, thetermination resistors changed to 100Ω for some reason, leading to the morerounded edges.
Conclusions
While the timing has gotten measurably worse from the original 12MHzdesign, the current 20MHz crystal versions shouldn't cause any problems.Crystal resonators are still probably not the best idea for a USB device (thefrequency inaccuracy is easily seen on the bottom trace), they do seem to workin most cases. The risk is the luck of the draw getting a resonator that'sfar enough on the edge of its tolerance that it causes problems.
Fortunately, all of the USB transfers used by the FabISP are very short;there isn't very much time for the error to accumulate.
If you're making a new FabISP design, I'd strongly recommend using acrystal. The slight extra cost is well worth the accuracy.
Another option: Zaerc's FabTinyStaris perhaps the best combination of minimal component count, lowest cost, andtiming accuracy. It uses the internal RC oscillator—normally, a ratherinaccurate frequency reference—but calibrates it on-the-fly. A new USB framebegins precisely every 2 ms—by tuning the RC oscillator in software based onthe start-of-frame packets every 2ms, the microcontroller's clock can befairly well synchronized to the host's. A scope capture from the data lineson the FabTinyStar is shown below, and the timing is spot-on.
Note the nice sharp edges. In part this is due to the 49Ω resistors ratherthan 100Ω, but also due to a much shorter cable.
Revision history
Avrdude For Mac Download
- 2016/09/28
- imported from here (bmayton)
- removed separate firmware files; firmware for all platforms is identical. Removed 'mac' from folder name inside zip archive. (bmayton)
- Added notes about installing tools on Windows 10; need to look into how this should be done now. (bmayton)
- Added informative section about USB timing; might later move to a separate page (bmayton)
This is a quick tutorial for beginners that aims to show how to install tools, compile the code with avr-gcc and send it to the MCU with avrdude. It also introduce basics of automation of this task by putting the all instructions into Makefile. The example files (main.c, main.bin, main.hex, Makefile) has been packaged as a .ZIP file and can be downloaded here.
Updates
[28.10.2019] Take a look at docker version of AVR Toolchain
1. Installing avr-gcc and tools
To compile C and/or C++ source code of your firmware you will need gcc-avr compiler, the avr-libc C library and avrdude. What is extremely useful, there are complete and easy to install packages for all major platforms.
Linux, Ubuntu
Ubuntu provides packages, so you can just install them using this command.
Mac OSX
Download AVR MacPack. The MacPack disk image has an installer that does everything for you.
Windows
Download WinAVR, which includes everything you need and has a nice installer.
2. Compiling and burning the code
Now that you have the compiler installed, a next step is to compile simple source code into a .BIN file, then generate Intel .HEX file and finally burn this .HEX file to AVR chip using USBasp programmer.
Example code
Here is an example content of main.c file. The code does nothing except getting stuck in an endless loop but it’s always something!
Compiling
The command below will compile your code. It’s GCC so I assume it looks familiar to you and no additional information is required. If you want perform compilation for some other MCU then you need specify appropriate -mmcu option.
After performing successful compilation, you can check program and data memory size with this command.
Generating .HEX
Most programmers will not accept a GNU executable as an input file, so we need to do a little more processing. So the next step is about converting the information form .BIN into .HEX file. The GNU utility that does this is called avr-objcopy.
Burning
The utility called avrdude can program processors using the contents of the .HEX files specified on the command line. With the command below, the file main.hex will be burned into the flash memory. The -p attiny13 option lets avrdude know that we are operating on an ATtiny13 chip. In other words – this option specifies the device. The full list of supported parts can be found here. Note that full-length names are also acceptable (i.e. t13 equals attiny13).
Voila! Chip is programmed.
3. Make and makefiles
Now, we can automate this process by creating a Makefile and putting our commands there. The structure of a Makefile is very simple, and more information about it can be found here. Utility make reads automatically a Makefile file in the folder where you launch it. Take a look at a ready-made example.
If you launch a simple make in the terminal, only label “all” will be executed. When you launch (sudo) make flash label “flash” will be executed, and so on.
4. Summary
Essentially, assuming that our program is in main.c, only those three things are needed to compile and burn the code to AVR chip.
It’s important to highlight that we can easily automate whole process with Makefiles. Sooner or later you will need it!