¿Debo usar MBED de ARM o plataforma nativa de proveedores de microcontroladores? [cerrado]

Eso depende.

• ¿Desea una fácil portabilidad entre microcontroladores ARM de diferentes familias de productos o incluso fabricantes? ¿Desea desarrollar aplicaciones IoT y desea una conectividad a Internet simple? ¿Le gustaría una amplia selección de bibliotecas portátiles y fáciles de usar?
  Usa mbed.

• ¿Desprecia tener que reinventar la rueda, pero no quiere los gastos generales de mbed? ¿No te gusta desarrollar código con una aplicación web? ¿La capacidad de cambiar a un fabricante diferente es superflua para usted, pero aún se requiere la portabilidad dentro de la misma familia de productos?
  Utilice las bibliotecas nativas de ST (HAL o SPL).

• ¿Quiere un control total sobre cada pequeño detalle del hardware y el software? ¿Quiere optimizar su código para que quepa en el microcontrolador más barato, ejecutarlo súper rápido o usar la menor cantidad de energía posible? ¿Odia tener que lidiar con bibliotecas excesivamente abstractas, lentas e inflexibles y prefiere hacerlo usted mismo?
  Programe bare metal: incluya solo CMSIS y registre definiciones, estudie la hoja de datos con cuidado y escriba su propio código.

Mbed ofrece:

• Portabilidad entre otras plataformas Cortex-M.
• Un amplio conjunto de pilas de red (LWiP, Nanostack) y controladores de red.
• Un RTOS.
• Todavía envuelve el STM32 HAL, por lo que si necesita algo muy específico, tiene esas funciones disponibles (a costa de la no portabilidad).
• Todavía se puede desarrollar y depurar en el banco de trabajo STM, además del IDE en línea, uVision, VSCode, etc.

Entonces, en mi opinión personal (¡pero parcial!), hay pocas desventajas en usar Mbed. Sin embargo, tiene un alcance mucho más amplio que el STM32 HAL, con muchas opciones para usted (elección de RTOS, elección de infraestructura de red). Si no está satisfecho con esto, le gusta hacer una programación básica o no quiere la sobrecarga de Mbed (aunque hay muchas maneras de reducirla); podrías optar por STM32 HAL.

Si está utilizando bibliotecas estándar, stm hal o mbed o una combinación, no está aprendiendo casi nada sobre ARM. Incluso si omite las bibliotecas, la mayor parte del trabajo no está relacionado con ARM, se trata principalmente del chip.

Debes buscar todas las vías para las que tengas tiempo. Las soluciones de nivel alto y muy alto en la superficie parecen fáciles, pero pueden implicar mucho trabajo/dolor. Está confiando principalmente en el código de otras personas, y cuando profundiza en ese código, puede descubrir que no le gusta. Profesionalmente, a su jefe no le importará si usted no quiso poner fin al esfuerzo y usó una biblioteca y luego la biblioteca se rompió y el producto falló y/o algún porcentaje de una ejecución tuvo que descartarse o se agregó un costo adicional para reprogramar. Sea cual sea el camino que necesite para ser responsable de sus elecciones, si desea utilizar una biblioteca, debe poseerla, examinar el código y sentirse cómodo con sus soluciones.

Encuentro que no usar la biblioteca es mucho más rápido de desarrollar (directamente desde el manual), más fácil y usted es dueño del código. Más pequeño, funciona mejor, etc. Pero al mismo tiempo, hay algo en esa parte que no sabe, ¿el proveedor del chip no encontró un error de tiempo porque usó un código de biblioteca que funcionaba lento y no descubrió un problema, o inflado o no? su código puede llegar a un periférico con una frecuencia de pulsación diferente a la tuya y, de nuevo, un matiz en el chip aún descubierto. ¿Hay registros no documentados que no tocó, etc. Puede/debe examinar su código de vez en cuando, incluso si está haciendo lo suyo para tratar de resolver estos problemas, un problema con el código de la biblioteca, ya sea que reutilice su código en partes o el proveedor de la biblioteca, es que si bien es probable que el proveedor del chip esté reutilizando un módulo en el chip, es posible que haya habido cambios,

Si esperas ser un desarrollador profesional, entonces te conviene sentirte cómodo en todos estos niveles, el precio de estos productos o incluso el uso de simuladores cuando sea posible de forma gratuita significa que solo es cuestión de que dediques tiempo, no una cantidad de dólares. Intente usar el RTOS, si lo proporciona el SDK/BSP de los proveedores de chips, para implementar algo. Intente usar las bibliotecas SDK/BSP de los proveedores de chips para crear una solución completa basada en la biblioteca e intente usar la documentación de la pieza para crear una solución completa. Este último es uno en el que aprende algo sobre ARM, o al menos es más probable que lo haga.

Dominar las herramientas es un factor importante aquí, ser capaz de construir un binario que funcione, incluso si un LED parpadea un poco trivial, usando su propia tabla de excepciones/vectores, código de arranque, aplicación y secuencia de comandos del enlazador. las cadenas de herramientas como gnu están listas para usar destinadas al desarrollo basado en linux/sistema operativo o quizás una biblioteca/sdk específico. Pero al mismo tiempo, un compilador solo toma código de alto nivel y genera ensamblado, un ensamblador toma ensamblado y genera un objeto y un enlazador vincula objetos. Cuanto más profundo a través de la cadena de herramientas, más específica se vuelve la cadena de herramientas, una secuencia de comandos gnu ld linker puede funcionar de manera completamente diferente a cualquier otra marca de compilador. El enlazador en general para el caso. Aquí nuevamente, profesionalmente, debe intentar usar algo que no sea gnu, intente llvm/clang aunque eso está algo conectado,

Si todo lo que sabe hacer es tomar un ide/entorno enlatado y llamar a algunas bibliotecas o escribir aplicaciones para un RTOS específico, mientras pueda ganarse la vida, sus opciones son claramente limitadas. En el tiempo que te lleva ver una nueva temporada de algún programa, podrías tener esa reproducción en la esquina de la pantalla o en un televisor cercano y, en paralelo, haber aprendido al menos una cosa nueva que te beneficiará profesionalmente...

Aunque ARM claramente domina el mundo de los procesadores, hay muchas otras arquitecturas aún activas que vale la pena explorar. el 8051 no va a morir pronto, tiene al menos uno, si no varios, en el dispositivo en el que está leyendo esto. El z80, aunque no es tan popular, todavía se usa como una alternativa al 8051. por supuesto, hay otras MCU populares que no están enterradas en otra cosa msp430, pic, avr (ardino las usa) y una serie de otras, que todavía se usan mucho a pesar de que las soluciones arm las pasan por alto. muchos de estos tienen simuladores o núcleos abiertos que puede usar de forma gratuita para conocer los problemas de arquitectura necesarios para arrancar, etc., antes de entrar en los detalles periféricos no específicos de la arquitectura. Del mismo modo, algunos de estos tienen tableros de evaluación/hobby igualmente económicos. Aún mejor, obtenga algunas muestras, una placa de ruptura,