¿Por qué la configuración de algunos GPIO cuesta tanta memoria?

Creo que he encontrado dos razones:

1. El compilador no es lo suficientemente inteligente como para reconocer algunas constantes de tiempo de compilación

El problema radica en estas macros: #define LCD_XXX_POS POSITION_VAL(LCD_XXX)

Quiero crear una máscara automática para varios registros de configuración GPIO. Para hacerlo, al menos debo saber la posición de cada pin. Así que uso POSITION_VAL() , una función de macro provista en el encabezado CMSIS de ST:

#define POSITION_VAL(VAL)     (__CLZ(__RBIT(VAL))) 

Básicamente, la función macro toma un parámetro (en este caso, máscara de pin GPIO único), la invierte con la instrucción rbit , calcula los ceros iniciales con la instrucción clz y devuelve los ceros iniciales. Al hacerlo, puedo obtener la posición del pin LCD_XXX con bastante facilidad.

El compilador parece reemplazar la función macro con su cuerpo cada vez, en lugar de reemplazarlos con constantes. He probado al definir LCD_XXX_POS como constantes, el tamaño de la función se redujo a ~ 380 bytes.

2. Algo estaba mal con la configuración del proyecto

Sobre la macro POSITION_VAL(VAL) , el compilador puede no (¿no?) preocuparse si se alimenta con constantes. Entonces, como lo sugiere este artículo , he creado un nuevo encabezado:

#ifdef POSITION_VAL
#undef POSITION_VAL
#endif

#ifdef __GNUC__
# define POSITION_VAL(VAL) (__builtin_ctz(VAL))
#else
# define POSITION_VAL(VAL) (__CLZ(__RBIT(VAL)))
#endif

  

GNU C tiene __builtin_ctz que logra lo mismo pero puede deducir el valor en el momento de la compilación si es apropiado.

Pero Truestudio resaltó #ifdef __GNUC__ rama como inactiva, aunque estaba seguro de que estaba usando GCC. Probé con una nueva plantilla de proyecto, la rama #ifdef __GNUC__ no se marcó como inactiva y la función solo cuesta ~ 180 bytes .

Claramente, había algo mal .....

  

¿Pero por qué cuesta casi 1 kB de flash aunque no es muy largo? Incluso la función HAL-GPIO es 3 veces más pequeña.

Primero veamos lo que pediste.

9 |= de operaciones con un literal *
6 &= ~ operación con un literal *
Operación de 1 = con literal *

* asumiendo que el compilador optimiza la aritmética en las constantes en -O1

El |= toma 4 instrucciones (2 LDR, ORR y STR), y dos constantes. (18 bytes)
&=~ es similar a |= , ya que ~const se optimizará.
Un = son tres instrucciones (LDR, MOV y STR) y dos constantes. (10 bytes)

Como los registros son volatile , estas asignaciones no se optimizarán más. Esto significa que el código anterior es de unos 280 bytes. Tal vez menos, sobre si más de -O1 manteniendo algunos punteros en r1.

Sin embargo, un proyecto ARM vacío también tiene aproximadamente 600 bytes.
Esa es solo la tabla de vectores (~ 80 palabras), y la pila y la inicialización del cero de memoria.

1kB, para " simplemente gpio " no es grande.

Podría deberse a que está utilizando la biblioteca de periféricos STM32F3. Si solo necesita acceso GPIO, puede incluir stm32f3xx.h directamente. Elimine USE_STDPERIPH_DRIVER de la configuración de compilación.