Eclipse + GNU ARM + STM32 - HAL o SPL


10

Voy a comenzar con el desarrollo de ARM (después de 2 años de AVR) y he elegido la placa STM DISCOVERY con el microprocesador stm32f4.

Decidí usar eclipse + ARM gcc ya que no me gusta el límite de código de Keil y no tengo el dinero para obtener una versión paga.

Siguiendo los tutoriales, instalé eclipse junto con gcc ARM tools + openocd + make utils, etc.

Mi pregunta es sobre el complemento 'paquetes'. Como todos los principiantes, estoy confundido sobre si usar el nuevo STM HAL o el SPL anterior.

Tengo entendido que HAL ha implementado la abstracción a un nivel en el que se puede referir como Arduino equivalente para el brazo. SPL, por otro lado, proporciona la abstracción suficiente para hacer que la codificación sea más rápida, pero aún debe tratar a nivel de chip.

Con esta comprensión, me gustaría seguir con SPL para comprender mejor las cosas en lugar de usar HAL.

Lo que me gustaría saber es: ¿el uso de paquetes para STM me obliga implícitamente a usar HAL? Si es así, ¿alguien puede indicarme cómo usar SPL con mi configuración?


1
"los tutoriales" es un poco vago, por lo que no sé sobre "el complemento 'paquetes'" y no tengo idea de qué es SPL (¿biblioteca periférica STM?) o SPCL. Tal vez no estoy calificado para esta pregunta, pero trabajar con STM32 durante más de dos años me hizo preguntarme ...
Arsenal

2
SPL es Standard Peripheral Library , por otro lado, tampoco conozco SPCL.
Bence Kaulics

2
La forma preferida y compatible de STM hoy es utilizar el STM32CubeMX, que está generando código basado en HAL. Y debo admitir que es bastante útil, aunque no soy fanático de las herramientas automatizadas, ya que ocultan cosas importantes ...
Eugene Sh.

1
Aunque debería ser principalmente compatible con otras versiones SPL de procesador STM32, no creo que ST tenga SPL para STM32F7.
Tut

Perdón por el bit SPCL. Eso fue un error. Todavía me estoy acostumbrando a las siglas. También verifiqué dos veces y mi placa es la variante stm32f4. Otro error. Aún quedan las preguntas generales, ¿cómo uso la biblioteca periférica estándar con eclipse?
Ankit

Respuestas:


6

El SPL, como veo, no tiene nada que ver con qué IDE está utilizando. Simplemente puede incluir los módulos relevantes (por ejemplo, stmf4xx_dma.c y stmf4xx_dma.h) en su proyecto y usar las funciones expuestas (y descritas muy bien) en los archivos .c y .h. De hecho, he estado aprendiendo sobre el núcleo stmf411 con gcc, openocd y SPL usando solo el símbolo del sistema de Windows; sin IDE Los paquetes en eclipse probablemente lo obligarían a usar el HAL (dado que dentro de la carpeta descargada 'Paquetes' para eclipse, solo veo los módulos HAL).

La propia HAL IMO parece mucho más capas de lo necesario. Mientras que el acceso a los registros directamente se vuelve pesado y difícil de leer. El SPL parece correcto. clive1, el gurú en el foro st.com, también prefiere el SPL sobre HAL. Aquí está mi pregunta en ese foro ... podría ser útil.

¿Necesita ayuda con USART en Nucleo stmf411?


1
Estoy totalmente de acuerdo contigo en eso. HAL parece haberse exagerado con todo el concepto de abstracción. Aunque con él se desarrollarían programas más rápido, realmente no se aprendería qué está sucediendo exactamente, lo que creo que es esencial para el aprendizaje y para ser una prueba futura. Como prueba, creé un proyecto en uvision y seleccioné el soporte heredado en lugar de los paquetes de software y eso parece haber incluido los archivos SPL. También gracias por el enlace!
Ankit

1

No tengo ninguna experiencia con HAL, pero usé SPL muchas veces para salvar mis tiempos. En mi opinión, la comunidad Target de estos procesadores integrados son 2 grupos: el primer grupo que no está interesado en participar con las capas de hardware. Programadores de software, aficionados habituales y adoradores de Arduino, Raspberry. si estás en este grupo parece que HAL es una buena opción para ti. Segundos que provienen de la comunidad electrónica y de hardware, que prefieren

GPIO_A->PIN &= ~(1 << 15);

a

LED_On(1)

para encender el LED y querer saber qué están haciendo básicamente. entonces, si tiene en este grupo y tiene tiempo suficiente para leer el manual de referencia y el manual de programación de su MCU, tal vez la programación de nivel de registro sea otra opción. pero si desea decidir entre solo la opción anterior 2: HAL tiene un futuro mejor debido al soporte de ST, pero SPL es una forma más fácil de entender para un nuevo iniciador. Tal vez esto pueda ayudar http://www.eevblog.com/forum/microcontrollers/stm32-and-their-hal-library/


1
Gracias por el enlace, lectura interesante! Tienes razón, para principiantes SPL parece ser la mejor manera de aprender (y esta es la forma en que también he elegido). Por cierto en su respuesta, debería ser LED_Off
Ankit

1

Obtenga este IDE: System Workbench para STM32 : es gratuito, está basado en Eclipse y tiene tanto arm-gcc como openocd en un solo paquete.

Y sobre bibliotecas: además de SPL y HAL ahora existen LL. Cada uno tiene algunas ventajas y desventajas, y debe elegir lo que necesita. Y según tengo entendido , todos ellos tienen un estado experimental para ST. Por debajo de mis calificaciones para cada uno de ellos:

  • SPL: viejo, engorroso, sin uso de ram adicional, flexible
  • HAL: uso real, engorroso, extra de ram, no flexible
  • LL: real, ligero, sin uso de ram adicional, flexible

Breve descripción de mis calificaciones:

  • engorroso - gran uso de flash, funciones "super" universales para trabajar con periferia
  • uso adicional de ram: se trata de HAL, tiene una copia del estado periférico en estructuras ubicadas en ram y lo usa en todas partes y en todo momento
  • no es flexible, y nuevamente sobre HAL, tiene muchas funciones para diferentes casos, ¡pero! la mayoría de ellos no son utilizables para dispositivos reales (las personas intentan reiniciar HAL para recibir byte por byte de usart >_<, todas las funciones para TIM + DMA se implementan para reescribir el registro TIM y ninguna otra ...)

Para rehabilitar un poco a HAL: tiene una gran ventaja para los novatos: es el soporte de STMCubeMX.

EDITAR:

Me olvido de libopencm3 , es una biblioteca alternativa. No lo he usado.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.