¿Cómo se determina la cantidad de flash/RAM que se necesita para un microcontrolador?

Question

Supongamos que está comenzando un proyecto embebido con alguna funcionalidad conocida. Cuando seleccionas un microcontrolador, ¿cómo seleccionas la cantidad de RAM ¿necesitas?

¿Utilizas una placa de desarrollo y codificas tu proyecto primero y luego ves cuánta memoria has utilizado y luego seleccionas un microcontrolador apropiado que se ajuste a esa memoria?

¿Se elige un microcontrolador potente para un prototipo y luego se reduce cuando se tiene un producto que funciona?

¿Simplemente eliges algo que estés seguro de que será suficiente y si te quedas sin espacio, simplemente actualizas a uno de mayor densidad de memoria o, de lo contrario, te quedas con el microcontrolador existente?

¿Qué se considera una buena práctica?

Answer 1

Personalmente, para los proyectos de hobby tiendo a utilizar el microcontrolador más potente de la familia con el tamaño adecuado. Luego desarrollo la placa de circuito impreso, escribo algo de código y produzco un prototipo.

Esto tiene la ventaja de que conozco bastante bien el pequeño número de microcontroladores, por lo que puedo crear rápidamente un prototipo sin tener que leer toda una hoja de datos. También tengo placas de circuito impreso y plantillas de código para ellos.

Si funciona y voy a hacer más de un puñado, entonces compro el microcontrolador más barato que tenga los periféricos adecuados y suficiente memoria para lo que haya codificado previamente. Esto puede ser molesto si los registros internos cambian (sucede en el PIC) o si alguno de los microcontroladores tiene periféricos extra que deben ser desactivados para que el código funcione.

Sin embargo, a efectos de producción, esto le permitiría recortar una buena cantidad de cada unidad.

Answer 2

Por supuesto, para un único prototipo casero puede ser una buena recomendación empezar con el más potente de todos los micros compatibles y escalar hacia abajo después.

Sin embargo, si quieres ganar un presupuesto, tienes que decirle a tu cliente un precio antes de tienes el dinero para implementar cualquier cosa.

Por lo tanto, una buena práctica es escribir algún tipo de especificación antes de empiezas a programar. Usted sabe qué que quieres hacer, y debes anotar cómo lo vas a hacer.

Este "cómo" también incluye la reflexión sobre el diseño de un software, respondiendo a preguntas como

• ¿Necesita un sistema operativo? ¿Cuál? ¿Qué recursos necesita?
• ¿Quiere tener una arquitectura por capas? Esto requiere interfaces, que pueden consumir RAM
• ¿Qué bibliotecas están ya disponibles y son útiles/necesarias para tu propósito, y cuánta memoria necesitan (una buena documentación de bibliotecas responde a esto basándose en al menos una compilación de referencia)?
• ¿Qué estructuras y variables tienes que implementar para tus propios controladores y tu aplicación?

Sumando todos esos valores se obtiene una estimación aproximada. Hasta qué punto puedes confiar en ella depende de lo detallado que sea tu análisis y de tu experiencia :-)
Añadir un margen de al menos el 30..50% de su estimación es sin duda una buena idea.

Una vez que su producto esté terminado y tenga alrededor del 80..90% de RAM en uso, puede estar bastante seguro de que su selección fue correcta - al menos en lo que respecta a la RAM.

Answer 3

Ojalá fuera posible codificar primero el sistema embebido y luego construir el hardware. Eso facilitaría la vida de todos. Desgraciadamente, eso también significa que los plazos se esfuman. Normalmente, el hardware tiene que diseñarse mucho antes que el software, porque las piezas de hardware suelen tener largos plazos de entrega.

Por ello, los desarrolladores de sw embebidos suelen tener que estimar las necesidades de memoria y CPU de su programa. Tu primer paso debería ser intentar convencer a los chicos del hardware para que te den el microcontrolador/CPU más potente con la mayor cantidad de RAM posible. Eso rara vez funciona porque tienen sus propios requisitos, pero de vez en cuando hay suerte.

Si eso no funciona, lo siguiente que habría que hacer es un diseño de software de alto nivel y desglosar los módulos en funciones. A continuación, estimarías las líneas de código de cada función para cada módulo del sistema. A continuación, puedes utilizar una fórmula para convertir las líneas de código en una estimación aproximada de la memoria del código. También hay que investigar cualquier requisito de memoria inusual (como las matrices grandes) y añadir una estimación para acomodarlo. A continuación, añada un porcentaje sobre ese total para cubrir cualquier cosa que se haya perdido. A continuación, duplique ese porcentaje para cumplir con el requisito típico de utilización del 50%.

Sí, lleva tiempo. Sí, es necesario pasar por todos los aros porque cambiar el hardware es realmente difícil una vez construido.

Answer 4

Por lo general, los fabricantes de microcontroladores incluyen en sus dispositivos una gama de memoria adecuada para las aplicaciones típicas. Así, si sólo necesitas unos pocos pines de E/S y un SPI en un dispositivo de tamaño reducido, es poco probable que encuentres algo que venga con 500 kBytes de Flash y 64 kBytes de RAM. En el caso de los dispositivos más grandes, que se acercan más a los paquetes SoC, incluso el más pequeño es casi seguro lo suficientemente grande, a menos que esté planeando hacer algún cálculo numérico serio, como el procesamiento de imágenes.

En un entorno profesional, la clave para elegir el microcontrolador adecuado es utilizar datos históricos. Tendrás un registro de los otros proyectos que has desarrollado y sabrás qué memoria y otros recursos de silicio son necesarios para implementar cada función. Sabrá lo que se espera que haga el producto y, por tanto, tendrá una buena lista de características y podrá calcular con rapidez y precisión los recursos que necesitará el microcontrolador. Intentar adivinar las necesidades de recursos a partir de una especificación de diseño inicial (desarrollada al principio del proyecto, cuando se dispone de menos información sobre el sistema) no es fiable en el mejor de los casos y sólo los ingenieros muy experimentados, que han creado una amplia base de datos históricos en sus propias cabezas, tendrán algún tipo de éxito al utilizar este método.

Muchas empresas han adoptado un enfoque "ágil" para el diseño electrónico y de software, que implica la creación de una "biblioteca" de pequeñas placas con características (por ejemplo, placas RS-485, placas ADC, etc.) junto con placas de plataforma genéricas que alojan los microcontroladores, de forma similar a la utilización de un dev-kit y plug-ins. De este modo, es posible crear rápidamente un prototipo del producto (en cuestión de horas) seleccionando y conectando el conjunto de placas necesarias para las funciones. El software se ensambla de forma similar a partir de módulos de biblioteca y puede portarse y probarse rápidamente. Una vez que se conoce el tamaño de la parte del código específica del hardware, suele bastar con seleccionar la parte más pequeña que lo contenga. La excepción es la mencionada anteriormente, cuando la funcionalidad del dispositivo implica grandes datos o algoritmos muy complejos. Este método proporciona una metodología precisa, fiable y rastreable, utilizando datos reales de productos que funcionan de verdad, en lugar de conjeturas basadas en especificaciones esperanzadoras.

(Otra ventaja del enfoque ágil es que permite que el desarrollo del software y el de la electrónica se realicen en paralelo, siendo el diseño de la electrónica un ejercicio de integración del conjunto de placas de características y de realización de la CEM pertinente y otras cosas difíciles al mismo tiempo que se desarrolla el software de aplicación en los conjuntos de prototipos. Todavía es necesario realizar alguna portación e integración, pero se hace cuando el software y la electrónica están disponibles).