CMSIS vs HAL vs Biblioteca de periféricos estándar

Así que estoy cambiando de PIC a ARM y compré una placa de descubrimiento STM32F4. Hasta ahora entiendo que para programarlo puede acceder a todos los registros directamente en la memoria (de manera obvia) y también hay 3 bibliotecas principales que puede usar para facilitarle la vida. Ahora mi pregunta es, ¿cuál de esos 3 (CMSIS, HAL, Std Peripherals Lib) es el nivel más BAJO? es decir. el que tiene menos gastos generales. Mi objetivo es aprender el funcionamiento interno del controlador y no hacer mi vida más fácil (solo un poco), por lo que me gustaría saber cuál de estos está más cerca del núcleo sin recurrir al uso del ensamblaje.

Definitivamente el CMSIS. No es exactamente una biblioteca, en su mayoría contiene definiciones para los distintos registros.

Es exactamente lo que uno necesita para acceder fácilmente a los registros del microcontrolador, a fin de implementar su propia HAL. No tiene gastos generales, ya que solo accede a los registros.

Tenga en cuenta que CMSIS, a diferencia de los otros dos, está definido por ARM y no por ST. Esto significa que las diversas bibliotecas CMSIS disponibles para los diversos microcontroladores son bastante similares, lo que ayuda en gran medida a la portabilidad.

Además, CMSIS es el más simple, por lo que es (IMO) el más versátil y más confiable, posiblemente con menos (o sin) errores. Algunas bibliotecas hal para los diversos mcu que he usado son bastante infames por sus errores.

Por otro lado, CMSIS necesita mucho más trabajo de su parte. Sin embargo, es mi elección personal, ya que prefiero invertir mi tiempo creando bibliotecas de calidad, que se adapten a mis necesidades y entendiendo cómo funciona el chip, que dedicar tiempo a aprender solo una nueva biblioteca.

Para aprender cómo funciona, no desea utilizar ninguno de los anteriores. Obtenga un compilador de cross arm y la documentación de st, hecho. Comience a codificar. estos chips son generalmente realmente fáciles de programar. la documentación le dice qué bits en qué registros hacen qué.

Cualquiera / todas estas bibliotecas están destinadas a eliminar esa comprensión / carga / trabajo de usted y hacer que se sienta como una simple experiencia de programación de aplicaciones similar a una API. Que es lo que mucha gente quiere. Puede usar toda la fuente de estas bibliotecas para ayudar a comprender, pero a medida que mejora, encuentra agujeros y problemas en las bibliotecas, a veces código muy aterrador. código mezclado, escrito de forma genérica y portado de un chip a otro, tal vez características de soporte que su chip no tiene, etc. Y todos tienen una sobrecarga excesiva. De 10 a 100 veces demasiado código para la tarea, seguro que puede optimizarse mucho, pero ¿por qué tenerlo allí en primer lugar?

Ya sea que vaya por su cuenta o use una de estas bibliotecas, aún debe mirar la fuente de las bibliotecas que usa para ver si se siente cómodo con lo que están haciendo, si tiene sentido, coincide con la documentación del chip, etc. Cuando algo sale mal, es probable que tengas que investigar tanto sus cosas como las tuyas para descubrir por qué.

Tenga en cuenta que los documentos de chip tampoco son perfectos, eso es parte de la diversión.

No entiendo por qué el ensamblaje surge en una discusión sobre la programación de metal desnudo. Puedes sobrevivir con muy poco montaje. Para estos chips cortex-m, técnicamente solo necesita esta cantidad de asm para arrancar:

.globl _start
_start:
.word 0x20001000
.word main

No puede confiar en datos ni bss y no puede regresar de main con ese mínimo de asm. Pero eso es todo lo que NECESITAS para el metal desnudo. Ahora, si desea hacer interrupciones, necesita más entradas en la tabla de vectores. más líneas de palabras. Recomiendo más asm, pero tal vez 10 o 20 líneas más.

Esto es típicamente todo el asm que uso.

.cpu cortex-m0
.thumb
.thumb_func
.global _start
_start:
stacktop: .word 0x20001000
.word reset
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.thumb_func
reset:
    bl notmain
    b hang
.thumb_func
hang:   b .
.align
.thumb_func
.globl PUT16
PUT16:
    strh r1,[r0]
    bx lr
.thumb_func
.globl PUT32
PUT32:
    str r1,[r0]
    bx lr
.thumb_func
.globl GET32
GET32:
    ldr r0,[r0]
    bx lr
.thumb_func
.globl GET16
GET16:
    ldrh r0,[r0]
    bx lr
.thumb_func
.globl dummy
dummy:
    bx lr
.end

Sí, dice cortex-m0, pero este es un arranque real para mi código m4. Prefiero que esto sea pulgar no pulgar2. Y solo reutilizo este código de un cortex-m a otro, cambiando la dirección del puntero de la pila según sea necesario, por lo que funciona para m0, m3 y m4. Todavía no tengo un m7 ni lo he investigado mucho.

Habilitar la fpu puede requerir algunas líneas más de asm ya que se necesitan instrucciones específicas. Pero el punto es no confundir programación de bajo nivel y asm. C tiene lo que necesita para configurar el chip, así como para escribir una aplicación. Las bibliotecas de las que está hablando están escritas en C, no en asm, por lo que obviamente tampoco necesitan usar asm.

Si quieres aprender el funcionamiento interno, escribe tu propio código. No utilice estas bibliotecas que no sean como referencia. A veces es más fácil piratearlo que intentar leer su código. (no solo ST sino todos los vendedores. Uno de los vendedores tenía una línea de código tan alarmante que la uso como una pregunta de entrevista, pues no la publicaré aquí).

ST definitivamente, pero también otros proveedores, para ahorrar energía, tienen habilitaciones de reloj para secciones del chip, por lo que antes de entrar e intentar parpadear un led, debe encontrar el bit de habilitación para ese bloque gpio y ver si sale de reinicio habilitado, si no, habilítelo, hablando con esa lógica gpio sin un reloj que lo habilita simplemente cuelga el procesador mientras espera una respuesta de la lógica que nunca responderá. No siempre te dicen acerca de estas habilitaciones. Una vez habilitados, a veces lo guían a través del init por algún periférico particular. Los documentos ST son bastante buenos. Viniendo de un microchip que obtiene una calificación bastante mala para la documentación, no debería tener un problema.

He usado ambos, solo acceso de registro de metal desnudo y la biblioteca periférica estándar. Me resulta más fácil lidiar con los registros. Además, si está utilizando un depurador, puede ver los registros y confirmar que contienen lo que programó para ser. Creo que también se aprende más sobre el funcionamiento del chip de esa manera.

Viniendo del mundo de 8 bits, siempre estaba acostumbrado a programar periféricos a través de registros. Las hojas de datos del microcontrolador (es decir, los manuales de referencia STM32) describen los periféricos exclusivamente en notación de registro. Como el programador debe leer esta misma documentación para conocer las funciones y características periféricas antes de intentar utilizarla, me parece natural comenzar a programar los registros. Con un diseño de código carful y comentarios, creo que el código puede ser agradablemente leído y modificado incluso después de volver a leerlo meses después.

Hasta ahora he usado definiciones de CMSIS y he disfrutado usando registros directamente. Mientras tanto, usé bibliotecas HAL en pocos proyectos. Tuvo una influencia considerable en el tiempo de ejecución del código, así que lo dejé. Aunque CMSIS sirve a mi interés, en estos días voy a ser fanático de libopencm3 . Es como las LLbibliotecas proporcionadas por ST. Sin embargo, cubre más microcontroladores incluso en familias ST:

El proyecto libopencm3 (anteriormente conocido como libopenstm32) tiene como objetivo crear una biblioteca de firmware libre / libre / de código abierto para varios microcontroladores ARM Cortex-M3, incluidos ST STM32, Toshiba TX03, Atmel SAM3U, NXP LPC1000 y otros.

tenga en cuenta que:

A pesar del nombre, libopencm3 también es compatible con otros microcontroladores ARM Cortex "relacionados", como Cortex-M0 o Cortex-M4 / Cortex-M4F, por ejemplo.

Puede encontrar la lista de microcontroladores compatibles aquí .