Por lo que sé, ST se detendrá para desarrollar bibliotecas periféricas estándar (SPL) para las próximas generaciones de STM32. Y HAL no es ideal para las personas que quieren entender bien acerca de STM32 y los microcontroladores. ¿Me puede sugerir cuál es el mejor para usar (para aprender y trabajar en el futuro)?
Si realmente desea aprender un microcontrolador específico, abandone las bibliotecas proporcionadas por el proveedor (que a menudo son manejo de errores de todos modos ), y trabaje desde la hoja de datos para establecer registros usted mismo.
Es mejor estructurar su código para que las bibliotecas no estén integradas en su aplicación. Mantenga el acceso al hardware a una capa de interfaz delgada que puede cambiar fácilmente si cambia de proveedor de silicio sin tener que realizar cambios en toda su base de código.
Si su objetivo es comprender en detalle cómo funciona el microcontrolador, simplemente use el archivo de declaración de registro (stm32fxxx.h) y trabaje directamente con el hardware. No es tan difícil, y para algunos periféricos diría que puede ser mucho más simple, ya que las bibliotecas ST agregan una gran cantidad de código de marco que pocas personas realmente necesitan. Una vez que haya aprendido a configurar y usar cada periférico, probablemente querrá usar una biblioteca para hacer el trabajo de la placa de la caldera, pero en ese momento tendrá el conocimiento para poder decidir si desea utilizar la propia. o use una de las ofertas de ST (y, lo que es más importante, depure esas bibliotecas si termina por usarlas).
También tenga en cuenta que CMSIS es un poco diferente del otro tipo de bibliotecas de 'abstracción de hardware' que podría estar viendo. Esencialmente, es una capa de software independiente del proveedor muy liviana definida por ARM para administrar las funciones de soporte de la CPU central (interrupciones, fpu, memoria, etc.). La razón por la que crearon esto es que en los primeros días de los microcontroladores ARM, ARM solo suministraba la CPU central. Estos no se desarrollaron inicialmente para el trabajo del microcontrolador de un solo chip, por lo que tenían un esquema de manejo de interrupciones muy simple: básicamente, solo un mecanismo para guardar el estado de la CPU y derivar a un solo vector en la afirmación de la línea IRQ. Si deseaba tener diferentes fuentes de interrupción, entonces el proveedor del chip tenía que agregar un periférico de controlador de interrupción. El problema fue que cada proveedor comenzó a desarrollar sus propios sistemas de manejo de interrupciones, lo que significaba que el código no podía ser portado tan fácilmente entre chips.
Cuando ARM lanzó la línea Cortex-M, dirigida específicamente a aplicaciones de microcontroladores, incorporaron algunos de estos periféricos de soporte más comunes con el núcleo de la CPU IP. Para proporcionar acceso a estos periféricos, también definieron el CMSIS.
En la práctica, casi siempre usarás las bibliotecas CMSIS en tus proyectos, pero deberías poder ver en el código fuente que gran parte de eso es solo un registro de definiciones, y es muy liviano.
Estoy de acuerdo con la mayoría de los otros; solo debes obtener la documentación de ST y comenzar a usarla. Es tan fácil programar los periféricos directamente como usar una biblioteca proporcionada por el proveedor. No hay otra opción si desea obtener información sobre el microcontrolador.
Si solo quieres aprender cómo llamar a algunas API, prueba las bibliotecas.
En cuanto a trabajar en este campo ahora y en el futuro, pruébalos todos. Desde el acceso directo a los periféricos, ni siquiera utilizar los archivos de cabecera de otra persona puede crear los suyos. Todo el camino hacia y a través de las bibliotecas, que pronto serán obsoletas o nuevas, en las que puede obtener sus manos. Experimente el enfoque RTOS; tome un FreeRTOS en funcionamiento o lo que sea que hayan portado o alguien haya portado y pruebe eso.
De un administrador a otro o de un empleador a otro, o de un proyecto a otro, es posible que tenga que cambiar de un verdadero administrador de barra a un API de llamadas y viceversa. Es posible que tenga que indagar en el proveedor u otro código suministrado y examinarlo de lado a lado con la documentación para averiguar qué está haciendo o qué no está haciendo para que usted resuelva un problema.
Pero debería poder ir desde cero (ver documentos de examen y otros ejemplos de personas), arrancar el Cortex-M, configurar el (los) GPIO (s) ligados a los LED, el tiempo de grabación en bucles y hacer el (los) LED (s) parpadeo encendido y apagado A partir de ahí, decida si desea continuar en los temporizadores y el UART y luego interrumpir o SPI o I²C o PWM otras rutas dentro de lo que está disponible en ese chip. O repite las experiencias con las bibliotecas.
Es muy difícil para usted NO utilizar CMSIS en estos días.
SPL se está descontinuando para el desarrollo futuro.
HAL / Cube es el futuro si desea permanecer en las bibliotecas de ST.
Sin embargo, tiene otras soluciones que no son de ST.
La gente a menudo habla acerca de cuán defectuosas son las bibliotecas ST y mi experiencia con esas afirmaciones sugiere que son más un problema de usuario que un problema de código. Al menos con ti "muy buggy" SPL. El problema conocido es el código I²C para algunos chips, que muchas personas desconocen, o que se conoce como un problema de hardware.
Otro ejemplo fue en el lanzamiento no oficial de SPL 3.5.
La mayoría de los problemas de los usuarios con SPL se deben a la incapacidad de entender cómo funciona el código y vincular el código al hardware.
Utilicé bibliotecas OEM a menudo y las he encontrado en general de muy alta calidad, sin duda mejor que la mayoría de los códigos producidos por "expertos".
Por lo tanto, te sugiero que te sumerjas y veas si te funciona. La sobrecarga es bastante mínima. Y si estructura su código correctamente, volver a su propio código desde la biblioteca es fácil.
Lea otras preguntas en las etiquetas microcontroller stm32f4 cmsis hal-library