Quiero aprender un microcontrolador real con STM32F4. ¿Qué biblioteca debo utilizar (HAL, SPL o CMSIS)?

Question

Por lo que sé, ST dejará de desarrollar Bibliotecas Periféricas Estándar (SPL) para las próximas generaciones de STM32. Y HAL no es ideal para la gente que quiere entender bien sobre STM32 y microcontroladores. ¿Puedes sugerirme cuál es el mejor para usar (para aprender y trabajar en el futuro)?

Answer 1

Si realmente quiere aprender un microcontrolador específico, abandone las bibliotecas proporcionadas por el proveedor (que a menudo son de todos modos, está plagado de errores ), y trabaje a partir de la hoja de datos para configurar los registros usted mismo.

Lo mejor es que estructures tu código de manera que las bibliotecas no estén integradas en tu aplicación. Mantén el acceso al hardware en una fina capa de interfaz que puedas cambiar fácilmente si cambias de proveedor de silicio sin tener que hacer cambios en toda tu base de código.

Answer 2

Si su objetivo es entender en detalle cómo funciona el microcontrolador, entonces sólo tiene que utilizar el archivo de declaración de registros (stm32fxxx.h) y trabajar directamente con el hardware. No es tan difícil, y para algunos periféricos yo diría que puede ser mucho más sencillo, ya que las librerías de ST añaden mucho código de marco que poca gente necesita realmente. Una vez que hayas aprendido a configurar y utilizar cada periférico, probablemente querrás utilizar una biblioteca para hacer el trabajo de la placa de caldera, pero en ese momento tendrás el conocimiento para poder decidir si quieres rodar tu propia, o utilizar una de las ofertas de ST (y, sobre todo, depurar esas bibliotecas si terminas usándolas).

También hay que tener en cuenta que CMSIS es un poco diferente del otro tipo de bibliotecas de "abstracción de hardware" que podrías estar mirando. Esencialmente, es una capa de software muy ligera e independiente del proveedor definida por ARM para gestionar las funciones de soporte del núcleo de la CPU (interrupciones, fpu, memoria, etc.). La razón por la que crearon esto es que en los primeros días de los microcontroladores ARM, ARM sólo suministraba el núcleo de la CPU. Estos no fueron desarrollados inicialmente para trabajar con microcontroladores de un solo chip, por lo que tenían un esquema de manejo de interrupciones muy simple - básicamente sólo un mecanismo para guardar el estado de la CPU y bifurcarse a un solo vector en la afirmación de la línea IRQ. Si querías tener diferentes fuentes de interrupción, el fabricante del chip tenía que añadir un periférico de gestión de interrupciones. El problema es que cada proveedor empezó a desarrollar sus propios sistemas de gestión 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- incorporó algunos de estos periféricos de apoyo más comunes con la IP del núcleo de la CPU. Para proporcionar acceso a estos periféricos también definieron el CMSIS.

En la práctica, casi siempre utilizará las bibliotecas CMSIS en sus proyectos, pero debería poder ver en el código fuente que gran parte de ellas son realmente definiciones de registros, y que son muy ligeras.

Answer 3

Estoy de acuerdo con la mayoría de los demás; deberías conseguir la documentación de ST y empezar a usarla. Es tan fácil programar los periféricos directamente como utilizar una biblioteca proporcionada por el proveedor. No hay otra opción si quieres aprender sobre el microcontrolador.

Si sólo quieres aprender a llamar a algunas APIs, entonces 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 utilizando los archivos de cabecera de otra persona hacer su propio. Todo el camino hasta y a través de cualquier librería, pronto obsoleta o nueva, que puedas conseguir. Experimenta el enfoque de RTOS; toma un FreeRTOS que funcione o lo que sea que hayan portado o que alguien haya portado y pruébalo.

De un gerente a otro, o de un empleador a otro, o de un proyecto a otro, es posible que tengas que pasar de un verdadero baremetal a llamar a las API y viceversa. Es posible que tengas que indagar en el código suministrado por el proveedor o por otra persona y examinarlo junto con la documentación para averiguar lo que hace o deja de hacer para resolver un problema.

Pero deberías ser capaz de partir de cero (examinando la documentación y los ejemplos de otras personas), arrancar el Cortex-M, configurar los GPIO(s) ligados a los LEDs, quemar tiempo en los bucles, y hacer que los LED(s) parpadeen. A partir de ahí decide si quieres continuar con los temporizadores y la UART y luego las interrupciones o SPI o I²C o PWM otros caminos dentro de lo que está disponible en ese chip. O repetir las experiencias con las librerías.

Answer 4

Hoy en día es muy difícil no utilizar el CMSIS.

El SPL se suspende para su desarrollo futuro.

HAL / Cube es el futuro si quieres seguir con las bibliotecas de ST.

Sin embargo, tienes otras soluciones que no son ST.

La gente suele hablar de los fallos que tienen las librerías de ST y mi experiencia con esas afirmaciones sugiere que son más un problema del usuario que del código. Al menos con la "muy buggy" SPL. El problema conocido allí es el código I²C para algunos chips, la mayoría de las veces desconocido para mucha gente, o conocido como un problema de hardware.

Otro ejemplo lo encontramos en la versión no oficial de SPL 3.5.

La mayoría de los problemas de los usuarios con el SPL se han debido a la incapacidad de entender cómo funciona el código y a la vinculación del código con el hardware.

He utilizado a menudo las bibliotecas OEM y he comprobado que, en general, son de muy alta calidad, ciertamente mejor que la mayoría del código producido por los "expertos".

Así que te sugiero que te sumerjas en él y veas si te funciona. Los gastos generales son mínimos. Y si estructuras bien tu código, volver a tu propio código desde la biblioteca es fácil.