Eclipse kompiliert asm startup nicht bei STM32

[Andreas L. (argon)]

Hallo, wenn ich in Eclipse ein Beispielprojekt für den STM32 anlege kann 
dies kompiliert und geflasht werden. Nun habe ich mir die StdPeriphLib 
zusammengeklickt. Dies lässt sich auch kompilieren bis ich das 
Startup-File einbinde. ( startup_stm32f40xx.asm oder auch 
startup_stm32f40xx.S ) Es sieht so aus, als ob Eclipse kein asm kann. 
Woran könnte das liegen?

Als Toolchain habe ich probiert:
- GNU Tools for ARM Embedded Processors (arm-none-eabi-gcc)
und
- Sourcery CodeBench Lite for ARM EABI (arm-none-eabi-gcc)

Bei beiden Varianten tritt das selbe Problem auf. Ich denke bzw. hoffe, 
dass es bestimmt nur eine kleinigkeit in den Einstellungen ist.

Ein Profi, der etwas tiefer mit der Materie vertraut ist, kann mir 
bestimmt weiter helfen.

Anbei noch der gekürzte Konsolenauszug

                                 .
                                 .
                                 .
End of search list.
COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-mthumb' '-O0' '-fmessage-length=0' '-fsigned-char' '-ffunction-sections' '-fdata-sections' '-g' '-D' 'USE_STDPERIPH_DRIVER' '-D' 'HSE_VALUE=8000000' '-I' '/home/username/embedded_workspace/tst/inc' '-I' '/home/username/embedded_workspace/tst/StdPeriphLib/inc' '-I' '/home/username/embedded_workspace/tst/system/CMSIS/Include' '-I' '/home/usernme/embedded_workspace/tst' '-v' '-MMD' '-MP' '-MF' 'src/startup_stm32f40xx.d' '-MT' 'src/startup_stm32f40xx.o' '-c' '-o' 'src/startup_stm32f40xx.o'
 /home/username/EmbeddedArm/gcc-arm-none-eabi-4_8-2014q3/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/as --gdwarf2 -v -I /home/username/embedded_workspace/tst/inc -I /home/username/embedded_workspace/tst/StdPeriphLib/inc -I /home/username/embedded_workspace/tst/system/CMSIS/Include -I /home/username/embedded_workspace/tst -mcpu=cortex-m4 -meabi=5 -adhlns=src/startup_stm32f40xx.o.lst -o src/startup_stm32f40xx.o /tmp/cc5PgyDv.s
GNU assembler version 2.23.2 (arm-none-eabi) using BFD version (GNU Tools for ARM Embedded Processors) 2.23.2.20140731
../src/startup_stm32f40xx.S: Assembler messages:
../src/startup_stm32f40xx.S:1: Error: junk at end of line, first unrecognized character is `*'
../src/startup_stm32f40xx.S:2: Error: junk at end of line, first unrecognized character is `*'
../src/startup_stm32f40xx.S:3: Error: junk at end of line, first unrecognized character is `*'
                                 .
                                 .
                                 .
                                 .
../src/startup_stm32f40xx.S:433: Error: bad instruction `end'
../src/startup_stm32f40xx.S:435: Error: junk at end of line, first unrecognized character is `*'
make: *** [src/startup_stm32f40xx.o] Fehler 1

Vielen Dank und Gruß,

Andy

[chnun (Gast)]

Problem liegt da:

../src/startup_stm32f40xx.S: Assembler messages:
../src/startup_stm32f40xx.S:1: Error: junk at end of line, first 
unrecognized character is `*'
../src/startup_stm32f40xx.S:2: Error: junk at end of line, first 
unrecognized character is `*'
../src/startup_stm32f40xx.S:3: Error: junk at end of line, first 
unrecognized character is `*'

Stell' doch 'mal Dein Startup File hier 'rein.

[Andreas L. (argon)]

Also das startup File habe ich aus dem Basic Framework. Da auch jede 
Zeile rot markiert ist, denke ich, dass Eclipse einfach das asm nicht 
erkennt.

[chnun (Gast)]

>Da auch jede
>Zeile rot markiert ist, denke ich, dass Eclipse einfach das asm nicht
>erkennt.

Nicht denken. Wissen...

Die Meldungen

>>../src/startup_stm32f40xx.S: Assembler messages:

kommen vom Assembler.

Vermutlich liegt's an den CRLF Zeilenenden.

Mach mal

$ dos2unix startup_stm32f4xx.S

[Andreas L. (argon)]

Ich danke dir chnun. Daran lag es. Einfach super wie schnell und 
kompetent hier geholfen wird. Da wäre ich nie drauf gekommen

[c-hater (Gast)]

chnun schrieb:

>>>../src/startup_stm32f40xx.S: Assembler messages:
>
> kommen vom Assembler.
>
> Vermutlich liegt's an den CRLF Zeilenenden.

Wenn's so ist: Schwache Leistung des Parsers.

Man kann so ein Ding auch so programmieren, daß es mit jeder Kombination 
aus CR/LF als Zeilenende klarkommt, sogar bei gemischtem Vorkommen. 
Schlimmstenfalls werden virtuell nicht wirklich vorhandene Leerzeilen 
erzeugt, was allerdings für die meisten Programmiersprachen keine Rolle 
spielt, weil dort Leerzeilen sinnvollerweise keine syntaktische 
Bedeutung besitzen.