Mueva la programación integrada de Keil a Linux

Actualmente estoy usando Keil para desarrollar una placa de descubrimiento STM32. Mi proyecto está casi terminado y me gustaría pasar a un entorno de construcción basado en Linux. He estado usando la herramienta de flasheo preconfigurada y los controladores STLink para que Windows flashee la placa, y obtuve keil para exportar un archivo bin, que logré flashear en mi máquina Linux usando qSTLink2 . Hasta aquí todo bien.

Ahora estoy atascado en mover el proceso de construcción de todo el proyecto. Específicamente:

¿Cómo porto mi .uvproj a un archivo MAKE, mientras tomo en cuenta cosas como el archivo de inicio 'startup_stm32l1xx_md.s'?

— LG102
fuente

No lo he usado en un STM32 en particular en un entorno de compilación GCC de Linux, pero probablemente encontrará que GCC necesita un archivo de inicio diferente. Es posible que sea mejor encontrar un proyecto simple que ya funcione y luego agregar su código a eso.

— PeterJ

El camino difícil, sin duda.

— Ignacio Vazquez-Abrams

¿Podría usar el archivo .o actual que Keil generó usando MDK-ARM, ignorar la compilación de ese archivo por ahora y vincularlo estáticamente?

— Lg102

Como PeterJ ya escribió. Utilizará un archivo de inicio diferente con diferentes etiquetas y semánticas diferentes. No debería haber forma de mantener el archivo Keil startup_stm32l1xx_md.o. ¿No tiene la fuente startup_stm32l1xx_md.s para ello?

— Harper

Sí, pero parece orientado a MDK-ARM (o eso dice el encabezado). Lo he reemplazado por otro . Sin embargo, no estoy seguro de lo que implica la distinción entre densidad media y alta.

— Lg102

Respuestas:

Lo tengo hecho. Pensé que compartiría mis resultados para que otros puedan usarlo. Gracias por su tiempo a todos.

Utilicé esta cadena de herramientas ARM para construir mi proyecto, y la biblioteca de texane / stlink , que viene con la ./st-flashherramienta, para actualizar el binario a mi STM32L1. Si bien el texane / stlink viene con GDB, descubrí que podía realizar el proceso de construcción + flasheo sin él.

Mi Makefile terminó luciendo así. No es muy bonito ni abstracto, pero hace el trabajo.

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

En el cual:

arm-none-eabi-gcc
La cadena de herramientas ARM
-T stm32l1xx.ld
El documento de enlace
-mthumb -mcpu=cortex-m3
Dile a GCC que esto es para un M3
-D STM32L1XX_MD -D USE_STDPERIPH_DRIVER
Define para el controlador periférico estándar
startup_stm32l1xx_md.s
Documento de inicio orientado a GCC.
system_stm32l1xx.c main.c [ sources ]
Lista de mis archivos fuente
-lm
Para Math.h( L ib M ath)
--specs=nosys.specs
No use llamadas de sistema como _exit.
-o Project.elf
Nombre de salida

— LG102
fuente

¿De dónde stm32l1xx.ldviene el archivo?

— furia

Hay una cadena de herramientas Gnu ARM (arm-none-eabi), y supuestamente openOCD funciona con gdb (aunque no he podido hacer que eso suceda bajo Win7 - openOCD se conecta a una placa STM32F4disco OK, pero gdb tiene problemas para conectarse a openOCD )

Investiga un poco por aquí y encontrarás enlaces a la cadena de herramientas, openOCD y proyectos de muestra que incluyen la fuente de inicio.

— Markt
fuente