http://www.8051projects.net/ Learn to make simple microcontroller projects, pic, 8051, avr and arm projects. download 8051 projects, tutorials, libraries, sample codes. join the microcontroller discussion forum and ask doubts regarding electronics. the best source for 8051 over internet. en-gb 2009-01-08T06:00:54-08:00 contact@nospam.com hourly 1 2000-01-01T12:00+00:00 http://www.8051projects.net/forum-t14724.html 2009-01-08T06:00:54-08:00 Hi guys,these are some of the FAQs from the avrlib -gcc manual which i found interesting especially for reducing the code length after compilation and i thought might be useful for AVR programmers1.Q. My UART is generating nonsense! My ATmega128 keeps crashing! Port F is completely broken!A. Well, certain odd problems arise out of the situation that the AVR devices as shipped by Atmel often come with a default fuse bit configuration that doesn't match the user's expectations. Here is a list of things to care for: * All devices that have an internal RC oscillator ship with the fuse enabled that causes the device to run off this oscillator, instead of an external crystal. This often remains unnoticed until the first attempt is made to use something critical in timing, like UART communication. * The ATmega128 ships with the fuse enabled that turns this device into ATmega103 compatibility mode. This means that some ports are not fully usable, and in particular that the internal SRAM is located at lower addresses. Since by default, the stack is located at the top of internal SRAM, a program compiled for an ATmega128 running on such a device will immediately crash upon the first function call (or rather, upon the first function return). * Devices with a JTAG interface have the JTAGEN fuse programmed by default. This will make the respective port pins that are used for the JTAG interface unavailable for regular IO.2.Q. I get "undefined reference to..." for functions like "sin()"A. In order to access the mathematical functions that are declared in <math.h>, the linker needs to be told to also link the mathematical library, libm.a.Typically, system libraries like libm.a are given to the final C compiler command line that performs the linking step by adding a flag -lm at the end. (That is, the initial lib and the filename suffix from the library are written immediately after a -l flag. So for a libfoo.a library, -lfoo needs to be provided.) This will make the linker search the library in a path known to the system.An alternative would be to specify the full path to the libm.a file at the same place on the command line, i. e. after all the object files (*.o). However, since this requires knowledge of where the build system will exactly find those library files, this is deprecated for system libraries.Note that u can add the libm.a even if u are using simple floating point calculations in ur code and not the math functions.The library significantly reduces code size.To add the libm.a for the linker with the AVR studio IDE, go to Projects ->> Configuration options -->Librariesthere u can select libm.a and click on add object to add the item and display it on the right side of the box.now close the window and compile ur code again and see the difference!!3.Q. Shouldn't I initialize all my variables?A. Global and static variables are guaranteed to be initialized to 0 by the C standard. avr-gcc does this by placing the appropriate code into section .init4 (see The .initN Sections). With respect to the standard, this sentence is somewhat simplified (because the standard allows for machines where the actual bit pattern used differs from all bits being 0), but for the AVR target, in general, all integer-type variables are set to 0, all pointers to a NULL pointer, and all floating-point variables to 0.0.As long as these variables are not initialized (i. e. they don't have an equal sign and an initialization expression to the right within the definition of the variable), they go into the .bss section of the file. This section simply records the size of the variable, but otherwise doesn't consume space, neither within the object file nor within flash memory. (Of course, being a variable, it will consume space in the target's SRAM.)In contrast, global and static variables that have an initializer go into the .data section of the file. This will cause them to consume space in the object file (in order to record the initializing value), and in the flash ROM of the target device. The latter is needed since the flash ROM is the only way that the compiler can tell the target device the value this variable is going to be initialized to.Now if some programmer "wants to make doubly sure" their variables really get a 0 at program startup, and adds an initializer just containing 0 on the right-hand side, they waste space. While this waste of space applies to virtually any platform C is implemented on, it's usually not noticeable on larger machines like PCs, while the waste of flash ROM storage can be very painful on a small microcontroller like the AVR.So in general, variables should only be explicitly initialized if the initial value is non-zero.Note: Recent versions of GCC are now smart enough to detect this situation, and revert variables that are explicitly initialized to 0 to the .bss section. Still, other compilers might not do that optimization, and as the C standard guarantees the initialization, it is safe to rely on it. 4.Q. Which -O flag to use?A. There's a common misconception that larger numbers behind the -O option might automatically cause "better" optimization. First, there's no universal definition for "better", with optimization often being a speed vs. code size tradeoff. See the detailed discussion for which option affects which part of the code generation.A test case was run on an ATmega128 to judge the effect of compiling the library itself using different optimization levels. The following table lists the results. The test case consisted of around 2 KB of strings to sort. Test #1 used qsort() using the standard library strcmp(), test #2 used a function that sorted the strings by their size (thus had two calls to strlen() per invocation).When comparing the resulting code size, it should be noted that a floating point version of fvprintf() was linked into the binary (in order to print out the time elapsed) which is entirely not affected by the different optimization levels, and added about 2.5 KB to the code.Optimization flags Size of .text Time for test #1 Time for test #2-O3 6898 903 µs 19.7 ms-O2 6666 972 µs 20.1 ms-Os 6618 955 µs 20.1 ms-Os -mcall-prologues 6474 972 µs 20.1 ms(The difference between 955 µs and 972 µs was just a single timer-tick, so take this with a grain of salt.)So generally, it seems -Os -mcall-prologues is the most universal "best" optimization level. Only applications that need to get the last few percent of speed benefit from using -O3.U can set the -O option (default -O0) in theAVRstudio IDE by navigating to the following rojects -> Configuration Options -> General -> OptimizationFor more detailed documentation u can always look into this link:http://www.nongnu.org/avr-libc/enjoy programming !Try out the newer version of AVRstudio release 4.15. It also contains a fully funcional disassembler. http://www.8051projects.net/forum-t14724.html 2009-01-08T06:00:54-08:00 Ajay nice pdi