AVR and Xcode
Sunday, October 11th, 2009
I recently purchased the beginning embedded electronics kit from SparkFun Electronics. It is a kit that include everything to start programming AVR microcontrollers. A microcontroller lets you control the most simple, physical things, like an LED or a motor. Given my lust for control, you can see why this has quickly become my latest obsessive hobby.
The problem is that I want to be able to program the micro with my Mac, which presented a few problems. Here is how I got it working with Xcode on my Mac.
The first step was getting the programmer to work.
The only problem? The kit screams Windows. By default it includes a parallel programer. The last time I had a computer with a parallel port was… well it was when I had a PC. Not only that but SparkFun only carries Windows compatible USB programmers (a programmer in this case is a device that transfers your code to the chip, not the skinny kid from high school with a Redbull IV in him). In fact, there are almost no AVR programmers that are Mac compatible.
Not knowing the days of frustration that I was getting myself into, I bought the STK500 USB programmer. Other options would be the now discontinued Pololu programmer, or build it yourself.
Luckily, Olimex, the company that made the STK500 USB programmer, has released an update that makes it Mac compatible. You can find info and instructions on how to install it on their product page. Be sure to follow the instructions exactly. You will need a Windows computer to do the upgrade. It worked fine in VMWare Fusion.
The next step was to get the build tools woking in Mac OS X. These are the programs that will compile your code and transfer it to the microcontroller.
The easiest way to get the tools needed is to get CrossPack. CrossPack includes all the tools necessary to build and upload your projects. This also includes some tools to generate Xcode templates.
Basically, the Xcode templates create a project with an external build target. So in the background all that is happening is make is being called. I found two problems with the default templates. One is that you have to use the command line to generate your templates. That isn’t really necessary since Xcode has a built in template architecture. Basically place any templates you wan to show up in the new file window in “/Developer/Library/Xcode/Project Templates”. Just make sure to create a sub folder there to create the section. I called mine AVR.
The second problem I had was that there is no way to upload the code to the chip. Luckily there is an easy fix. Right click on executables and select “Add: New Custom Executable”. Use /usr/bin/make as the path. Under arguments, add “flash”. This will call make, just like the target does, but it will make for flash instead of compile. Now you can select Build and Go and it will upload the program to the connected microcontroller.
To get going, you need to edit the makefile in the project. Select your microcontroller, for DEVICE. Input the correct value for CLOCK. I also had to add a variable for the location of the tools. I called it TOOLS
DEVICE = atmega168 CLOCK = 8000000 PROGRAMMER = -c stk500v2 -P /dev/tty.usbmodem* OBJECTS = main.o FUSES = -U hfuse:w:0xd9:m -U lfuse:w:0x24:m TOOLS = /usr/local/CrossPack-AVR/bin/ AVRDUDE = $(TOOLS)avrdude $(PROGRAMMER) -p $(DEVICE) COMPILE = $(TOOLS)avr-gcc -std=c99 -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)
In the PROGRAMMER line you will notice I used an asterisk (*) to select any connected programmer. I did this because the number changed on me a few times and I didn’t want to have to edit the makefile every time I plugged it in.
You should be good to go now. You can download my template, but you will still need the CrossPack tools.
Update: Jonathan mentioned in the comments that you can use http://www.engbedded.com/fusecalc/ to calculate the fuse bits.
Filed under: Electronics Tags: AVR, Microcontroller, Xcode
Michael Jean
October 29th, 2009 at 8:15 PM
Great job, a good fix for features missing in the default Crosspack template.
I have a suggestion. If you right-click on the ‘firmware’ target, and add a new build setting PATH = $(PATH):/usr/local/CrossPack-AVR/bin (or whatever), you can eliminate the need for the TOOLS define in your Makefile and in front of all the executable names. This makes the build output window a little easier to read.
David Beck
October 29th, 2009 at 8:21 PM
Thanks, I will give that a try.
YannickF
November 2nd, 2009 at 5:25 AM
Hello
Thanks for information about AVR and Xcode.
I was using AVRstudio without any problem (via Parallels desktop) but I want to use Xcode.
I can now build with Xcode, but if the build fail, there isn’t any information about the line (in source code) where the error appears. So, clicking on the error in build output window is not very useful (as it was in AVRstudio)
The output of avr-gcc (WinAVR) version gives the line number. It seems that the CrossAVR version just indicate the error type, not the line where it occurs.
How could I click on error and set the cursor on the appropriate line ?
Thanks
YannickF.
Michael Shimniok
February 28th, 2010 at 8:48 PM
Nice write-up, thanks for putting this info together! Am referencing this writeup on my blog post re: programming Pololu Orangutans on the Mac. –Michael
makefile template
April 3rd, 2010 at 4:49 AM
[...] columns to the right of the user area and the rows below the user area when I issue a template. …David Beck's Blog AVR and XcodeThat isn't really necessary since Xcode has a built in template architecture. … I didn't want to [...]
Ruedi Heimlicher
April 7th, 2010 at 12:10 PM
Hello
I am programming my Atmega’s with the USB-Programmer from http://www.tuxgraphics.org without any problems using the toolchain provided by CrossPack and a makefile from Tim Lott. After upgrading to Snow Leopard and Xcode3.2, programming failed with the message that the data for the atmega328p could not be found although I hat inserted the code for it in the avrdude.conf. The problem was fixed after typing once the line
avr-gcc-select-4
in the terminal. It is mentioned in the comments that gcc4 produces larger code than gcc3, but I didn’t get it to work otherwise.
Daniel H
April 13th, 2010 at 6:18 PM
Hi!
Does anyone have any idea what should I have to replace the fuses line in order to program an ATMEL AT90S8515?
FUSES = -U hfuse:w:0xd9:m -U lfuse:w:0×24:m
Thanks,
Daniel
Jonathan
May 26th, 2010 at 12:40 AM
Use this web site
http://www.engbedded.com/fusecalc/
It came up with this for our atmel
-U lfuse:w:0xf9:m
Delicia Gord
June 22nd, 2010 at 11:08 AM
I am definitely bookmarking this page and sharing it with my acquaintances. You will be getting plenty of visitors to your website from me!
Allun
July 3rd, 2010 at 3:33 PM
Hi,
regarding YannickF’s issue – I have solved this one and someone else might find the info useful.
Here’s my writeup from my personal notes:
XCODE DOESN’T JUMP TO THE ERROR WHEN CLICKING ON IT IN THE BUILD WINDOW:
This is because of a paths problem – the project settings make gcc compile the files in the “firmware” dir, and pipes the output back to xcode to show in the build window but gcc passes back a relative path, so unless the C files are in the same dir as the “.xcode” project file, xcode can’t jump to the appropriate line in the editor.
The fix for this is to
a) just read the line number that is reported in the build window and manually go to that line in the editor (with line numbers turned on)
b) put the xcode project file in the “firmware” dir then open the project and remove the references to the source and makefile, then re add them from their new location…..
d) set the project settings so that the path for the custom build command is “./” i.e. the current directory. This does mean that you get your hex files and project files and source all in the same dir, but I am will to deal with this and be able to click on the build errors and jump to them automatically!
d) is the nest option of course, the others are just there to show what the problem is.
Ethyl Riggsby
July 25th, 2010 at 12:11 AM
That was a fairly useful perception for me personally