Sposta la programmazione integrata da Keil a Linux

Attualmente sto usando Keil per sviluppare una scheda di rilevamento STM32. Il mio progetto è quasi finito e mi piacerebbe passare a un ambiente di costruzione basato su Linux. Ho usato lo strumento di flash preconfigurato e i driver STLink per windows per eseguire il flashing della scheda, e ho avuto il coraggio di esportare un file bin, che sono riuscito a eseguire il flashing sulla mia macchina Linux usando qSTLink2 . Fin qui tutto bene.

Ora sono bloccato nel spostare il processo di costruzione dell'intero progetto. In particolare:

Come posso portare il mio .uvproj su un makefile, tenendo conto di cose come il file di avvio 'startup_stm32l1xx_md.s'?

— Lg102
fonte

Non ho usato in un STM32 in particolare in un ambiente di build GCC Linux, ma probabilmente troverai che GCC ha bisogno di un file di avvio diverso. Potrebbe essere meglio trovare un progetto semplice già funzionante e quindi aggiungere il codice a quello.

— PeterJ,

Nel modo più duro, senza dubbio.

— Ignacio Vazquez-Abrams,

Potrei usare l'attuale file .o che Keil ha generato usando MDK-ARM, per ora ignorare la compilazione per quel file e collegarlo staticamente?

— Lg102,

Come ha già scritto PeterJ. Utilizzerà un file di avvio diverso con etichette e semantica diverse. Non dovrebbe esserci alcun modo per mantenere il file startup_stm32l1xx_md.o di Keil. Non hai la fonte startup_stm32l1xx_md.s per questo?

— forte

Lo so, ma sembra orientato su MDK-ARM (o giù di lì per le intestazioni). L'ho sostituito con un altro . Non sono sicuro di cosa significhi la distinzione tra media e alta densità.

— Lg102,

Risposte:

Ho fatto. Ho pensato di condividere i miei risultati in modo che altri possano usarli. Grazie per il tuo tempo, a tutti.

Ho usato questa toolchain ARM per costruire il mio progetto e la libreria texane / stlink , che viene fornita con lo ./st-flashstrumento, per eseguire il flashing del binario sul mio STM32L1. Mentre texane / stlink viene fornito con GDB, ho scoperto che potrei fare il processo di costruzione + flashing senza di esso.

Il mio Makefile è finito così. Non è molto carino o astratto, ma fa il lavoro.

all:
    arm-none-eabi-gcc -T stm32l1xx.ld -mthumb -mcpu=cortex-m3 -D STM32L1XX_MD -D USE_STDPERIPH_DRIVER startup_stm32l1xx_md.s system_stm32l1xx.c main.c [ sources ] -lm --specs=nosys.specs -o Project.elf

In quale:

arm-none-eabi-gcc
La toolchain ARM
-T stm32l1xx.ld
Il documento linker
-mthumb -mcpu=cortex-m3
Di 'a GCC che questo è per un M3
-D STM32L1XX_MD -D USE_STDPERIPH_DRIVER
Definisce per il driver periferico standard
startup_stm32l1xx_md.s
Documento di avvio orientato al GCC.
system_stm32l1xx.c main.c [ sources ]
Elenco dei miei file di origine
-lm
Per Math.h( L ib M ath)
--specs=nosys.specs
Non usare chiamate di sistema come _exit .
-o Project.elf
Nome dell'uscita

— Lg102
fonte

Da dove viene il stm32l1xx.ldfile?

— rabbia

C'è una toolchain ARM di Gnu (arm-none-eabi), e presumibilmente openOCD funziona con gdb (anche se non sono stato in grado di farlo accadere sotto Win7 - openOCD si collega a una scheda STM32F4disco OK, ma gdb ha problemi di connessione a openOCD ).

Fai un po 'di ricerche qui e troverai i collegamenti alla toolchain, openOCD e progetti di esempio che includono l'origine di avvio.

— markt
fonte