Tool-Chain für AVR Assembler ohne GUI

[Walter K. (Gast)]

Hallo,

ich habe den Assembler-Source-Code für ein LED Blink für den
mega328p

in den ports von FreeBSD habe ich den avr-gcc und zum übertragen
avrdude gefunden.

/* Compiler Aufruf - fuer den assembler code - es ist kein
Inline-C */
avr-gcc -c  test.sx -mmcu=atmega328p  -o test.o

/* Linker */
avr-ld test.o -o test.elf

/* Intelkonforme Hexdatei mit MaschinenCode erzeugen */
avr-objcopy -O ihex test.elf test.hex


Passt das so?

[Oliver S. (oliverso)]

Compiler und linker werden dir schon mitteilen, wenn denen was nicht 
passt. Also tipp es einfach mal ein, und schau, was passiert.

Oliver

[Jim M. (turboj)]

Walter K. schrieb:
> /* Linker */
> avr-ld test.o -o test.elf

Wird nicht passen, AVR ist multi-lib. Da nimmt man zum Linken den GCC 
als Frontend, also auch einfach "avr-gcc". Auch da ist der MCU Typ 
anzugeben.

[Walter K. (Gast)]

Jim M. schrieb:
> Wird nicht passen, AVR ist multi-lib. Da nimmt man zum Linken den GCC
> als Frontend, also auch einfach "avr-gcc"

Ja o.k. Danke

Ich nehm dann einfach hier aus Euren Wiki das Make-File und pass das an:

TARGET=blink
MCU=atmega328p
SOURCES=blink.c

PROGRAMMER=arduino
#auskommentieren für automatische Wahl
PORT=-P/dev/ttyS0
BAUD=-B115200

#Ab hier nichts verändern
OBJECTS=$(SOURCES:.c=.o)
CFLAGS=-c -Os
LDFLAGS=

all: hex eeprom

hex: $(TARGET).hex

eeprom: $(TARGET)_eeprom.hex

$(TARGET).hex: $(TARGET).elf
  avr-objcopy -O ihex -j .data -j .text $(TARGET).elf $(TARGET).hex

$(TARGET)_eeprom.hex: $(TARGET).elf
  avr-objcopy -O ihex -j .eeprom --change-section-lma .eeprom=1 
$(TARGET).elf $(TARGET)_eeprom.hex

$(TARGET).elf: $(OBJECTS)
  avr-gcc $(LDFLAGS) -mmcu=$(MCU) $(OBJECTS) -o $(TARGET).elf

.c.o:
  avr-gcc $(CFLAGS) -mmcu=$(MCU) $< -o $@

size:
  avr-size --mcu=$(MCU) -C $(TARGET).elf

program:
  avrdude -p$(MCU) $(PORT) $(BAUD) -c$(PROGRAMMER) 
-Uflash:w:$(TARGET).hex:a

clean_tmp:
  rm -rf *.o
  rm -rf *.elf

clean:
  rm -rf *.o
  rm -rf *.elf
  rm -rf *.hex

[Oliver S. (oliverso)]

Man könnte auch einfach mal die Doku lesen.

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

Oliver

[Walter K. (Gast)]

Oliver S. schrieb:
> Man könnte auch einfach mal die Doku lesen.

Man könnte auch einfach schweigen - wenn man ausser
RTFM nichts mittzuteilen hat ;-)

[guest (Gast)]

Alles bisher gesagte ist aber nur dann richtig, wenn es sich bei dem 
"Assembler-Source-Code" auch tatsächlich um welchen für den Assembler 
aus dem avr-gcc Packet handelt.
Sollten die Sourcen allerdings für den "AVR Assembler" von 
Atmel/Microchip sein, dürfte es etliche Fehlermeldungen hageln.
http://www.atmel.com/webdoc/avrassembler/

[hunsbuckel (Gast)]

guest schrieb:
> Alles bisher gesagte ist aber nur dann richtig, wenn es sich bei
> dem "Assembler-Source-Code" auch tatsächlich um welchen für den
> Assembler aus dem avr-gcc Packet handelt.
> Sollten die Sourcen allerdings für den "AVR Assembler" von
> Atmel/Microchip sein, dürfte es etliche Fehlermeldungen hageln.
> http://www.atmel.com/webdoc/avrassembler/

Das ist mir schon klar, Danke für den Hinweis.
Allerdings entsteht jetzt die Frage, ob der Ansatz mit avr-gcc zum 
Lernen und Einstieg richtig ist.
Ich hatte den avr-gcc gewählt, weil ich selbst aus dem C Bereich komme - 
später sicher auch mehr mit C und Inline Assembler machen werde ... für 
den Anfang aber erst mal mit reinen Assembler beginnen wollte

[guest (Gast)]

hunsbuckel schrieb:
> Allerdings entsteht jetzt die Frage, ob der Ansatz mit avr-gcc zum
> Lernen und Einstieg richtig ist.
> Ich hatte den avr-gcc gewählt, weil ich selbst aus dem C Bereich komme -
> später sicher auch mehr mit C und Inline Assembler machen werde ... für
> den Anfang aber erst mal mit reinen Assembler beginnen wollte

Mach es umgekehrt. Fang mit C an und ersetze dann einzelne Funktionen in 
Assembler. Mit avr-gcc problemlos, mit avrasm2 unmöglich.
Viele Beispiele sind allerdings für avrasm2, von daher spricht auch 
einiges für das Atmel/Microchip Teil.

[Rolf M. (rmagnus)]

Jim M. schrieb:
> Walter K. schrieb:
>> /* Linker */
>> avr-ld test.o -o test.elf
>
> Wird nicht passen, AVR ist multi-lib. Da nimmt man zum Linken den GCC
> als Frontend, also auch einfach "avr-gcc". Auch da ist der MCU Typ
> anzugeben.

Dann muss man aber noch explizit dafür sorgen, dass Startup-Code und 
Standardlib für C nicht mitgelinkt werden, also -nostdlib als 
zusätzlichen Parameter übergeben.

[Jörg W. (dl8dtl) (Moderator)]

Walter K. schrieb:
> /* Intelkonforme Hexdatei mit MaschinenCode erzeugen */
> avr-objcopy -O ihex test.elf test.hex

Kannst du einsparen, muss man nicht haben.  AVRDUDE kann seit geraumer
Zeit die ELF-Files auch direkt lesen.  Dabei ist ein „-U foo.elf“ die
Kurzform für „-U flash:w:foo.elf:e“, d. h. es wird nur der für den
Flash bestimmte Anteil aus dem ELF-File genommen und programmiert.

[Johann L. (gjlayde)]

Rolf M. schrieb:
> Jim M. schrieb:
>> Walter K. schrieb:
>>> /* Linker */
>>> avr-ld test.o -o test.elf
>>
>> Wird nicht passen, AVR ist multi-lib. Da nimmt man zum Linken den GCC
>> als Frontend, also auch einfach "avr-gcc". Auch da ist der MCU Typ
>> anzugeben.
>
> Dann muss man aber noch explizit dafür sorgen, dass Startup-Code und
> Standardlib für C nicht mitgelinkt werden, also -nostdlib als
> zusätzlichen Parameter übergeben.

Müssen?

Man kann auch den C Startup-Code in Assembler verwenden, etwa für

.data
.global var
var:
    .word 42
;; Triggert Teil des Startup-Codes
.global __do_copy_data

bereits beim Einsprungpunkt in den Assmbler-Code (main) initialisiert zu 
haben.

Außerdem hat man damit bereits eine Vector-Tabelle aus dem crt und man 
kann also auch ohne jegliches C-Modul vom C-Startup profitieren. Ein 
minimales main.S wäre dann z.B.:

#include <avr/io.h>

.text

;;; C-Startup definiert vectors-Tabelle, und avr/io.h definiert
;;; ISR names wie INT0_vect.

.global INT0_vect
INT0_vect:
    ;; Code
    reti

;;; C-Startup springt nach Initialisierung von .data und .bss nach main

.global  main
main:
    ;; Code

und einfach übersetzen mit

avr-gcc main.S -o main.elf -mmcu=...