(.text+0x2): undefined reference to `WDT_ADLY_1000'
11
_test\RTC_WDT.o: In function `WDT_1sec_wake':
12
(.text+0x4): undefined reference to `WDTCTL'
13
_test\RTC_WDT.o: In function `WDT_1sec_wake':
14
(.text+0x8): undefined reference to `WDTIE'
15
_test\RTC_WDT.o: In function `WDT_1sec_wake':
16
(.text+0xa): undefined reference to `IE1'
17
_test\RTC_WDT.o: In function `WDT_1sec_wake':
18
(.text+0xe): undefined reference to `GIE'
19
_test\RTC_WDT.o: In function `WDT_1sec_wake':
20
(.text+0x10): undefined reference to `SR'
21
Build error occurred, build is stopped
22
Time consumed: 1266 ms.
Die references von WDT_ADLY_1000, WDTCTL, WDTIE, IE1, GIE, SR sind in
"wdt_a.h" definiert.
Warum findet der ggc4 sie nicht? Oder habe ich was falsch deklariert?
Grüße
Du rufst den Assembler direkt auf, der hat keine Ahnung, was ein
#include ist. Vermutlich wird ihm das # einfach ein Kommentar-
zeichen sein. ;-)
Der gängige Weg ist es, die Datei mit dem Suffix .S zu benennen
(großes "S"!) und sie dem Compiler zum Fraß vorzuwerfen. Das große
S ist dem ein Zeichen, dass er die Datei zuerst durch den Präprozessor
jagen soll und dann dem Assembler füttern.
All die Konstanten da drin, die dir der Linker anmeckert, sollte der
Assembler gar nicht mehr symbolisch sehen, sondern bereits durch den
Präprozessor aufgelöst numerisch. Unix-Assembler (zu denen der GNU
Assembler gehört) beklagen sich jedoch nicht über Dinge, die sie nicht
kennen, sondern nehmen sie stillschweigend als "global undefined" in
die Symboltabelle auf, in der Hoffnung, dass der Linker das dann schon
irgendwie parat haben wird. Daher kommt die Meckerei nicht vom
Assembler selbst, sondern erst vom Linker.
J. R. schrieb:> msp430-as.exe -mmcu=msp430x449 -IC:\mspgcc4\msp430\include ...
Du sollst bitte den Compiler aufrufen damit, nicht den Assembler.
Das Kommando "msp430-gcc" (das .exe darfst du dir getrost klemmen)
ist der sogenannte Compiler-Treiber, der die einzelnen Stufen der
"Backends" anhand der Dateiendung der Quelldatei ermittelt und der
Reihenfolge nach aufruft. Der braucht (außer den -I-Optionen) nur
noch die Option -c, für "compilier' das mal".
> Muss mann noch an den Linker Flags was drehen?
Nein, zum Geier[tm]. Der Linker hat damit nichts zu tun, diese
Konstanten sollen bereits vor dem Assemblieren in Zahlen verwandelt
werden, und dafür zuständig ist der Präprozessor.
Der Linker hat exakt Null Ahnung davon, was ein WDT_ADLY_1000 sein
könnte, und der muss diese Ahnung auch nicht haben.
J. R. schrieb:> ../_test/RTC_WDT.S:75: Error: unknown pseudo-op: `.cdecls'> ../_test/RTC_WDT.S:76: Error: unknown pseudo-op: `.ref'> ../_test/RTC_WDT.S:77: Error: unknown pseudo-op: `.def'
Ja, die hattest du doch schon rauskommentiert.
Da musst du wohl im MSP430-Assemblerhandbuch nachlesen, wofür die
gut sein sollen, um dann das Pendant vom GNU-Assembler zu finden.
Aber wenn ich mir die so ansehe, braucht man die wohl nicht.
J. R. schrieb:> bzw> _test\RTC_WDT.o: In function `WDT_1sec_wake':> (.text+0x2): undefined reference to `WDT_ADLY_1000'
Das heißt aber, dass der Präprozessor da wohl nach wie vor nicht
drüber gelaufen ist. Lass ihn mal manuell laufen, indem du das
-c durch ein -E ersetzt und bei -o einen entsprechend anderen
Dateinamen angibst. Schau dir an, was der Assembler dann gefüttert
bekommt.
Die # und & sehen überaus seltsam aus für den GNU-Assembler.
Was sind Kommentarzeichen? @? ;? Gibt es eine Register-Prefix?
Konstanten-Prefix?
Schau dir einfach die asm-Ausgabe des Compilers an (-save-temps) und du
hast eine gute Basis, wie korrekter Assembler auszusehen hat:
Funktionsdefinitionen, Symbole, Labels, Kommentare, Direktiven, ...
Johann L. schrieb:> Die # und & sehen überaus seltsam aus für den GNU-Assembler.
# für Direktoperanden war auch schon früher üblich. Der GNU-Assembler
richtet sich da oft genug nach der Syntax des originalen Assemblers
für den jeweiligen Prozessor (sofern sich das irgendwie einrichten
lässt), insofern kann ich mir das schon vorstellen.
Jörg Wunsch schrieb:> Johann L. schrieb:>> Die # und & sehen überaus seltsam aus für den GNU-Assembler.>> # für Direktoperanden war auch schon früher üblich.
Auch wenn vorher der C-Präprozessor drüber soll?
Johann L. schrieb:>> # für Direktoperanden war auch schon früher üblich.>> Auch wenn vorher der C-Präprozessor drüber soll?
Ja, der reagiert doch nur auf Zeilen, die auf den regulären Ausdruck
"^\s*#" passen. Da ein Direktoperand immer noch (mindestens) einen
Operator voran hat, kann es nie zu einer Verwechslung kommen.
Jörg Wunsch schrieb:> Das heißt aber, dass der Präprozessor da wohl nach wie vor nicht> drüber gelaufen ist. Lass ihn mal manuell laufen, indem du das> -c durch ein -E ersetzt und bei -o einen entsprechend anderen> Dateinamen angibst. Schau dir an, was der Assembler dann gefüttert> bekommt.
Also:
Jörg Wunsch schrieb:>> ../_test/RTC_WDT.S:75: Error: unknown pseudo-op: `.cdecls'
Im
MSP430 Assembly Language Tools v 3.3
User's Guide
http://focus.ti.com/lit/ug/slau131e/slau131e.pdf
steht
"You can use the .cdecls assembler directive to share C headers
containing declarations and prototypes between C and assembly code. Any
legal C/C++ can be used in a .cdecls block and the C/C++ declarations
will cause suitable assembly to be generated automatically, allowing you
to reference the
C/C++ constructs in assembly code."
Weitere Details dort auf S.73:
The .cdecls options control whether the code is treated as C or C++
code; and how the.cdecls block and converted code are presented. Options
must be separated by commas; they can appear in any order:
C = Treat the code in the .cdecls block as C source code (default).
LIST = Include the converted assembly code in any listing file generated
for the containing assembly file."
Er holt sich dort also die Definitionen von WDT_ADLY_1000 etc?
Wie kann ich ihm das mithilfe von mps430gcc beibringen?
Grüße
J. R. schrieb:> liefert als RTC-WDTX.o:> [avrasm]# 1 "RTC_WDT.S"> # 1 "<built-in>"> # 1 "<command line>"> # 1 "RTC_WDT.S"
(und dann keine weiteren #-Zeilen)
Das heißt, da ist kein include-File drüber gelaufen.
Weiter oben hast du da noch
#include "msp430x44x.h"
#include "wdt_a.h"
stehen, und letztere Datei sollte die fehlenden Symbole bringen.
J. R. schrieb:> Die header files der ggc4 sollte der compiler doch verstehen?
Ja. Da musst du wohl nun denjenigen fragen, der diese Datei (wdt_a.h)
geschrieben hat. An dieser Stelle kann ich dir nicht mehr helfen, da
ich vom MSP430 und dessen GCC-Portierung keine Ahnung habe.
