Electronic – AVR-GCC: Ports Undeclared when compiling

There are many benefits to inline functions over preprocessor macros:

• Type checking. The compiler will complain if the arguments are of incorrect type.

• No risk of multiple evaluation: macros can be dangerous when the argument is an expression, consider:

  #include <stdio.h>
  #define square(n) ((n)*(n))
  
  int main(void)
  {
      int x, i = 0;
      while (i < 10) {
          x = square(i++);
          printf("%d\r\n", x);
      }
      return 0;
  }
  

• Can include multiple lines of code without trailing backlashes.
• Inline functions have their own scope for variables and they can return a value.

Macros can be useful e.g. when concatenating tokens into code, so as to simplify some complex declarations.

Consider macros as just a dumb text replacement functionality. A good rule of thumb is to avoid function-like macros, unless there is no other viable solution.

It is a common misconception that inlining always equals faster code. Keep in mind, that every inlined call from more than one place adds up to code size. Premature optimization is not a virtue, even when working with the constrained resources of a microcontroller.

GCC interprets the inline keyword as a mere hint. There is no guarantee thet the function will actually be inlined. To have GCC inline your function regardless of optimization level, declare the function with the always_inline attribute:

void function() __attribute__((always_inline));

A little explanation of what's really going on:

The -l argument order does not normally matter on computers since most libraries are dynamically loaded (.dll, .dylib or .so) and are truly linked only at program startup time.

OTOH on the AVR all libraries are static. When linking with static libraries the linker adds to the program only the functions he currently needs from the library. If you pass -lm on the command line before a file that needs a particular function you will get unresolved symbols errors.