STM32F4 y HAL

Crear sus propias bibliotecas es bastante simple. Su documentación de especificaciones de registro es bastante buena, la mayoría, si no todos, los periféricos son fáciles de configurar. Me resulta mucho más doloroso usar sus bibliotecas. pero tal vez solo soy yo. Esto es cierto para st, nxp, ti, atmel, por nombrar algunos (no tanto para intel y microchip).

¿Por qué cambian de biblioteca? Puede deberse a varias razones, un nuevo jefe se hizo cargo, alguna división se cerró, otra se hizo cargo. Marketing quería una nueva imagen para el producto. Como se mencionó ElectronS, podría ser un intento de abstraerse más del hardware para atraer a los usuarios que no quieren o no pueden hacer bare metal. Iría más allá y diría que probablemente estén tratando de competir con el fenómeno Arduino. Lo que mbed y todos los demás siempre han intentado hacer y han fallado (incluso antes de Arduino).

En cualquier caso, cuanto más lejos del hardware se vuelve más hinchado y lento, por lo que más tienes que gastar por unidad de rom, ram y mhz. ¿Solo para poder pasar la misma cantidad de tiempo programando? ¿Simplemente haciéndolo diferente?

Dices que vienes del mundo PIC, ahora hicieron un buen trabajo con las herramientas, sin embargo, sus documentos de chip fueron terribles, algunos de los peores. lo compensaron con bibliotecas y cajas de arena.

Al final del día, pruebe las diversas opciones, pruebe los productos de la competencia para ver cómo se comparan sus herramientas. Mucho de eso lo puedes hacer gratis solo para ver si tiene sentido y puedes compilar cosas. Tal vez incluso use un simulador de conjunto de instrucciones. Encuentra el que coincida contigo.

Tenga en cuenta que la opción sin bibliotecas enlatadas SIEMPRE está disponible para usted. No está limitado en cuanto a qué cadena de herramientas puede usar, qué sistema operativo host, qué ide, editor, etc. Es posible que se lo impongan en la programación de las piezas, si sus opciones son extremadamente limitadas en ese sentido, pase a algún otro chip. o vendedor si puede.

Para vender un producto de chip como este, tienen que proporcionar un entorno de desarrollo, ya sea todo suyo o cosas gratuitas que han pegado. Y tienden a armar una biblioteca de algún tipo. Solo tiene que verse lo suficientemente bien y el parpadeo del ejemplo LED funcione lo suficientemente bien para que su equipo de administración o de hardware diseñe su producto, luego, cuando su producto de placa se lanza por la pared al software, es cuando el dolor llega o no llega. Si casi funciona, pero no del todo, es una gran victoria para el proveedor del chip, ya que ahora pagará por el soporte técnico para ese último tramo. Por lo tanto, les conviene estar casi allí, pero no del todo.

Los proveedores de chips solo tienen que verse lo suficientemente bien como para ganar el diseño. Tienen que seguir mejorando (? cambiando) el producto para atraer clientes nuevos y antiguos. Por lo tanto, tendrán repeticiones, la distancia entre ellas y la cantidad de bibliotecas anteriores que continúan admitiendo, varía. Entonces, casi cualquier biblioteca a la que te acostumbres desaparecerá eventualmente. Así que aprenda a adaptarse (o no use sus cosas y vaya por su cuenta, que puede apoyar indefinidamente). De acuerdo, idealmente, solo necesita desarrollar la aplicación una vez por producto, hacer que su firmware sea perfecto (buena suerte si usa bibliotecas de terceros), y no necesitará volver atrás y encontrar una computadora que cargue su cadena de herramientas si puede encontrar un copia de él, y recuerda cómo usar esa vieja biblioteca. Recuerde que no solo debe guardar su código fuente, sino que también debe guardar todas sus herramientas y documentos.

Sus bibliotecas solo se admiten en una cadena de herramientas, en uno o quizás dos IDE y, a veces, solo en Windows y ciertas versiones. Nuevamente, no tiene ninguna de esas limitaciones, definitivamente no para ARM, si hace lo suyo. Siempre puede leer cualquiera o todas sus bibliotecas para ver cómo hacen las cosas. Pero eso a menudo da mucho miedo, no usan a los desarrolladores de su equipo A para las bibliotecas, extraje algunas líneas de código para preguntar a los candidatos de la entrevista qué está mal con este código.

para ahorrar tiempo y esfuerzo tanto en el lado del silicio como en el lado del software, a menudo reciclan la misma ip, por lo que una vez que ve cómo funciona el periférico en uno de sus chips, a menudo funciona de la misma manera en muchos otros de sus chips. Sí, los sistemas de reloj pueden ser complicados con o sin sus bibliotecas. Alta probabilidad de bloquear el chip, ahí es donde ha ocurrido la mayor parte de mi chip/tablero. Ayuda a comprender cómo funcionan sus chips, por ejemplo, los AVR, la mayoría, si no todos, pueden reprogramarse mientras el chip está reiniciado, por lo que cualquier código incorrecto que arruine los pines necesarios para reprogramar o cuelgue la lógica necesaria para reprogramar, no importa, puedes reprogramar esos chips. Algunos de estos proveedores (st es uno) tienen un cargador de arranque interno que puede seleccionar usando una correa (BOOT0, por ejemplo, en el mundo st),

Talla única que no le queda bien a nadie. Particularmente cierto para el software. Entonces, cualquier intento de abstraer el hardware, solo lo vuelve lento e inflado. También podría obtener un chip más grande y ejecutar Linux en él, si eso es lo que realmente busca. Sin embargo, gran parte de esto se debe a que los desarrolladores no quieren ensuciarse las manos, por lo que básicamente hemos pedido esto y ellos están tratando de proporcionarlo.

Una vez más, no se encierre en st ni en ningún otro proveedor (a menos que sea demasiado tarde y la administración o el equipo de hardware se lo hayan pegado, tenga en cuenta que los productos stm32 son agradables y fáciles de usar). Comprando por ahí. TI está poniendo muchos huevos en la canasta de cortex-m4. Puede hacer mbed en varios de estos productos de brazo, así como en las soluciones compatibles con el proveedor.

Una cosa en la que siempre puede confiar es que cambiarán las bibliotecas de vez en cuando y eventualmente dejarán de admitir la que estaba acostumbrado.

Déjame decirte que muchos de nosotros compartimos la misma decepción que tienes con las bibliotecas HAL, de hecho, están mal y vagamente documentadas y aún nuevas contienen muchos errores.

Entonces, para responder a su pregunta de por qué ST decidió HAL es simple:

1. Quieren crear una capa de abstracción de hardware que, en lenguaje sencillo, significa que quieren que el desarrollo de software y el código sean independientes del microcontrolador, por lo que si escribe un código hoy para stm32f4 y necesita migrar a stm32f7 después de un par de años. será fácil y el código será altamente modular.

2. Esto también permite que más desarrolladores, como programadores de software, trabajen con el microcontrolador sin comprender realmente o entrar en los detalles profundos de cómo el hardware está logrando una tarea. Compañías como ST y TI (que comienzan este camino ahora) están tratando de hacer que el desarrollo integrado sea similar al desarrollo de código de PC donde se usan controladores de alto nivel para desarrollar código RÁPIDAMENTE. La torpeza y falta de optimización en sus drivers y librerías se compensa con el alto rendimiento de los dispositivos ARM.

3. Creo que STM32cubeMX es una gran herramienta si usa bibliotecas HAL, porque el trabajo que consume más tiempo es inicializar periféricos y ahora puede hacerlo en muy poco tiempo, con una interfaz visual que se puede cambiar fácilmente sin afectar el código de usuario (si escribe su código en el lugar apropiado) Puede usar Stm32cubeMx y luego revisar el código y tratar de entender cómo y por qué están usando cada función, de esta manera está tratando de resolver un ejercicio y tiene un manual de solución cerca para corregirlo. gran OMI.

4. El núcleo ARM es bastante complejo, por lo que los métodos antiguos que usamos en el microcontrolador de 8 bits, como el manejo de registros directamente (escribir C en forma de ensamblador), no son factibles, consumen mucho tiempo y dificultan el mantenimiento del código debido a la arquitectura compleja (consulte el configuración del reloj, por ejemplo)

Sé que esto va a ser largo y obstinado, pero como acabamos de lanzar (con éxito) nuestro nuevo producto usando HAL, creo que vale la pena considerarlo. Además, no trabajo para ST, he odiado cada parte de HAL, casi reinicio el proyecto con StdPeriph, he sentido el dolor, pero ahora entiendo por qué.

Primero, un poco de historia. Desarrollamos sistemas de telemetría de potencia ultrabaja y nuestro producto funciona con un STM32L1. Cuando comenzamos a trabajar en el firmware, teníamos las opciones habituales para dispositivos ST (bare metal): hacer todo a mano, usar las bibliotecas StdPeriph o ir con HAL. Los muchachos de ST nos convencieron de elegir HAL, y así lo hicimos. Fue doloroso, tuvimos que solucionar errores en el software (la parte de I2C nos volvió locos durante bastante tiempo) y todavía no me gusta la arquitectura general. Pero funciona.

Cuando cambié de escritorio a integrado, hace un poco más de un año, me sorprendió algo extraño que no podía nombrar ni comprender. Con el tiempo pude entender lo que estaba pasando, o mejor dicho, lo que está pasando: el mundo incrustado está en transición. El silicio se vuelve más barato cada día y los MCU son más potentes y versátiles. Cada vez más dispositivos, independientemente de su tamaño y necesidades de energía, dependen de MCU genéricos. Cada vez más empresas se unen al juego, trayendo una horda de nuevos desarrolladores con diversos antecedentes. La cultura "mezquina" se aleja del tradicional "chico de EE con habilidades de magia de programación" a "chico de SW con vagos conocimientos de hardware".

Si esto es bueno o malo es irrelevante. Solo pasa. De hecho, también le pasó al mundo del software, más de una vez. El auge de la web en 2000 atrajo a los novatos de PHP/MySQL: diles que hay registros en la CPU y responderán "Estoy usando Linux, por lo que no hay registro en mi sistema operativo". Anteriormente, los sistemas operativos multiusuario que se ejecutaban en modo protegido permitían a los desarrolladores perezosos nunca configurar un ISR en toda su carrera y estar bien . Incluso antes, los perforadores de tarjetas y los fabricantes de impresoras fabricaban teclados y pantallas y se volvían locos.

_{Y sí, las tendencias actuales me entristecen personalmente , ya que veo a los desarrolladores ignorantes asombrados con las últimas tecnologías brillantes, mientras que son totalmente incapaces de vincularlos con la historia. Cuando veo a un yo más joven programando un juego en Javascript con WebGL en 2015, quiero gritar "¡No hay nada nuevo! ¡Hice lo mismo con C++ y el SDK de 3Dfx en 1995!". Lo que la historia no cuenta es que su juego se ejecuta en mi teléfono móvil, mientras que el mío necesitaba una PC de jugador (y un instalador, y no podía enviar actualizaciones a través de la web). La verdad es que él podía desarrollar su juego en un mes, donde yo hice lo mismo en seis o doce.}

Obviamente, ni ST ni TI ni Intel ni quien fabrica chips quiere perder el turno. Y tienen razón. El HAL es la respuesta de ST, y en realidad es bastante sólido, no solo en el aspecto comercial o de marketing, sino también en el aspecto de ingeniería. La razón por la que es sonido radica en el nombre:

Capa de abstracción de hardware

En todo caso, esto es lo que debe recordar. El HAL es un esfuerzo por alejarse del hardware. Es una buena ingeniería porque nos permite desvincular la funcionalidad de los detalles. La superposición es lo que permite desarrollar programas complejos: una abstracción sobre otra, hasta el hardware. La abstracción es en realidad la herramienta más poderosa que tenemos para manejar la complejidad . Dudo mucho que alguien en este planeta pueda programar un navegador web en ensamblaje para una CPU específica.

El cambio cultural es realmente difícil de digerir, pero como tengo que reconocer que no es necesario haber leído El arte de la programación informática de Knuth para desarrollar aplicaciones web, el mundo de EE debe admitir que hay recién llegados que pueden (¡y lo harán!) Desarrollar código integrado. sin haber leído el Maldito Manual de Referencia Santo.

La buena noticia es que los jugadores nuevos no significan menos trabajo para los jugadores mayores, sino todo lo contrario, en mi humilde opinión. ¿A quién van a llamar cuando las cosas "no funcionan"?. Si tiene RTFM (a diferencia de ellos), y si sabe lo que hace cada bit de este oscuro registro de configuración, tiene una ventaja.

Entre sus lecturas y experimentos, simplemente vaya con el HAL. ¿Nuevo MCU? No hay problema. ¿Nueva línea MCU? No hay problema tampoco (codifiqué una prueba en un Nucleo STM32F4 en solo un día con CubeMX, y luego simplemente la transfirí a nuestro dispositivo... se sintió bien ). Burlarse de las pruebas unitarias? No hay problema. La lista sigue y sigue, porque la abstracción es buena.

Por supuesto, el HAL en sí mismo no está 100% bien. Su documentación es horrible (pero tienes RT F HRM, ¿no?), hay errores, ST acaba de descargarnos una versión beta (parece bastante estándar en estos días) y su apoyo público es una broma. Pero no lanzar el HAL hubiera sido aún peor.