Simpler alternative to #if ! defined() ... #endif ?

i need to define AVR_ATmega328P definition and include file "m328.h" in sketch code

No, define AVR_ATmega328P and then include avr/io.h (it will include iom328p.h for you, but it does some other things that you want as well.)

Actually, define AVR_ATmega328P and then include Arduino.h; Arduino.h includes io.h, io.h includes iom328p.h

i found avr, avr-3, avr-4 folders

There are two places where "avr-3" and "avr-4" shows up.

One is near the top-level of the toolchain directory, and is a consequence of some sort of incompatibility between compiler versions 4.3.x and 3.4.x; I don't know the details, but avr-gcc packages (winavr, crosspack, linux installs) from those days include TWO versions of the compiler, selectable with avr-gcc-select. Arduino only uses 4.x Hopefully there are lots of symlinks involved, but I'm not sure that they survive the sort of packaging and unpackaging and re-packaging that has gone on.

The other is that in addition to the specific CPUs like AVR_ATmega328P, the avr chips are also divided into several "architectures" with minor but significant differences to compiler tools. These are unimaginatively called "avr1", "avr3.5", and so on, and affect things like libraries, startup code, and linker scripts.

You really want to use -mcu= and not just define the appropriate macros. The -mcu= option controls what instructions the compiler generates. Different boards might have different instructions. If whatever default your gcc was built for uses instructions that your machine does not support, your program won’t run. If the default is the least common denominator, your program might be bigger and slower than if you used the correct -mcu= option.

westfw:

i found avr, avr-3, avr-4 folders

There are two places where "avr-3" and "avr-4" shows up.

One is near the top-level of the toolchain directory, and is a consequence of some sort of incompatibility between compiler versions 4.3.x and 3.4.x; I don't know the details, but avr-gcc packages (winavr, crosspack, linux installs) from those days include TWO versions of the compiler, selectable with avr-gcc-select. Arduino only uses 4.x Hopefully there are lots of symlinks involved, but I'm not sure that they survive the sort of packaging and unpackaging and re-packaging that has gone on.

okay, now i know it.

The other is that in addition to the specific CPUs like AVR_ATmega328P, the avr chips are also divided into several "architectures" with minor but significant differences to compiler tools. These are unimaginatively called "avr1", "avr3.5", and so on, and affect things like libraries, startup code, and linker scripts.

great to know that too! (i've seen that folders but also did not understand the meaning). that relates to these link too: http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

thank you, now it becomes more and more clear

MichaelMeissner:
You really want to use -mcu= and not just define the appropriate macros. The -mcu= option controls what instructions the compiler generates. Different boards might have different instructions. If whatever default your gcc was built for uses instructions that your machine does not support, your program won’t run. If the default is the least common denominator, your program might be bigger and slower than if you used the correct -mcu= option.

i would be happy to just use it, but unfortunately i can’t as my toolchain is not gcc and i have to do pretty the same as avr-gcc does behind the scene. fortunately, the community is very experienced and friendly to help me with it.

4ntoine: i would be happy to just use it, but unfortunately i can't as my toolchain is not gcc and i have to do pretty the same as avr-gcc does behind the scene. fortunately, the community is very experienced and friendly to help me with it.

Fair enough, but the point is you should use whatever options are appropriate to your compiler to target the exact board you are using.

Also i can see desktop IDE adds core includes (i know core for the board - it’s written in boards.txt file):
all .h files in core folder so for “Uno” it will be all .h files in …/cores/arduino:
-I … /cores/arduino

These are the Arduino core libraries, appropriate to have paths added via -I

then i add constant includes for all the board types
-I … avr/avr/include
-I … "avr/lib/gcc/avr/4.7/include
:
Ive found “UBRRH” definition in files:
tools/avr/avr-3/include/avr/iom163.h
tools/avr/avr-3/include/avr/iom165.h
and this makes me think i have to add such files into include list/paths, but i need to know the correlation between board type and header filename.

These however, are “system” include files, whose path should be inherent in the compiler build/installation.
tools/avr/include is essentially equivalent to /usr/include on a native compiler installation. It will be a symlink that points to either the avr-3 or avr-4 directory depending on which one has been set up (always 4 for Arduino.) This is where the includes for the compiler core defines and avr-libc live, and I’m not sure that you should be adding explicit -I options for them

I can confirm it works now and Serial extern var (as HardwareSerial) is available now (it confirms avr/io.h included needed file and HardwareSerial found required definition) though autocomplete feature works not as i expect. Thank you, guys!