CooCox neue Entwicklungsumgebung

[Michael W. (Gast)]

Ich habe mit meinem Discovery Board CooCox ein-einhalb Jahre pausiert 
und habe mir nun, da ich wieder was machen möchte, CooCox abermals 
heruntergeladen.

Nun sehe ich zu meiner Verwunderung, dass sich da einiges geändert hat 
und ich bin nicht mal mehr in der Lage, ein simples Projekt mit meinen 
alten Header Files zu übersetzen. Wo sind die denn hin?

Stattdessen nervt mich CooCox mit irgendwelchen Komponenten etc...Ist 
das ganze nun Modulbasiert geworden wie der Sch... bei DAVE?

Falls ja, wie schreibe ich Programme im alten Stil?

Ich hab eleider das ungute Gefühl, dass man CooCox oder die ganze Lib 
von STM nicht mehr verwenden kann, da die mittlerweile auf einer ganz 
anderen Schiene unterwegs sind.

LG, Michael

[easy flasher (Gast)]

Wo ist das Problem?
Installiere die alte Version und leg los!

[Bernd K. (prof7bit)]

Du hast nun schmerzhaft eine wichtige Lektion gelernt die da lautet:

  * Das Projekt welches die Zeit überdauern soll und die IDE die
    immer nur einer kurzen vergänglichen Tagesmode entspringt sollen
    niemals auf Gedeih oder Verderb voneinander abhängig und auf
    Ewig aneinander gekettet sein.

Nächste Schritte:

  * Installiere eine nackte Toolchain (nimm das Orginal von
    https://launchpad.net/gcc-arm-embedded/+download)

  * Installiere Cygwin und dessen make-Paket um eine ordentliche
    leistungsfähige Kommandozeilenumgebung zu haben.

  * Schreibe ein Makefile (oder passe ein existierendes an) mit
    dem Du das vorhandene Projekt auf der Kommandozeile bauen
    kannst, ganz ohne IDE.

  * Du wirst viel dabei lernen und Dinge verstehen von denen
    Du vorher noch nichtmal geträumt hast, das ist Gold wert.

Wenn das geklappt hat dann:

  * Installiere eine neutrale IDE (z.B. Eclipse CDT mit dem
    GNU-ARM Plugin) und importiere das Prokekt als Makefile-Projekt,
    also alle Compilereinstellungen, includes und defines und
    der komplette Build bleiben weiterhin im Makefile, der Build
    wird immer nur allein vom Makefile gesteuert, die IDE macht
    nichts anderes als make all aufzurufen (und komfortabel den
    Debugger bedienen natürlich).

  * Jetzt kannst Du jederzeit die IDE wechseln wenn Dir Eclipse
    nicht mehr gefällt oder auch einen neuen Teamkollegen mit ins
    Boot holen der lieber Emacs oder Vim bevorzugt, du hast das
    Projekt und dessen Build-Vorgang erfolgreich komplett von der
    IDE entkoppelt und eine ganze Klasse von Kopfschmerzerregern
    vollständig eliminiert, alles wird nun einfacher und weniger
    widerspenstig sein.

[W.S. (Gast)]

Bernd K. schrieb:
> * Installiere eine nackte Toolchain (nimm das Orginal von
>     https://launchpad.net/gcc-arm-embedded/+download)
>
>   * Installiere Cygwin und dessen make-Paket um eine ordentliche
>     leistungsfähige Kommandozeilenumgebung zu haben.

Es geht noch viel einfacher:

- Man installiere wie gesagt eine Toolchain, ob das nun von launchpad 
ist oder z.B. yagarto oder Keil (ohne die IDE zu benutzen) oder ein IAR 
(ebenfalls ohne die IDE zu benutzen) IST WURSCHT. Hauptsache, man hat 
Compiler, Assembler, Linker, Bibliotheken und .elf-->.hex Tool lauffähig 
beisammen.

- Man lerne, die Aufrufe von Compiler und Co selbst zu formulieren. 
Ersatzeshalber guckt man hier in der Lernbetty nach, wie man das tut. Da 
braucht man keinerlei Cygwin oder Make, die nackte Toolchain reicht 
völlig aus.

Ich hatte genau diese Herangehensweise (Tools ohne IDE benutzen lernen) 
damals in der Beschreibung zur Lernbetty schon mal formuliert, habe 
dafür aber heftigstes Gekreische und Geflame geerntet. Tja, so gehts in 
der Welt..

W.S.

[Michael W. (Gast)]

Hallo und danke für die Antworten !

Nachdem mir die Auseinandersetzung mit dem neuen CooCox zu blöd ist, 
habe ich vor - wie oben empfohlen - alles unter Eclipse und "from the 
scratch" zu machen.

Ich habe dazu die "GNU Tools ARM Embedded" installiert und nach einer 
Reihe weiterer kleinen Hürden nun erstmals ein kleines Test-Programm 
übersetzt (ein Blinky, wobei es mir aber nicht um die Funktion geht, 
sondern um den reinen Übersetzungsvorgang). Das von mir erstellte 
make-File ist im root-Projekt-Ordner!

Die Ausgabe im Eclipse (verbose mode im make aktiviert):

21:51:36 **** Build of configuration Default for project blinky_mk ****
make all 
"----------------------------------------------------------------------"
"Compilation of src/blinky.c:"
""
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -g2 -Wall -O0 -DSTM32F401VC -I./src -ID:/stm32/gnu/include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/CMSIS/ST/STM32F4xx/Include -ID:/stm32/discovery/STM32F4-Discovery_FW_V1.1.0/Libraries/STM32F4xx_StdPeriph_Driver/inc src/blinky.c -o src/blinky.o
""
"----------------------------------------------------------------------"
"Linking:"
""
arm-none-eabi-gcc -mthumb -mcpu=cortex-m4 -g2 -Wl,-Map=bin/main.map -O0 -Wl,--gc-sections -Wl,--verbose -L.  -Wl,-T./ldf/discovery.ld -g -o ./bin/main.elf src/blinky.o  
GNU ld (GNU Tools for ARM Embedded Processors) 2.24.0.20150604
  Supported emulations:
   armelf
opened script file ./ldf/discovery.ld
using external linker script:
==================================================
OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* Internal Memory Map*/
MEMORY
{
  rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x00040000
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00010000
}

_eram = 0x20000000 + 0x00010000;
SECTIONS
{
  .text :
  {
    KEEP(*(.isr_vector))
    *(.text*)
    
    KEEP(*(.init))
    KEEP(*(.fini))
    
    /* .ctors */
    *crtbegin.o(.ctors)
    *crtbegin?.o(.ctors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
    *(SORT(.ctors.*))
    *(.ctors)
    
    /* .dtors */
    *crtbegin.o(.dtors)
    *crtbegin?.o(.dtors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
    *(SORT(.dtors.*))
    *(.dtors)
    
    *(.rodata*)
    
    KEEP(*(.eh_fram e*))
  } > rom 
  
  .ARM.extab : 
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } > rom 
  
  __exidx_start = .;
  .ARM.exidx :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  } > rom 
  __exidx_end = .;
  __etext = .;
  
  /* _sidata is used in coide startup code */
  _sidata = __etext;
  
  .data : AT (__etext)
  {
    __data_start__ = .;
    
    /* _sdata is used in coide startup code */
    _sdata = __data_start__;
    
    *(vtable)
    *(.data*)
    
    . = ALIGN(4);
    /* preinit data */
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP(*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);
    
    . = ALIGN(4);
    /* init data */
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);
    
    . = ALIGN(4);
    /* finit data */
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP(*(SORT(.fini_array.*)))
    KEEP(*(.fini_array))
    PROVIDE_HIDDEN (__fini_array_end = .);
    
    KEEP(*(.jcr*))
    . = ALIGN(4);
    /* All data end */
    __data_end__ = .;
    
    /* _edata is used in coide startup code */
    _edata = __data_end__;
  } > ram 
  
  .bss :
  {
    . = ALIGN(4);
    __bss_start__ = .;
    _sbss = __bss_start__;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
    _ebss = __bss_end__;
  } > ram 
    
  .heap (COPY):
  {
    __end__ = .;
    _end = __end__;
    end = __end__;
    *(.heap*)
    __HeapLimit = .;
  } > ram 
  
  /* .stack_dummy section doesn't contains any symbols. It is only
  * used for linker to calculate size of stack sections, and assign
  * values to stack symbols later */
  .co_stack (NOLOAD):
  {
    . = ALIGN(8);
    *(.co_stack .co_stack.*)
  } > ram 
  
  /* Set stack top to end of ram , and stack limit move down by
  * size of stack_dummy section */
  __StackTop = ORIGIN(ram ) + LENGTH(ram );
  __StackLimit = __StackTop - SIZEOF(.co_stack);
  PROVIDE(__stack = __StackTop);
  
  /* Check if data + heap + stack exceeds ram  limit */
  ASSERT(__StackLimit >= __HeapLimit, "region ram  overflowed with stack")
}

==================================================
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crti.o succeeded
c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crti.o
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtbegin.o succeeded
c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtbegin.o
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/crt0.o succeeded
c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/crt0.o
attempt to open src/blinky.o succeeded
src/blinky.o
attempt to open ./libgcc.so failed
attempt to open .\libgcc.a failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/libgcc.so failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m\libgcc.a succeeded
attempt to open ./libg.so failed
attempt to open .\libg.a failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/libg.so failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m\libg.a failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/libg.so failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a succeeded
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-exit.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-impure.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-init.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-memset.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-__call_atexit.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-atexit.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-fini.o
(c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libg.a)lib_a-__atexit.o
attempt to open ./libc.so failed
attempt to open .\libc.a failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/libc.so failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m\libc.a failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m/libc.so failed
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7e-m\libc.a succeeded
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtend.o succeeded
c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtend.o
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtn.o succeeded
c:/program files (x86)/gnu tools arm embedded/4.9 2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crtn.o
""
"----------------------------------------------------------------------"
"Creation of Binary:"
""
arm-none-eabi-objcopy -Obinary ./bin/main.elf ./bin/main.bin
"----------------------------------------------------------------------"
"Create Listing File:"
""
arm-none-eabi-objdump -S ./bin/main.elf > ./bin/main.lst
"----------------------------------------------------------------------"
"Create Static Usage Analysis:"
""
arm-none-eabi-size ./bin/main.elf
   text     data      bss      dec      hex  filename
    364     1080       32     1476      5c4  ./bin/main.elf

21:51:37 Build Finished (took 742ms)

Wie man sieht ist das compilieren gut gegangen (Haupthürde war es, alle 
Include Pfade richtig bereitzustellen).

Die Fragen:

1)
Wie kann das Linken aber gut gegangen sein, wo doch Funktionen 
eigentlich unresolved sein sollten (z.B. RCC_AHB1PeriphClockCmd, oder 
die von mir provozierte my_foo() ??? Man beachte, dass ich nur das 
blinky.o linke, und weder andere Objects, noch Libraries 
angebe...RCC_AHB1PeriphClockCmd ist in einem File der CMSYS, das ich 
(hier einmal) gar nicht mit-übersetze! Ich stehe vor einen kleinen 
Rätsel...Ich habe derzeit kein Target-System parat, frage mich aber was 
passieren würde, wenn ich die Firmware tatsächlich ausführe...

2)
Beim Blick in das log tauchen Zeilen auf wie:
attempt to open c:/program files (x86)/gnu tools arm embedded/4.9 
2015q2/bin/../lib/gcc/arm-none-eabi/4.9.3/armv7e-m/crti.o succeeded

Warum versucht der Linker ein crti.o zu finden, und warum genau in 
diesem Verzeichnis?? Hat der Linker eine Liste von 
Default-Verzeichnissen, relativ zum Pfad des Programms arm-none-eabi.exe 
?

Obwohl ich mehr Fragen habe, sind es diese beiden, die mich momentan am 
meisten beschäftigen. Hat jemand Antworten?

Vielen Dank,
Michael

[Jope (Gast)]

Hast Du eine Startupdatei, von wo aus Deine main() aufgerufen wird? Ich 
glaube, die hast Du vergessen...

[Michael W. (Gast)]

aha...jetzt klingelt es bei mir ;-)
Mein main wird ja nie aufgerufen und deshalb wird auch kein code 
generiert - stimmt das? Ich wollte mich um die Startup Datei später 
kümmern, aber das ist natürlich Unsinn...

Sehe ich das so richtig?

[Jope (Gast)]

>stimmt das?

Ja.

[Michael W. (Gast)]

Danke !
Ich mache dann morgen weiter.