Is this assembly code invalid in Atmel Studio 6.0 ?

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

Hi!
Why do I get following message on Atmel Studio 5.0 and 6.0, but not in AVR Studio 4?

Quote:
Invalid redefinition of 'PORTB'
Invalid redefinition of 'DDRB'

http://imageshack.us/photo/my-im...

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

Do you have a .include "def.inc" at the top of the file? (as most Atmel Asm programs do). That will already be defining things like PORTB.

(It could be that AS5/6 is throwing in that .include for nothing simply because you have selected a certain AVR to build for).

Why do you feel the need to define these things yourself anyway?

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

No, I do not have any .include file at the top.

I am new in programming, I am following the examples in "Some Assembly Required" by T.Margush. I do not see any .include file in his examples.

The author is using an STK500 with atmega 16A.
I am using STK500 with a atmega 32 microprocessor.

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

But all Atmel Assembler programs should start with such an include. For example if you build for mega16 then you:

.include "m16def.inc"

at the top of the file.

As I say I think this could be a case of Atmel trying to out-smart you. In AS5/6, because you already told them which target you are building for I think they may be doing an implied .include anyway. Let me check that theory...

EDIT: yes, I simply created a new project and entered:

/*
 * AVRAssembler1.asm
 *
 *  Created: 07/03/2012 15:35:09
 *   Author: cliff
 */ 

start:
	ldi r17, 0xFF
	out DDRB, r17
loop:
	in r16, PORTB
	eor r16, r17
	out PORTB, r16
	rjmp loop

When I built I got no error about DDRB or PORB and the build output included:

		AVRASM: AVR macro assembler 2.1.51 (build 21 Nov 29 2011 15:45:53)
		Copyright (C) 1995-2011 ATMEL Corporation
		[builtin](2): Including file 'C:\Program Files\Atmel\AVR Studio 5.1\extensions\Atmel\AVRAssembler\2.1.51\AvrAssembler/Include\m16def.inc'

So, yes, there's a" hidden" .include of m16def.inc simply because I chose to target the project to mega16.

As such your programs do not need (indeed they should not) define things like DDRB and PORTB as that's going to be done automatically.

(BTW I have to question that book - it's a bit crap if it didn't know about .include - perhaps it dates from a time when such a thing did not exist?)

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

Thank you! But I still do not understand why I get "invalid redefinition of PORTB" etc.

Is your code, the same as mine, but in a different form?
Sorry, I am very new in this area.

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

Quote:

But I still did not understand why my code (from the book) did not compile.

Well the "hidden" file that's being included has stuff like:

.equ	EEDR	= 0x1d
.equ	EECR	= 0x1c
.equ	PORTA	= 0x1b
.equ	DDRA	= 0x1a
.equ	PINA	= 0x19
.equ	PORTB	= 0x18
.equ	DDRB	= 0x17
.equ	PINB	= 0x16
.equ	PORTC	= 0x15
.equ	DDRC	= 0x14
.equ	PINC	= 0x13
.equ	PORTD	= 0x12
.equ	DDRD	= 0x11
.equ	PIND	= 0x10
.equ	SPDR	= 0x0f
.equ	SPSR	= 0x0e
.equ	SPCR	= 0x0d

(that's an excerpt from the file that is actually used for mega16 in fact). So that file is already doing a lot .equ's. Then your own code was doing:

.equ PORTB = 0x18
.equ DDRB = 0x17

That's not only pointless it's redefining "PORTB" and "DDRB" when m16def.inc already defined them. Admittedly it's defining them as the same thing again but the rules in the assembler says you can only .euq a symbol once. The errors you were getting mentioned "redefinition".

The bottom line of this is that the book you are using looks like something out of the Ark! It's hugely out of date and suggesting something you haven't needed to do for years (if ever) and that now actually conflicts with normal operation of the assembler.

Quote:

And, what did you do there?
Is your code, the same as mine, but in a different form?

That has no relation to your program - just a bit of example code I made up to make use of DDRB and PORTB. What my code actually does is set PORTB to output then sits in a tight loop toggling (that's what EOR does) all the pins in the port about as fast as possible.

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

Thank you very much!!!
I now commented out the part with .equ, and finally my
code did compile.

I added STK500 from tools > Add STK500
But now I got this message:

[ERROR] Failed to open COM16. Error 0x2., ModuleName: TCF (TCF command: Tool:connect failed.)

[ERROR] Unable to connect to tool context: 'Atmel.VsIde.AvrStudio.Services.TargetService.TCF.Internal.Services.Remote.ToolProxy+ToolContext'.

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

I'd actually start a new thread about that - it's a completely different problem. It seems to be saying it cannot open COM16 - are you sure that's the port used by the USB-RS232 adapter between the PC and the STK500? And are you sure no other program (maybe Hyperterminal or something?) already has COM16 open?

(anyway, as I say, maybe start a new thread about that)

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

I actually tried with another COM port (COM2), but I still got the same message.

Here is a screenshot:

http://img51.imageshack.us/img51...

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

Quote:
But all Atmel Assembler programs should start with such an include. For example if you build for mega16 then you:
Code:
.include "m16def.inc"

at the top of the file.

Any assembler project created in AS5/AS6 shall include the correct inc file for the selected device automatically.
This was done through the toolchain properties [Project -> Properties -> Toolchain -> General -> Include File]
The ($IncludeFile) substitutes the correct *def.inc file for the selected device. Refer the attachment.

You can verify this from the output window after the project is being is built.

Just copying one such build output for your reference

[builtin](2): Including file 'C:\Program Files (x86)\Atmel\AVR Studio 5.1\extensions\Atmel\AVRAssembler\2.1.51.17\AvrAssembler/Include\m16adef.inc'
C:\Users\Documents\AVRStudio 5.1\AVRAssembler1\AVRAssembler1\AVRAssembler1.asm(9,0): Empty source file

Attachment(s): 

Regards,
Deena

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

Heyy guys.. Reviving this post!!

I am using AtmelStudio 6.0 with ATmega328P as target (Project -> Project Properties -> Device -> Current Device: ATmega328P).

 

I compiled the following code:

 

#define SREG (*((volatile unsigned char *)0x5F))
#define WDTCSR (*((volatile unsigned char *)0x60))

int main(void)
{
    SREG = 0x80; //Enable interrupt
    WDTCSR = 0x40; //Enable WatchDog
}

It compiled with no errors.

 

When it compiles, AtmelStudio should include automatically the file m328Pdef.inc, right? My doubt was.. Am I defining again SREG and WDTCSR (they are already defined at m328Pdef.inc)? So I tryed to compile without the first two line and... Error.. SREG and WDTCSR not defined!

 

I think I am probably confusing C code with Assembly code.. what leads me to the question: this m328Pdef.inc only works when I am coding in assembly?

 

-------- EDIT ----------------

Ok. I did the test and this .inc only works if you create an Assembly project! If you want the default definition programming in C, you have to include avr/io.h

I thought that, because the compiler is creating an assembly code from my C code, it would automatically include this m328Pdef.inc

 

Last Edited: Wed. Nov 16, 2016 - 11:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought that, because the compiler is creating an assembly code from my C code, it would automatically include this m328Pdef.inc

The gnu C compiler uses the gnu assembler, and it relies on the xxx.h files rather than the .inc files.

 

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

JABBA_JOE wrote:
I thought that, because the compiler is creating an assembly code from my C code, it would automatically include this m328Pdef.inc
Completely different assembler. The Atmel assembler (sometimes called Asm2 because a long time ago there was one before it) is very simple. It uses def.inc files and it is a non-linking assembler. In fact these days you don't actually need the .include of the XXXdef.inc for it because a command line switch leads to that being included anyway.

 

Meanwhile the C and C++ compilers come from a completely different source - they are open source developed by the GNU foundation. There's not just C (avr-gcc) and C++ (avr-g++) compilers but a whole raft of supporting tools:

/usr/bin$ ls avr-*
avr-addr2line  avr-c++      avr-g++        avr-gccbug  avr-gdbtui  avr-man      avr-objdump  avr-run      avr-strip
avr-ar         avr-c++filt  avr-gcc        avr-gcov    avr-gprof   avr-nm       avr-ranlib   avr-size
avr-as         avr-cpp      avr-gcc-4.5.3  avr-gdb     avr-ld      avr-objcopy  avr-readelf  avr-strings

The majority of those tools are known as "binutils" ("binary utilities" obviously). In amongst those you will see avr-as. That is the GNUG assembler (often called "gas") for the AVR8 target. It has nothing to do with Atmel's Asm2. The difference between this assembler and the Atmel one is that this is a powerful linking assembler. It does not simply generate .bin or .hex directly (as the Atmel one does) but it generates linkable load modules in ELF/DWARF2 forum. These are then inputs to avr-ld which is the binutils linker. It's the reason you can write a project in multiple C files, compile each in turn (to .o files) and then link them all together to make a final .elf file from which things like .bin and .hex can be extracted (using avr-objcopy and avr-objdump which are further binutils).

 

I always think this picture is very useful to understand the interrelation of the GNU C compiler and the binutils:

 

Image result for avr-gcc build tools

 

(I wish I could find a better version of that - it used to be in the Wiki on the old AVR Freaks but that no longer exists).

 

Hopefully you can see what goes on here. You write .c files and feed them to the C compiler (avr-gcc). The preprocessor (first stage of compilation) may then pull in accompanying .h files as further inputs. The output of the compiler are .s files which are the ASCII text assembler source that are input to the GNU assembler (avr-as). If you want to mix C and Asm (or just write only asm) you can also separately author your own .S files with avr-as source code in them. All the .s and .S are fed into the GNU assembler (avr-as) (the .S also go through C style preprocessing too first). The assembler outputs "Obj"ect files which traditionally have a .o (for "object") extension. These are then passed as input to the GNU linker (avr-ld) and it joins together any .o files (and possibly libXXX.a files which are archives made up of a number of previously built .o files). Finally it outputs a linked together .ELF file and that may be passed to avr-objcopy to extract .hex from it to be sent to the AVR.

 

You can see the assembler in action here:

$ cat avr.c
#define F_CPU 123456UL
#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    DDRB = 0xFF;
    while(1) {
        PORTB ^= 0xFF;
        _delay_ms(200);
    }
}
$ avr-gcc -Os -mmcu=atmega16 -save-temps avr.c -o avr.elf
uid23021@lxl0131u:~$ cat avr.s
	.file	"avr.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r24,lo8(-1)
	out 55-32,r24
.L2:
	in r24,56-32
	com r24
	out 56-32,r24
	 ldi r24,lo8(6172)
    ldi r25,hi8(6172)
    1:sbiw r24,1
    brne 1b
	rjmp .
	nop
	rjmp .L2
	.size	main, .-main

The "trick" I used here was -save-temps. When passed to the C compiler it says "leave behind the intermediate files you would normally delete after use". So it compiled my avr.c and then left behind the avr.s it generated from that C source. This is the (gnu as) source for the C I wrote.

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

Thanks, that was great!

 

The figure you posted helped me a lot to understand the big picture! I tryed to redraw this amazing figure. Please review it looking for errors or something we could add!

 

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

Lime green for ".h" is not "other libraries". It's more general than that - simply "any header file" - that will be some written by the programmer and some coming from various system headers