AVR-AS - Controller gibt keinen Mucks von sich

[ReSeT]

Hallo liebe Robotergemeinde,

ich beschäftige mich nun seit einigen Wochen mit der Atmel Plattform und habe den Umstieg von Microchip erfolgreich hinter mich gebracht.

Das Programmieren mit dem AVR-GCC, einem selbstgebauten STK200 Programmieradapter und AVRDUDE funktioniert problemlos. Nun mein Problem:

Folgendes C-Code Fragment:

int main(void) {

	DDRA = 0xFF;

	while(1) {

		PORTA = 0x00;
		PORTA = 0xFF;

	}


	return 0;
}

Schaltet alle Pins an PORTA abwechselnd ein und aus, kann ich auch schön auf dem Oszilloskop sehen.

Nehme ich das gleiche in Assembler:

#include <avr/io.h>

.text

dir = 16
dat = 17

.global main

main:
        ldi     dir,0xFF
        out     DDRA,dir

loop:
	ldi     dat,0xFF
        out     PORTA,dat
        ldi     dat,0x00
	out     PORTA,dat

        rjmp    loop     /* loop forever */

	.end

dann tut sich gar nichts. Ich habe alle möglichen Quellen durchforstet, und bin der Meinung, daß das Assemblerprogramm so funktionieren sollte.

Habe ich hier irgendwas übersehen, oder müssen noch spezielle Einstellungen durchgeführt werden? Ich benutze einen ATMega32 und erzeuge und programmiere
das Hexfile so:

avr-gcc -o main.elf -g -mmcu=atmega32 -Wa,-gstabs -Os main.S
avr-objcopy -j .data -j .text -O ihex main.elf main.hex
avrdude -p m32 -c stk200 -U flash:w:main.hex -v -U lfuse:w:0xff:m -U hfuse:w:0xd9:m

Der Programmieradapter und mein Schaltungsaufbau funktionieren mit der C-Variante ja einwandfrei, also kann es ja daran wohl nicht liegen.

Bin für jeden Hinweis dankbar.

Gruß
ReSeT

[ReSeT]

So, habs dann nach stundenlanger Suche im Netz selbst rausgefunden:

statt:

out     PORTA,dat

muss es heissen:

out _SFR_IO_ADDR(PORTA), dat

_SFR_IO_ADDR scheint ein Makro zu sein, was die tatsächliche Port Adresse ermittelt.

Programmiert hier eigentlich niemand Atmels mit dem Linux Assembler?

[Besserwessi]

Bei den Atmels wird sehr oft das AVRstudio benutz, wegen des integriertem Simulators. Das mit den macros _SFR_IO_Addr ist was GCC speziefisches. Den Assembler über GCC nutze ich nur wenn ich ASM mit C kombiniere.

[SprinterSB]

_SFR_IO_ADDR scheint ein Makro zu sein, was die tatsächliche Port Adresse ermittelt.

Ein SFR im I/O-Bereich hat zwei Adressen: Seine Adresse im RAM, also die ADresse, wo es hingemappt ist, und seine I/O-Adresse.

Die beiden Adressen unterscheiden sich um einen Offset von 0x20.

RAM-Adressen werden verwendet zusammen mit LDS, STS, ...
I/O-Adressen werden verwendet mit IN, OUT, CBI, SBIS, ...

Die Header der avr-libc stellen nur die RAM-Adresse zur Verfügung, für die I/O-Adresse muss diese also angepasst werden. Das macht das Makro.

Steht aber alles in der Doku zur avr-libc...

http://www.nongnu.org/avr-libc/user-...assembler.html
http://www.nongnu.org/avr-libc/user-...fr__notes.html

Wenn man Software einsetzt/einzusetzen gedenkt, sollte man in Betracht ziehen, auch ihre Doku zu lesen...

[ReSeT]

Wenn man Software einsetzt/einzusetzen gedenkt, sollte man in Betracht ziehen, auch ihre Doku zu lesen...

Manchmal ist es aber auch einfacher, Leute zu fragen, die sich bereits damit auskennen.

[SprinterSB]

Klaro. Du hast ja erst mit den avr-Tools angefangen, und da sieht man manchmal den Wald vor lauter Bäumen nicht, vor allem bei vertrackten Kleinigkeiten, die große Wirkung haben wie hier.

Manchmal ist es ganz hilfreich, sich anzuschauen, was avr-gcc bzw. die avr-Tools so treiben:

https://www.roboternetz.de/wissen/in...en_mit_avr-gcc

avr-as tickt etwas anders als der Atmel-Assembler für AVR, er kennt andere Direktiven, und and Atmel-asm wird auch kein elf-Objekt erzeugt, gegen das gelinkt wird.