STM32F4 y HAL

Así que he estado experimentando un tiempo con el STM32F407 (soy nuevo en ARM) y decidí escribir una aplicación simple usando las bibliotecas HAL ya que parece que ST ha descontinuado las Bibliotecas de periféricos estándar. Entonces mi pregunta es, ¿cuál es el punto en HAL? ¿No estaba StdPeriph haciendo su trabajo? ¿Por qué lo suspenderían por HAL? Para mí, parece que HAL es un completo desastre.

La documentación es HORRIBLE, al menos para StdPeriph hay una referencia completa organizada lo suficientemente bien como para encontrar fácilmente lo que desea ( http://stm32.kosyak.info/doc/ ). Para HAL hay un PDF malo ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ) que tiene una estructura aparentemente aleatoria. Al leer cualquier sección, por ejemplo, sobre un periférico, parece que no puedo entender los requisitos para configurarlo y personalizarlo correctamente. Parece más una nota personal de alguien que no quiere olvidar cosas que una referencia.

Sé que puedo usar CubeMX para inicializar GPIO y configurar periféricos, pero mi objetivo es hacerlo yo mismo, así que entiendo mejor su funcionamiento, no tener un software que lo haga todo por mí. ¿Estoy haciendo algo mal? ¿Es el novato ARM en mí lo que me confunde? ¿O la documentación disponible es TAN mala?

Crear tus 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 las bibliotecas? Podría haber varias razones, un nuevo jefe se hizo cargo, una división se cerró y otra se hizo cargo. El marketing quería una nueva imagen para el producto. Como ElectronS mencionó, podría ser un intento de abstraerse más del hardware para atraer a los usuarios que no desean o no pueden hacer metal desnudo. 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 fallaron (incluso antes de Arduino).

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

Dices que vienes del mundo de PIC, ahora hicieron un buen trabajo con las herramientas, sus documentos de chips eran terribles, algunos de los peores. 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. Puede hacer mucho de eso de forma gratuita solo para ver si tiene sentido y puede compilar cosas. Tal vez incluso use un simulador de conjunto de instrucciones. Encuentra el que más te convenga.

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. Pueden adherirse a usted en la programación de las partes, si sus opciones son extremadamente limitadas a ese respecto, pase a otro chip o vendedor si puedes.

Para vender un producto de chips como este, tienen que proporcionar un entorno de desarrollo, ya sea que sea todo suyo o cosas gratis que hayan pegado. Y tienden a armar una biblioteca de algún tipo. Solo tiene que verse lo suficientemente bien y el parpadeo del ejemplo dirigido funciona lo suficientemente bien como para que su gerencia o su equipo de hardware diseñen en su producto, entonces cuando el producto de su 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 de chips, ya que ahora pagará por el soporte técnico para ese último momento. Por lo tanto, les conviene estar casi allí, pero no del todo.

Los vendedores de chips solo tienen que verse lo suficientemente bien como para que el diseño gane. Tienen que seguir mejorando (? Cambiando) el producto para atraer nuevos y viejos clientes. Por lo tanto, tendrán que hacer cambios, la distancia y la cantidad de bibliotecas anteriores que continúan admitiendo, varía. Así que casi cualquier biblioteca a la que te acostumbres desaparecerá eventualmente. Así que aprende a adaptarte (o no uses sus cosas y hazlo tú mismo, lo que puedes soportar 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á regresar y encontrar una computadora que cargue su cadena de herramientas si puede encontrar un copia de ella, 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 son compatibles con una cadena de herramientas, bajo uno, tal vez dos IDE y, a veces, solo en Windows y ciertas versiones. Una vez más, no tiene ninguna de esas limitaciones, definitivamente no es para ARM, si hace lo suyo. Siempre puede leer cualquiera / todas sus bibliotecas para ver cómo hacen las cosas. Pero eso a menudo da mucho miedo, no usan los desarrolladores de su equipo A para las bibliotecas, he extraído algunas líneas de código para preguntar a los candidatos de la entrevista qué hay de malo en 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 vea cómo funciona el periférico en uno de sus chips, a menudo funciona de la misma manera en muchos otros chips. Sí, los sistemas de reloj pueden ser complicados con o sin sus bibliotecas. Alta probabilidad de bloquear el chip, que es donde la mayor parte de mi chip / tablero ha ocurrido. Ayuda a comprender cómo funcionan sus chips, por ejemplo, los AVR, la mayoría, si no todos, pueden reprogramarse mientras el chip está en restablecimiento, por lo que cualquier código incorrecto que estropea los pines necesarios para reprogramar, o bloquea la lógica necesaria para reprogramarse, no importa, puedes reprogramar esos chips. Algunos de estos proveedores (st es uno) tienen un gestor de arranque interno que puede seleccionar usando una correa (BOOT0, por ejemplo, en el mundo st),

Una talla para todos no sirve para nadie. Particularmente cierto para el software. Por lo tanto, cualquier intento de abstraer el hardware solo lo hace lento e hinchado. 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 están tratando de suministrarlo.

Una vez más, no te encierres en st ni en ningún otro proveedor (a menos que sea demasiado tarde y la administración y el equipo de hardware te lo hayan asignado, ten 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 la corteza-m4. Puede hacer lo 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 acostumbrada.

Permítame decirle que muchos de nosotros compartimos la misma decepción que usted tiene con las bibliotecas HAL, de hecho están pobremente y vagamente documentados y aún nuevos contienen muchos errores.

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

1. Quieren crear una capa de abstracción de hardware que, en inglés simple, 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 después de un par de años migrar a stm32f7 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 detalles profundos sobre cómo el hardware está logrando una tarea. Compañías como ST y TI (comenzando este camino ahora) están tratando de hacer que el desarrollo incrustado sea similar al desarrollo de código de PC, donde usas controladores de alto nivel para desarrollar código RÁPIDO. La torpeza y la falta de optimización en sus controladores y bibliotecas se compensa con el alto rendimiento de los dispositivos ARM.

3. Creo que STM32cubeMX es una gran herramienta si está utilizando bibliotecas HAL, porque el trabajo que lleva 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 del usuario (si usted 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 tener un manual de solución cerca para corregirlo. gran OMI.

4. El núcleo ARM es un complejo silencioso, por lo que los viejos métodos que utilizamos en el microcontrolador de 8 bits, como el manejo de registros directamente (escribir C en forma de ensamblaje) no es factible, consume mucho tiempo y hace que el código sea difícil de mantener debido a la arquitectura compleja (verifique el ajuste del reloj, por ejemplo)

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

Primero, un poco de historia. Desarrollamos sistemas de telemetría de ultra baja potencia y nuestro producto funciona con un STM32L1. Cuando comenzamos a trabajar en el firmware, teníamos las opciones habituales para dispositivos ST (básicos): hacer todo a mano, usar las bibliotecas StdPeriph o ir con el HAL. Los chicos de ST nos convencieron para que fuéramos con el HAL, así que 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 incrustado, hace poco más de un año, me sorprendió algo extraño que no podía nombrar ni siquiera comprender. Con el tiempo pude entender lo que estaba sucediendo , o más bien lo que está sucediendo: el mundo incrustado está en transición. El silicio se vuelve más barato todos los días y los MCU son más potentes y versátiles. Cada vez más dispositivos, independientemente de su tamaño, 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 "mala" se aleja del tradicional "chico EE con habilidades de hechicería de programación" a "chico SW con vago conocimiento de hardware".

Si esto es bueno o malo es irrelevante. Solo pasa. En realidad, también le sucedió al mundo del software, más de una vez. El auge de la web en 2000 atrajo a los novatos de PHP / MySQL. Ve y diles que hay registros en la CPU, ellos 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 permitieron a los desarrolladores perezosos nunca configurar un ISR en toda su carrera y estar bien . Incluso antes, los teclados y la pantalla hicieron que los perforadores de tarjetas y los fabricantes de impresoras se volvieran locos.

_{Y sí, las tendencias actuales me entristecen personalmente , ya que veo a desarrolladores ignorantes maravillados con las últimas tecnologías brillantes, mientras que son totalmente incapaces de vincularlos con la historia. Cuando veo a un yo más joven codificando un juego en Javascript con WebGL en 2015, quiero gritar "¡No hay nada nuevo! ¡Hice lo mismo con C ++ y el SDK 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 para jugadores (y un instalador, y no podía enviar actualizaciones por la web). La verdad es que él podría desarrollar su juego en un mes, donde yo hice lo mismo en seis o doce.}

Obviamente, ni ST ni TI ni Intel ni el fabricante de chips quieren perderse el turno. Y tienen razón. El HAL es la respuesta de ST, y en realidad es bastante sólido, no solo en el lado comercial o de marketing, sino también en el lado de la ingeniería. La razón por la cual 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 para alejarse del hardware. Es una buena ingeniería porque nos permite desacoplar la funcionalidad de los detalles. La creación de capas 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 gestionar la complejidad . Dudo mucho que alguien en este planeta pueda programar un navegador web en conjunto 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 nuevos usuarios que pueden (¡y lo harán!) Desarrollar código incrustado sin haber leído el Manual de referencia de Fucking Holy.

La buena noticia es que los jugadores nuevos no significan menos trabajo para los jugadores mayores, 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 sabe qué hace cada bit de este oscuro registro de configuración, tiene una ventaja.

Entre sus lecturas y experimentos, simplemente vaya con el HAL. Nueva MCU? No hay problema. ¿Nueva línea de MCU? No hay problema también (codifiqué una prueba en un STM32F4 Nucleo en solo un día con CubeMX, y luego simplemente lo porté a nuestro dispositivo ... simplemente me sentí bien ). ¿Burlándose de las pruebas unitarias? No hay problema. La lista sigue y sigue, porque la abstracción es buena.

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