Forum: Mikrocontroller und Digitale Elektronik Assembler in AVR Studio 6.1?


von Bert S. (kautschuck)


Lesenswert?

Hallo,
ich kann mittlerweile erfolgreich ein C-Programm von AVR Studio 6.1 auf 
mein Atmega8A bringen und ausführen. Ich möchte aber Assembler 
programmieren und nicht C. Also habe ich in AVR Studio 6.1 ein 
Assembler Projekt erstellt und
möchte dass nun Assemblieren und die Hex auf den uC laden. Wenn ich in 
AVR Studio "build solutions" ausführe, wird doch ein Assembler Programm 
assembliert? Ich kriege aber 499 Fehler, alleine durch .include 
"m8def.inc"
also wird anscheinden nicht assembliert, doch wie mach ich das dann?

Gruss Bert
1
.include "m8def.inc"
2
    ldi r16, 0xFF       ; lade Arbeitsregister r16 mit der Konstanten 0xFF
3
    out DDRB, r16       ; Inhalt von r16 ins IO-Register DDRB ausgeben
4
 
5
    ldi r16, 0b11111100 ; 0b11111100 in r16 laden
6
    out PORTB, r16      ; r16 ins IO-Register PORTB ausgeben
7
 end: rjmp end

von Thorsten R. Ollemann (Gast)


Lesenswert?

>AVR Studio "build solutions" ausführe, wird doch ein Assembler Programm
>assembliert? Ich kriege aber 499 Fehler, alleine durch .include

Hat das File die richtige Endung?

Bert Siegfried schrieb:
> mein Atmega8A bringen und ausführen. Ich möchte aber Assembler
> programmieren und nicht C. Also habe ich in AVR Studio 6.1 ein

Willst Du das wirklich? Wie wäre es mit inline-Assembler, wenn C nicht 
mehr ausreicht?

von Bert S. (kautschuck)


Angehängte Dateien:

Lesenswert?

Wenn ich das File in AVR Studio erstelle hat es die Endung .asm, sollte 
also eigentlich richtig sein. Ja, möchte am Anfang mal nur in Assembler 
programmieren. Im Anhang noch die Fehlermeldung.

Gruss Bert

von Kai S. (kai1986)


Lesenswert?

Hallo,

lass mal die Zeile mit dem .include weg. Bei erstellen von einem 
Assembler Projekt wählst du ja den µC schon aus. Das AVR Studio macht 
den include damit schon automatisch.

Gruß Kai

von Dietrich L. (dietrichl)


Lesenswert?

Ich habe mal in der ASM-Hilfe der Version 4.19 geschaut: da gibt es
1
.include "m8def.inc"
nicht. Da heißt die Directive
1
#include ...
Und ist die "m8def.inc" auch die Assembler-Version und nicht die 
C-Version?

Gruß Dietrich

von Sascha (Gast)


Lesenswert?

Hallo,
wenn du C und Assembler im mixed mode betreibst, gehe ich davon aus, 
dass der gcc Compiler benutzt wird und somit auch der Linker die 
Programmteile zusammenfügen muss. Es ist schon ein Jahr her, dass ich 
damit gearbeitet habe, aber ich glaube das Assembler File braucht die 
Endung .s . Auch muss du in dem Assembler File die Codesection für den 
Linker angeben und einen Namen der für das File steht. Das mit dem Namen 
ist ganz praktisch, weil in der Auflistung des Linkers man dann eine 
klasse Übersicht bekommt.
Alle Variablen und Code-Labels die zu anderen Files sichtbar werden 
sollen muss man mit Global oder Public declarieren. Alle Variablen die 
man von anderen Files nutzen will mit EXTERN.

Gruß Sascha

von Bert S. (kautschuck)


Lesenswert?

Vielen Dank für die Hilfe und Tips, es lag an .include "m8def.inc", das 
schon von AVR Studio importiert wurde.

Gruss Bert

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Dietrich L. schrieb:

> Ich habe mal in der ASM-Hilfe der Version 4.19 geschaut: da gibt
> es.include "m8def.inc"
> nicht.

Doch, natürlich gibt es die. Wäre es nicht so, würde sich keines meiner 
Programme übersetzen lassen...

> Da heißt die Directive#include ...

Die gibt's außerdem auch noch.

Der Assembler unterstützt sowohl den eigenen Präprozessor als auch den 
von C.

Man sollte sich aber nach Möglichkeit davor hüten, beides zu mischen, 
das kann ziemlich schief gehen, wenn man nicht ganz genau weiß, was man 
da tut.

Meine Empfehlung: Für Asm-Programme ausschließlich den (mächtigeren) 
Präprozessor des Assemblers benutzen.

Einzige Ausnahme: funktionsartige Macros, sofern nötig und für die 
Anwendung sinnvoll. Denn die gehen nur mit dem C-Präprozessor. Wenn man 
diese aber benutzt, dann unbedingt darauf achten, daß die 
"Funktionsparameter" keine Vorwärtsreferenzen enthalten, also Verweise 
auf Präprozessor-Symbole, die erst später beim Assembliervorgang einen 
Wert zugewiesen bekommen. Dabei kann ganz fürchterliche Scheiße 
passieren und zwar u.U. sogar ohne eine entsprechende Warnung des 
Präprozessors. Genau das macht die Sache so gefährlich, man sucht sich 
dann nämlich einen Wolf, um das Problem zu finden...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.