[TUT] [SOFT] Setting up an AVRStudio GCC project

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EDIT: Bugger, I didn't see that someone else already covered this. I hope this at least contains other useful info :P.

Freaks,

While AVRStudio is NOT my personal preference for a front-end to AVR-GCC (that honor goes to the Programmers Notepad project), it is for many. Unfortunately, many people seem to use mis-configured project options with AVRStudio which result in less than optimal builds of their projects. To try to rectify this, I'll try to add hints here to achieve a better programming experience and end result.

Please feel free to reply to this with corrections or hints of your own.

Fonts: Out with Courier New!
Courier New is a horrible programming font - it's hard on the eyes and just seems so blocky. Having a good programming font is the first step to a good programming environment; after all you'll probably be staring at your code for many many hours. And who wants to read something that makes your eyes bleed?

My personal preference is the Microsoft Consolas font, size 9. It's fixed width (a MUST for ALL programming fonts) and is pleasantly styled. Most importantly, it scales well both upwards and downwards and thus is great for those with poor eyesight.

Far more importantly however, is to turn on Cleartype if available on LCD monitors. It will reduce eyestrain and make everything easier to read.

Optimization: Choose what's best for YOU
AVR-GCC has quite a sophisticated optimizer under its hood - this allows it to compile your code in a manner best for either size, speed or a combination of the two. Optimization is very powerful and extreamly useful, however AVRStudio defaults to it being turned off.

To turn on the optimizer, choose Project->Configuration Options from the top menu. Change the "Optimization" combo box from it's initial setting (-O0, off) to the setting you desire and click OK.

The most common optimizer setting is -Os, which compiles for the smallest resulting code size possible. This produces quite fast code too, so it's a good choice. If speed is of the essence, choose -O3.

For more information on the different settings, check out the GCC manual online. DON'T FORGET TO READ THE AVRLIBC FAQ - there are some things you need to be aware of when writing code that will be optimized!

You should also set your AVR clock's frequency in the appropriate box on this screen; this value is used by several library routines to determine delay lengths.

Main compile flags: At no extra cost!
Also in the same Configuration Options screen are several checkboxes to the right of the optimizer combobox. I recommend checking them all.

Unsigned Chars - This makes all "char" variables unsigned by default unless explicitly declared as signed. Unsigned chars are used far more than signed, so this is a good idea.

Unsigned Bitfields - This also defaults bitfields to unsigned unless explicitly declared as signed. Useful for projects which use bitfields to manage flags in registers and variables.

Pack Structure Members - Choosing this will cause GCC to pack structure members as close together as possible (to save on RAM).

Short enums - Enums in GCC-C are ints by default (16 bits wide). This switch forces all enums to become unsigned chars in size instead.

File generation: Help at hand
A final thing to look at on the first tab of the Configuration Options screen is the three checkboxes along the bottom of the window.

Create HEX File - Ticked by default. This causes GCC to both compile your project and produce a resulting HEX binary which you can use to program into an AVR.

Generate MAP file - When ticked GCC will also create a .map file in your project's directory. This file contains information on where your global variables and functions are located in your project's binary. Useful for debugging.

Generate list file - A BRILLIANT option which many miss. This causes GCC to make a .lss file in your current directory containing both your entire C code and linked AVRLibC functions as well as the resultant assembly code after each C line. This allows you to see just what functions are taking up all your room, as well as see what exactly your lines of C are producing once compiled.

Libraries: Don't re-invent the wheel!
Another feature overlooked by many. AVRLibC, the C library that comes with GCC, has several library files which should be linked with your project so that their hand-optimized routines are used in place of GCC's generic routines.

Failing to link with the correct libraries will NOT produce any GCC errors in most cases - but your resultant binary will be larger and slower than it needs to be.

From the PROJECT->CONFIGURATION OPTIONS screen, select the "Libraries" tab. Libc and Libm should be linked to all your projects, so select them both and click the "Add Library" button.

If your project makes used of the printf or scanf functions, you should link against the appropriate libraries from this screen too. The "_min" variants of each library are the minimal versions forgoing some of the advanced features available in the larger versions.

I will be adding and revising this post in the future. Cheers!
- Dean :twisted:

Attachment(s): 

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Last Edited: Tue. Nov 14, 2006 - 05:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That font is awesome. I have made it the default in every one of my coding environments!

The rest of the Tutorial is good, too. Will reference it more when I get tired of ASM and switch to C for the AVR's.

Thanks and Best Regards!
Steve

  • "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."  -- Abraham Lincoln
  • "All right wise guy, where am I?"   -- Daffy Duck
  • "Well, we're safe for now. Thank goodness we're in a bowling alley."  -- Big Bob, Pleasantville
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers! I wanted to work in a mention of it into this tutorial, since I love it so much. I've actually surfed around quite a bit for a decent font, and that's the best one so far. Looks especially nice in Programmer's Notepad, and remains readable at very small sizes so I can fit more onto the screen at once. However, perhaps it's best feature over Courier New is the fact that zeros have a diagonal slash through them (in the style of old) which visually distinguishes then from a capitol "O".

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In case you want to have a look at the consolas font w/o having to have visual studio installed - here are the 'naked' .TTFs

Attachment(s): 

Andreas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where does the "Cleartype setting" hide ??

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I know, it is a technology only available on Windows XP. I'd write the instructions myself, but there's already a nice guide on the internet that I just Googled and found.

Personally, I prefer to download and use the Microsoft Cleartype tuning powertoy (Windows XP English only). It allows you to tune the ClearType system to suit your individual monitor, which is important. If you can use this, do so.

For an explanation of ClearType from Microsoft themselves, see here.

I can almost guarantee you'll hate Cleartype at first - I did. It will feel strange, but try to persist (also, tune with the above powertoy, as some displays follow odd pixel configurations). After a few hours, you won't notice it unless you look for it, and it'll make reading on a laptop screen a lot easier.

Don't use Cleartype on a CRT monitor. It is designed for LCDs.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean

Have applied the new Consolas Font & Cleartype.
I am running 2 monitors both act as a 1 big rectangle screen.
1st is CRT (screen is a little bit fuzzy)
2nd is LCD (screen is a GREAT)

Is there any way to just apply the Cleartype to the LCD & not effect the CRT ?
Don't tell that I need an another LCD to replace the CRT.

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ken,

Bad news. To the best of my knowledge (keep in mind that I am far from an expert in these matters!) ClearType is system wide. I would image it changes the Windows GDI DrawText (and similar) hooks, which effect all display device contexts.

Looks like you'll be needing another LCD! At least it's a great excuse to justify the expense to the significant other ;).

- Dean :twisted:

PS: Hmmm, perhaps I should make an OT tutorial on making the most accessible workspace, since you all seem to enjoy that aspect of this tutorial!

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean

Yes that is a good excuse & add that to my Xmas list.
LCD display are getting cheaper anyway.

Quote:
Hmmm, perhaps I should make an OT tutorial on making the most accessible workspace, since you all seem to enjoy that aspect of this tutorial!

Yes, good idea.

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nice tutorial dean.
i finally got mine set up too... used codevision before...

but i cant understand one thing. when they say AVR is made for C then why the hell hasn't Atmel made a normal programming environment for C programming yet? that small Gcc support in AVRstudio is just "lame" although better than nothing...
a new and separate program is what I'm crying here about. with good library and syntax checking. and at least some kind of a help file and compile all built in.
and i haven't found any good tutorial on how to set up orwhere to get command line compiler/programmer for my AVR's I'ld use that then...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bloody:

I'm not certain that Atmel had C in mind for themselves when they constructed the AVR - I think they wanted to focus on the assembly side. However, it is a known fact that the design of the AVR was made with collaboration of the IAR compiler design team. I think Atmel wanted to ensure that their new chip design was more friendly to C compilers, without focusing on higher language levels in their own offerings.

With the wide use and excellent quality of the AVR-GCC compiler, they've only recently caved and started to integrate it into their IDE.

I personally use the free Programmers Notepad software which is installed with WinAVR. I made my own AVRASM syntax highlighting scheme, and it suits me just fine. I wish it had Intellisense and smart code blocks (eg, inactive #ifdef blocks are highlighted a different colour to normal #ifdef blocks) like in the Microsoft IDE - but other than that it's great!

Swapping back and forth between AVRStudio and PN is no problem for me. I doubt Atmel could make anything better than PN - so why bother? It would still be separate from the AVRStudio IDE, and still require ALT-TABing.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Dean, Thanks for your posts re PROGMEM, etc. I was using 963 bytes of RAM on my ATmega168, and wondering why my stack was blowing away.

Because of the separate addressing/usage of .text and .data, does this fall into the "too hard" basket to get the compiler/linker to resolve this, i.e. "const" means "Use .text & get the compiler+linker to work out what is required"? (Aren't computers supposed to free us from this tedium? :?: )

For Fonts, I'm quite keen on the 8K (yes, 8 Kbyte) fonts Sheldon & Sheldon Narrow (which I mostly use), available with another similar one called ProFont(with TTF & Linux variations), here: http://www.tobias-jung.de/seekin...

Thanks again,
Alf
(ex-Vic, moved to Qld for wife's health)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't say - the internals of GCC isn't my area. I do know that the PROGMEM attribute is specific to the AVR architecture (which is a very minor GCC target) and so any modifications would have to be in the form of a time consuming to maintain patch to the AVR build of GCC (and thus unlikely to manifest). Perhaps Joerg can post more about this, as he knows a lot more about it than I.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think Jörg will confirm that it basically all boils down to GCC being a Von Neumann (single memory space) compiler while the AVR is a Harvard (multiple memory space architecture) and while work is being done for GCC to ultimately support multiple memory spaces it's early days. In the meantime the __attribute__((__progmem__)) and the pgm_???() helper functions will be needed to support the AVR's "odd" architecture

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi.. was hoping you could make a "how to make a library tutorial"

Thanks for the tutorials

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no provision in AVR Studio project setup to make a library. Create your own makefile (and build on the command line or use in AVR Studio). You can take help of the Mfile utility for creating the file. Some manual editing is probably needed though.

There is documentation on how to create a library here: http://www.nongnu.org/avr-libc/u... . The same documentation is on your hard disk if you have installed WinAVR.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that the Mfile template contains:

LIBNAME=lib$(TARGET).a
lib: $(LIBNAME)

# Create library from object files.

.SECONDARY : $(TARGET).a
.PRECIOUS : $(OBJ)
%.a: $(OBJ)
	@echo
	@echo $(MSG_CREATING_LIBRARY) $@
	$(AR) $@ $(OBJ)

So it should be as simple as "make lib" I believe having set TARGET= to the lib name without the lib.a parts and listing the sources on the SRC= and ASRC= lines.

EDIT: yup, here we have it (test.c and empty.c on the SRC= line, TARGET=test)

======================================================================
D:\test>make lib

Compiling C: test.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1843200UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save-temps -fverbose-asm -Wa,-adhlns=./test.lst  -std=gnu99 -MMD -MP -F .dep/test.o.
d test.c -o test.o

Compiling C: empty.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1843200UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes --save-temps -fverbose-asm -Wa,-adhlns=./empty.lst  -std=gnu99 -MMD -MP -F .dep/empty.
o.d empty.c -o empty.o

Creating library: libtest.a
avr-ar rcs libtest.a ./test.o ./empty.o

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I added the libc and libm libraries to 2 of my projects. Both resulted in larger compiled code. both using -Os optimization.
Both added 4 byes. 1 of them went from 1728 to 1732 bytes. Does the addition of libc and libm make faster code? It doesn't necessarily end up with smaller code.

Jim M., Rank amateur AVR guy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noting in a lib.a is actually used unless the code you write makes a call to one of it's functions. So just listing libm.a (so -lm is passed) should have no effect on code size whatsoever UNTIL you call a math function when you will be VERY glad you are linked with libm.a as it's about 1/3rd the size (and more accurate) than the 32bit default routines in libgcc.a

Not sure what you mean about adding libc.a. The user need do nothing about libc.a it's linked against automatically, always.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the OP he said libc and libm. That's why I tried it.

Quote:

From the PROJECT->CONFIGURATION OPTIONS screen, select the "Libraries" tab. Libc and Libm should be linked to all your projects, so select them both and click the "Add Library" button.

So libm is a real advantage when using 32-bit math?
What is the #include used for?

clawson wrote:
Noting in a lib.a is actually used unless the code you write makes a call to one of it's functions. So just listing libm.a (so -lm is passed) should have no effect on code size whatsoever UNTIL you call a math function when you will be VERY glad you are linked with libm.a as it's about 1/3rd the size (and more accurate) than the 32bit default routines in libgcc.a

Not sure what you mean about adding libc.a. The user need do nothing about libc.a it's linked against automatically, always.

Jim M., Rank amateur AVR guy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
In the OP he said libc and libm.

Like I say it's almost never necessary to specify -lc (add libc.a to the list). An exception is explained in this thread:

https://www.avrfreaks.net/index.p...

Quote:

So libm is a real advantage when using 32-bit math?
What is the #include used for?

libm.a is a MAJOR advantage. As soon as you #include and access any function it documents then if you don't have -lm (which Studio projects stupidly don't default to do) so that a link is made against libm.a then the linker will fall back to using the weak links in libgcc.a that provide the same functions. The problem is the routines are written in C not hand crafted AVR Asm (as with libm.a) and they are written for the 80x86 32 bit environment and don't consider the possibility that sizeof(int) is 2 not 4 as found with AVR. If you even use */+- with FP or long int types then library functions are called for those ops and the code will be that horrendous, bloaty code from the default lib. Meanwhile libm.a has been written specially for the AVR and is in the tightest, most efficient AVR Asm so it's not only about 1K versus 3K of code flash but can be 10's or even 100's of times faster and it does not have overflow errors like the 32bit code built for an 8bit processor with 16 bit int's.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah haaa. That's good to know. I do have some 32bit operations on some of my stuff. I'll check it out further. Thanks for the link.

clawson wrote:

Like I say it's almost never necessary to specify -lc (add libc.a to the list). An exception is explained in this thread:

https://www.avrfreaks.net/index.p...

Quote:

So libm is a real advantage when using 32-bit math?
What is the #include used for?

libm.a is a MAJOR advantage. As soon as you #include and access any function it documents then if you don't have -lm (which Studio projects stupidly don't default to do) so that a link is made against libm.a then the linker will fall back to using the weak links in libgcc.a that provide the same functions. The problem is the routines are written in C not hand crafted AVR Asm (as with libm.a) and they are written for the 80x86 32 bit environment and don't consider the possibility that sizeof(int) is 2 not 4 as found with AVR. If you even use */+- with FP or long int types then library functions are called for those ops and the code will be that horrendous, bloaty code from the default lib. Meanwhile libm.a has been written specially for the AVR and is in the tightest, most efficient AVR Asm so it's not only about 1K versus 3K of code flash but can be 10's or even 100's of times faster and it does not have overflow errors like the 32bit code built for an 8bit processor with 16 bit int's.

Jim M., Rank amateur AVR guy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What is the #include used for?

Including a header file and specifying a library to use when linking are two different things.

math.h contains function headers (and other stuff) that is included into the source code when the compiler is working with it.

libm.a contains actual implementations, pre-compiled, of functions that is glued together with your already compiled code by the linker.

A header file says "somewhere there is a function called foo()". A library says "Here it is!" :D

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, of course. Sorry for mixing my libs and includes.

JohanEkdahl wrote:

Including a header file and specifying a library to use when linking are two different things.

math.h contains function headers (and other stuff) that is included into the source code when the compiler is working with it.

libm.a contains actual implementations, pre-compiled, of functions that is glued together with your already compiled code by the linker.

A header file says "somewhere there is a function called foo()". A library says "Here it is!" :D

Jim M., Rank amateur AVR guy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
does anyone know how to display lines number in the editor?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR Studio does not have a line numbering option.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

too bad...