Neural Advance

In the past I wrote an article about writing assembly programs for AVR devices on the Mac but missed a couple of important points.

The major problem with my original article was that I was passing everything through the C compiler rather than just using avr-as as one should. The other problem was that I was using the libc headers to get the names of the specific ports. The better solution is to take the include files that Atmel supply with AVR Studio 4 on the PC and just make a couple of small changes to make them work using avr-as. The include file I use for the ATmega168 can be found here.

By using this approach there is basically no difference between the assembly that you would use in AVR Studio 4 and that you can use on your Mac. This makes the entire development process extremely easy.

So lets list the source code of our updated LEDon.S file from the original article:

.include "/home/dev/m168.h"
 
	rjmp init
 
init:
 
	ser r16
	out DDRB, r16
	out DDRD, r16
 
	clr r16
 
	out PORTB, r16
	out PORTD, r16
 
	.global main
 
main:
 
	sbi PORTB, 0
	rjmp main

it should look pretty similar to the original.

The only real difference comes when you want to assemble it and produce a hex file which you then upload with AVRdude (as documented here). So you do that with these commands (assuming you have saved the above file as ledon.S and that the header file I provided is stored in /home/dev – if it is different change the include line to point to the correct path):

avr-as -mmcu=atmega168 -o ledon.out ledon.S
avr-objcopy -O ihex ledon.out ledon.hex

this should result in a nice ledon.hex file.

Now that you can use the “raw” assembler you can just read the data sheets and the AVR instruction reference and use the port names as is rather than having to use the rather stupid C macros that AVR libc provides. Obviously this technique is completely cross platform and will work on any UNIX based machine, not just Macs.

It has been awhile since Apple announced the Mac App Store but it has taken this long for me to decide what my opinions are on the subject. The fact that the announcement will have a huge impact on the Apple developer community as a whole is undeniable.

Although I am late to the party when it comes to discussing the new Mac OS X app store I think it should be noted that this post comes after some thought on the subject. The major disadvantage of the Mac app store is the fact that Mac OS X customers will start to see it as the only legitimate place to buy Mac software from. Apple have been very careful to make it clear that developers are free to distribute applications separately from the app store if they wish but I worry about it when I think of a consumer choosing between an app which is conveniently located on the app store and one which is not. Which app do you think they will be most likely to purchase?

The fact that Apple do not deny developers the chance to distribute applications on their own does not mean that the effects of the app store on the greater developer community will not be the same. If customers are trained by Apple to use the app store to look for application purchases (it seems likely that Apple will make the app store a prominent part of the next Mac OS X release) then why would a consumer even bother looking outside of the app store? Heck, they might not even think it is possible to get software anywhere else.

This kind of situation is one in which developers need to find a way in which to keep their applications in the publics minds if they are not going to be deploying their applications to the app store (for whatever reason, Apples restrictions seem unnecessarily harsh). This will take some very creative marketing and is something I do not envy those who are stuck with legacy applications that they have no hope of ever making compliant with the requirements that Apple have laid.

The other important issue at stake here is one of price. The iOS app store has basically centred around 99 cent applications, anything more than that is considered a premium price. By their very nature Mac OS X applications require much more developer work on average than iOS applications and that should be reflected in the price. Unless Apple bring iAds to Mac OS X (something that I feel is very likely) most developers may well feel they are going to be forced to lower prices to below what they would expect to charge before the app store existed.

Even though I have laid out some problems which I foresee occurring once Apple release the app store for Mac OS X I still think in general it will be a positive boost for Mac OS X developers. It will give them easy access to every single modern Mac owner and that is a lot of people. Those who design a popular application have the chance to make an awful lot of money on the Mac OS X app store, assuming of course you can comply with Apples requirements.

Update 3: Although this article is now obsolete (see update 2 below) I thought I’d at least make sure the code blocks display properly using the new syntax highlighting system in use.

Update 2: I have rewritten this article here. If you want to do AVR programming in assembly on Mac OS X then read that article. This one is just kept around for historical reasons and to list another option if you want to do it a different (albeit harder) way.

Update: After a little bit more careful study of the AVR libc library I realised that you can just make use of the macros it contains in order to access ports etc without having any ugly defines.

I struggled to get up to speed with creating my first assembly program for my AVR device. The problem is that the tutorials and information available either target C for the AVR GCC tool chain (doesn’t help me much as I want to use assembly) or target assembly but using another assembler. There does not seem to be any specific information that I could get to work. I hope that this article will help if you find yourself in the same position.

So the first thing you need to do is build your GCC tool chain: here are some instructions. Once that is done you should be all ready to get started.

First things first, I am assuming you’ll be using avr-libc to make use of all the defines which it sets for you (register names etc), gcc, gdb and avrdude (at a minimum).

First things first I tend to define the device I am using at the top of the source file just in case. Then we need to include the AVR libc file which gives us the nice names for ports etc.

#ifndef __AVR_ATmega168__
#define __AVR_ATmega168__
#endif
 
#include <avr/io.h>

We include the AVR libc io.h header file so that we can use the libc defines to access the relevant ports by name rather than having to use their real address or having to define them ourselves.

Now we move on to the actual assembly program. At first I was stuck because the linker complained that no main method was declared. I found this somewhat perplexing until I remembered that you need to declare a main method using the .global statement. So don’t forget to have a section defined with a .global main.

     rjmp Init
 
Init:
 
     ser r16
     out _SFR_IO_ADDR(DDRB), r16
     out _SFR_IO_ADDR(DDRD), r16
 
     clr r16
 
     out _SFR_IO_ADDR(PORTB), r16
     out _SFR_IO_ADDR(PORTD), r16
 
     .global main
 
main:
 
     sbi _SFR_IO_ADDR(PORTB), 0
     rjmp main

The above code is simply meant to turn an LED on and was (very slightly) adapted from the “AVR: An Introductory Course” book.

It is vital that you save this file with an extension of .S (that is a capital S) as that is what tells GCC to run it through the assembler.

We will compile it with the following command:

avr-gcc ledon.S -mmcu=atmega168 -Os -g -o ledon.out

you will need to substitute the atmega168 part with the correct device that you are using. Failure to do so will result in a program compiled for the wrong chip.

We then need to create a hex file from the output which we can then upload to our device using AVRdude. Use this command:

avr-objcopy -O ihex ledon.out ledon.hex

You can find out how to upload it to the device here.

And there you have it. Debugging it seems somewhat more complex if you don’t have a JTAG (such as the Arduino, I’ll need to look into getting something like the AVR Dragon before I can use AVaRICE and GDB together).

Update: Updated the article to use nice new syntax highlighting.

Before you start you must already have the Apple Developer Tools installed. The latest version of which can be downloaded from the Mac Developer Centre (registration required).

GNU Binutils:

cd binutils-folder
mkdir obj-avr
cd obj-avr
 
../configure --prefix=CHANGE_TO_ABSOLUTE_INSTALL_PATH --program-prefix=avr- --target=avr --disable-nls --disable-werror --enable-install-libbfd
 
make
make install

GCC:

Make sure to download MPFR, MPC and GMP first and place then in folders (with the same name and in lower case) in the root of the GCC source directory. They will automatically be compiled along with GCC itself.

If you make use of MPFR 3.0.0 there is a patch that you need to install before you compile GCC. Download it here. Save it as allpatches.txt and then simply use the following command (assuming you are in the gcc directory) to apply it:

patch -N -Z -p1 > ../allpatches.txt

Once that patch has been applied you now need to patch GCC itself with this patch. Unfortunately you need to insert the missing commas in the middle column, it should be straight forward to see what I mean when you open the patch file up in a text editor. Apply the patch like so (again assuming you are in the gcc directory):

patch -p0 < ../changes.patch.txt

At this point you are now ready to start the compilation and installation of the AVR GCC compiler:

cd gcc-folder
mkdir obj-avr
cd obj-avr
 
../configure --prefix=CHANGE_TO_ABSOLUTE_INSTALL_PATH --program-prefix=avr- --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 --disable-werror
 
make
make install

GDB:

cd gdb-folder
mkdir obj-avr
cd obj-avr
 
../configure --prefix=CHANGE_TO_ABSOLUTE_INSTALL_PATH --target=avr --program-prefix=avr-
 
make
make install

AVaRICE:

cd avarice-folder
mkdir obj-avr
cd obj-avr
 
$CPPFLAGS=-ICHANGE_TO_ABSOLUTE_INSTALL_PATH/i386-apple-darwin10.3.0/avr/include LDFLAGS="-LPATH_TO_LIBBFD -LPATH_TO_LIBIBERTY" ../configure --prefix=CHANGE_TO_ABSOLUTE_INSTALL_PATH
 
make
make install

References:

Building and Installing the GNU Toolchain

Although my original article predates the following article I came back and updated my article using some of the information contained in the articled linked below when I upgraded my tool chain so I include a link here just to mention it.

Compiling AVR Toolchain from Scratch

Another small note for myself here.

In order to compile for AVR devices it is essential that you define which AVR you are targeting on the command line with your version of GCC. Chances are you will be targeting an ATmega168 (use the -mmcu=atmega168 command line switch) as that seems to be the most prevalent hobby chip. It should also be noted that it is even more important when compiling code for embedded devices to use the -Wall command line option.

Also for future use the avr/delay.h file is now util/delay.h (which gets me every time).

I often see people asking how to compile the Boost C++ libraries on Mac OS X so I thought I would post a quick tutorial.

1. Download B-jam from http://www.boost.org/ – you will find it in the “Downloads” area of the site. Make sure you download the Mac OS X binary file to avoid problems.
2. When B-jam has been download, extract the archive by double clicking on it.
3. Move the executable entitled “bjam” to a directory on your path. If you don’t know what this means then just open the Terminal application and type “cd ” (the trailing space is very important) then drag the folder which you just extracted onto the Terminal window, click once in the Terminal window and then press return.
4. Type “sudo mv bjam /usr/bin” exactly as shown, you will then be asked to type your administrator password. Once you have typed it in press return and bjam will now be accessible from the command line.
5. Next download the source code distribution of Boost from http://www.boost.org/ – this is found in the same place as B-jam.
6. Extract the archive and then open the folder in Terminal using the same method outlined above.
7. Type “bjam stage –build-type=complete” and press return. Wait for a couple of hours for it to finish and then type “sudo make install” to install the boost libraries on your machine.

Update: For those who want to build just the 64 bit versions of the shared library that are thread safe in release mode (this is a much, much faster build time) then you can substitute the build command in stage 7 above with this one:

bjam toolset=darwin link=shared threading=multi runtime-link=shared variant=release address-model=64 stage

Update 2: To build a 32 bit version for PowerPC Macs and a 32 bit and 64 bit version for Intel Macs in a universal binary you need to substitute phase 7 listed above for the following command:

bjam toolset=darwin threading=multi variant=release link=shared runtime-link=shared address-model=32_64 architecture=combined

Mac OS X has a rich development environment that is at least the equal of Linux in terms of diversity and available features. For a start Apple supply Xcode, which in my opinion, is one of the best IDEs available on any platform. Included with the Xcode IDE is a large set of tools including GCC, NASM, Flex, Bison, Make and many other tools traditional UNIX programmers will find familiar.

I want to show the more traditional Mac users who perhaps only know about Objective-C and Cocoa what the possibilities are when it comes to using the vast array of open source software on Mac OS X.

The first thing that should be said is that open source libraries normally come in source code form and thus require you to compile them yourself. This is actually a very easy process, and normally just requires you to issue the following commands:

./configure
 
make
 
sudo make install

from the Terminal application. Obviously this will only compile and install the default package, if you want more control over what you want installed or where you want it to be installed then you will need to supply some options to the configure script.

In order to find out what options are available to you just type the following command:

./configure --help

and it should list all the available options that you can pass to the configure script. The default install location for most libraries will be /usr/local which in 99% of cases is fine.

Assuming there are no missing dependencies for the particular library you are trying to compile the configure script should run successfully. Once that is done you can then compile the library using the make command. Once it has compiled all you need to do is install it using the sudo make install command.

Now that you have the library installed you will most likely want to make use of it from within your Xcode projects. This is an area that many people seem to find somewhat confusing so I will try to keep this as simple as possible.

There are two stages to using a library (other than the ones that come with Xcode / the operating system itself). First you must tell Xcode where to locate header files and secondly you must tell Xcode where to find the compiled dynamic or static libraries. The first stage is very simple indeed, with your project open go to the Project menu and select “Edit Project Settings”. This will bring up the build configuration window where you can set numerous options to do with compilation and deployment relating to your project.

Look for an item called “Header Search Paths” in the Search Paths section shown in the image below.

Xcode Build Settings

My project as you can see already has the header and library search path defined. In this case it tells the compiler to look in /usr/local/pgsql/include for header files and /usr/local/pgsql/lib for library files. If you see a star after the path it means that you have told Xcode to search recursively all sub folders of the specified path for the header and library files that you have included. Be careful with this option as it can lead to some odd build errors but that has only happened to me once so your milage may vary.

When passing the default values to a configure script it almost always installs the files in /usr/local. Given this assumption you should put /usr/local/include in the Header Search Paths box and /usr/local/lib in the Library Search Paths box. Obviously if you told the configure script to install it somewhere else then adjust the paths accordingly.

The last step is to add the library itself to the Xcode project. With your project open go to the Project menu again and select the option “Edit Active Target” (it will have the name of your application after that). This will open the following window:

Xcode Library Settings

As you can see the bottom panel already includes two libraries in my project and both of them are required dependencies. You can add your own library dependencies by just clicking the bottom “+” button and selecting the required library / framework from the list that pops up (assuming you set the paths correctly in the preceding set of instructions).

That is pretty much all there is too it. Hopefully that will have opened up a whole wealth of open source software which you can now make use of in your own projects (make sure you comply with their licenses though ); everything from audio, graphics, maths, science and language is covered in one form or another by open source software so I am sure that there will always be something that you find useful after a little searching.

As always, if you have any questions or comments please post below and I will try to get back to as soon as possible.

First things first, make sure you have installed the latest version of Xcode from the Apple Developer website (the version that comes on the Mac OS X DVDs is most likely an older version). Once that is installed you need to download the latest source code distribution of NASM from here, it is located under the Download tab.

Once you have the file downloaded (it should be called something like nasm-x-xx.tar.bz2 – if it has RC in the name download the next lowest number that does not have RC in the file name as we want to use a stable version for the purposes of learning) just double click on it to extract its contents into a folder.

Now open up the Terminal application which is located in /Applications/Utilities/ and type “cd” followed by a space. Then drag the folder that was just extracted from the nasm archive and drop it onto the Terminal window. This should place the path to the folder after the cd and space. If it looks something like:

cd ~/Downloads/nasm-2.07

then you have done it correctly. Press return and the terminal should place you inside the nasm distribution folder. Type the following commands exactly as they appear below:

./configure
 
make
 
sudo make install

after you have typed sudo make install it will ask you for your password. This is your administrator account password. It will not show anything as you type as a security measure so make sure you don’t forget how far you have got .

Now inside the Terminal window if you type

nasm -v

you should see the following (or something similar) output:

NASM version 2.07 compiled on Aug 13 2009

congratulations, you now have the latest version of NASM installed. If you have any questions please leave a comment and I will try my best to answer them (perhaps in a new blog post).