What is different of avr/io.h vs avr/iom32.h?

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

Hi!

My target device is ATmega32.
And use WINAVR for complier.

Is iom32.h specific for ATmega32?
I guess it should be better than general io.h.

However it is not sucess in complie.

I am a beginner.
Please let me know what wrong.

Code:

-------------------------------
#include 
//#include 
#include 

int main(void)
{
DDRB=0xFF; //all pins of PORTB declared as output
PORTB=0x00;
while(1)
{
//TODO:: Please write your application code
PORTB=0xFF;  //High State
_delay_ms(200); //delay
PORTB=0x00; //low state
_delay_ms(200); //delay
}
}

output
--------------------
> "make.exe" all

-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: LEDblinking.c
avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./LEDblinking.lst  -std=gnu99 -MMD -MP -MF .dep/LEDblinking.o.d LEDblinking.c -o LEDblinking.o 
In file included from LEDblinking.c:8:
c:/program files/winavr-20100110/lib/gcc/../../avr/include/avr/iom32.h:41:4: error: #error "Include  instead of this file."
LEDblinking.c: In function 'main':
LEDblinking.c:13: warning: implicit declaration of function '_SFR_IO8'
LEDblinking.c:13: error: lvalue required as left operand of assignment
LEDblinking.c:14: error: lvalue required as left operand of assignment
LEDblinking.c:18: error: lvalue required as left operand of assignment
LEDblinking.c:20: error: lvalue required as left operand of assignment
make.exe: *** [LEDblinking.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:02
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Suggest you read the user manual:

http://nongnu.org/avr-libc/user-...

which wrote:
This is done by diverting to the appropriate file which should never be included directly.

Last Edited: Thu. Feb 28, 2013 - 05:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you include "avr/io.h", it will look at the -mmcu=xxxxx provided on the compile command line, and include the appropriate more-specific ioXXXXX.h file,
while if you include "avr/iom32.h", your program is hardwired to only support the mega32.

io.h also includes the other "boilerplate" needed by the more specific files, like

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

The answers don't address why the OP reports getting those symptoms, with the source shown.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I believe there are some macros defined in "io.h" that are used by all the processor specific "ioxxxx.h" files. Without those macros you get these errors.

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

westfw wrote:
When you include "avr/io.h", it will look at the -mmcu=xxxxx provided on the compile command line, and include the appropriate more-specific ioXXXXX.h file,
while if you include "avr/iom32.h", your program is hardwired to only support the mega32.

io.h also includes the other "boilerplate" needed by the more specific files, like

    #include 
    #include 
    #include 
    #include 

My target BD is using atmage32.
If the for atmage32 ONLY, that should be fine too. Right?
But why not success in complie.

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

Because you don't have:

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

westfw wrote:
Because you don't have:

#include  


Could you tell me what is it?

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

You COULD just look at it, you know. It's sitting on your computer somewhere in perfectly readable form. (this may sound a little harsh, but it's an important aspect of open source software in general and C compilers in particular (even ones that are not open source.) Included .h files are SOURCE CODE, stored in a relatively standard place. (something\avr\include\avr\, usually. Buried inside of the Atmel or WINAVR install.) Looking at these can be very educational, and help resolve all sorts of errors.)

In your case, the first error was:

Quote:
warning: implicit declaration of function '_SFR_IO8'

sfr_defs.h has
Quote:
The \c file is included by all of the \c
files, which use macros defined here to make the special function register
definitions look like C variables or simple constants, depending on the
_SFR_ASM_COMPAT define.

Including the definition of _SFR_IO8 (Special Function Register in the IO space, 8bits wide...)

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

Quote:

The answers don't address why the OP reports getting those symptoms, with the source shown.

It is likely that the build error shown is not from building the source shown, but rather for

//#include  
#include 

Quote:
My target BD is using atmage32.
If the for atmage32 ONLY, that should be fine too. Right?

No, because there are more things needed than the things you include explicitly.

Why are you determined to work around ? It is designed so that everything needed is included for your specific AVR model, transparently. All you need to do for this to work is to pass the -mmcu switch to the compiler. How this is done depends on the build system you are using - of which you say nothing in your posts above.

If you want to circumvent and set up your own "include hierarchy" for your specific processor you should at least
i) read the documentation, and
ii) study what does.
IMO, circumventing is (almost?) always a meaningless thing to do.

If you think that you can optimize e.g. flash memory consumption by circumventing then you are wrong.

Doing your own include instead of using will also make it less likely that you will get any good help when you enounter a new problem with your code and pose a question here at AVRfreaks.

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

Quote:

Why are you determined to work around ?

Exactly. I know Lee says that we didn't answer the question directly. But we kind of did you know. If you just start all your AVR programs with:

#include 

(and don't attempt to include device specific files like iom32.h) then all will be happy in the rose garden.

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

Just like Gerald Ford.

Sid

Life... is a state of mind

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

thanks all
I am a beginner on it.

I am never want to build my own include file.
I see the io.h & iom32.h exist in same folder.
as title, what different between them?
I just to know about it.
I understand that necessary read more document or text book for back ground.

But book is fixed, you are alive. Different onec will have different explaination/ presentation. it is good for me(better than text book).

If you think it is wasting your time or trouble to you. I am sorry.

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

The way this is supposed to work (as the manual explains) is that when you invoke the compiler you must always tell it what micro the code is being built for. You do this with a command such as

avr-gcc -mmcu=atmega8 foo.c

Inside the compiler/preprocessor that -mmcu= leads to an internal symbol such as __AVR_ATMEGA8__ being defined. You then start every C file you write with:

#include 

and it then goes on to include some other vital files such as sfr_defs.h after that there is a huge #if/#else statement with an entry for every single AVR including an entry such as:

#if defined (__AVR_ATMEGA8__)
 #include 

and THAT is why you need not worry about including it directly. In fact, because it relies on the other things included by io.h it won't work if you just try to include it directly and if you do you will get the error shown above.

This is not rocket science so I don't understand your reluctance to do it as designed?

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

Quote:

I see the io.h & iom32.h exist in same folder.
as title, what different between them?
I just to know about it.

Shhesh--open them up with an editor and look at them.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

thanks all