¿Cómo determina cuánto flash/RAM necesita para un microcontrolador?

Supongamos que está iniciando un proyecto integrado con alguna funcionalidad conocida. Cuando selecciona un microcontrolador, ¿cómo selecciona la cantidad de RAM que necesita?

¿Usa una placa de desarrollador y codifica su proyecto primero y luego ve cuánta memoria ha usado y luego selecciona un microcontrolador apropiado que se ajuste a esa memoria?

¿Simplemente elige un microcontrolador robusto para un prototipo y luego lo reduce una vez que tiene un producto que funciona?

¿Simplemente elige algo que está seguro de que será suficiente y si se queda sin espacio, simplemente actualice a uno de mayor densidad de memoria, de lo contrario, simplemente conserva el microcontrolador existente?

¿Qué se considera una buena práctica?

Me parece que debería ser posible, desde el punto de vista de la teoría de la información, estimar el requisito de RAM dentro de un orden de magnitud (estilo de razonamiento dimensional), a partir de la especificación de la tarea. Mmm...
Si usa bibliotecas, puede investigar su huella de memoria. Con tu propio código tienes que ir con experiencia. Compare el nuevo proyecto con los anteriores y determine si espera que sea más grande o más pequeño.

Respuestas (4)

Personalmente, para proyectos de pasatiempos, tiendo a usar el microcontrolador más potente de la familia con el tamaño adecuado. Luego desarrollo la PCB, escribo algo de código y produzco un prototipo.

Esto tiene la ventaja de que conozco bastante bien la pequeña cantidad de microcontroladores, por lo que puedo crear prototipos rápidamente sin tener que leer una hoja de datos completa. También tengo tableros de trabajo y plantillas de código para ellos.

Si funciona y estoy haciendo más de un puñado, entonces compro el microcontrolador más barato que tiene los periféricos correctos y suficiente memoria para lo que codifiqué anteriormente. Esto puede ser molesto si los registros internos cambian (sucede en el PIC) o si alguno de los microcontroladores tiene periféricos adicionales que deben desactivarse para que el código funcione.

Sin embargo, para fines de producción, esto le permitiría reducir una buena cantidad de cada unidad.

Para mis proyectos personales tiendo a utilizar un enfoque similar. Ese mismo método también se cuela en la oficina conmigo. No está mal, funciona, pero ¿hay mejores formas, etc. Agradezco la entrada!
Definitivamente habrá mejores formas en un entorno "real", ¡esperemos otras respuestas!
Absivamente. Desarrollar en una caja de arena grande y cortar más tarde. El tiempo que ahorrará cubrirá con creces los $ 4 adicionales que gasta por microcontrolador para desarrollar. Esto funciona para algo más que un pasatiempo y, de hecho, es aún más importante. ¡Imagínese a 12 personas esperando a que ocurra un cambio a un controlador más grande en lugar de uno!

Por supuesto, para un solo prototipo casero puede ser una buena recomendación comenzar con el más potente de todos los micros compatibles y luego ir escalando.

Sin embargo, si desea ganar una cotización, debe decirle a su cliente un precio antes de tener el dinero para implementar cualquier cosa.

Por lo tanto, una buena práctica es escribir algún tipo de especificación antes de empezar a programar. Usted sabe lo que quiere hacer y debe escribir cómo lo va a hacer.

Este "cómo" también incluye pensar en un diseño de software, respondiendo preguntas como:

  • ¿Necesitas un Sistema Operativo? ¿Cuál? ¿Qué recursos necesita?
  • ¿Quieres tener una arquitectura en capas? Esto requiere interfaces, que pueden consumir RAM
  • ¿Qué bibliotecas ya están disponibles y son útiles/necesarias para su propósito, y cuánta memoria necesitan (una buena documentación de la biblioteca responde esto en función de al menos una compilación de referencia)?
  • ¿Qué estructuras y variables tiene que implementar para sus propios controladores y su aplicación?

Resumir todos esos valores le da una estimación aproximada. Hasta qué punto puede confiar en eso depende de qué tan detallado sea su análisis, y depende de su experiencia :-)
Agregar un margen de al menos 30..50% de su estimación es sin duda una buena idea.

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

Re: "80..90% RAM en uso". La práctica estándar es asegurarse de usar solo un máximo de 50 % de uso tanto en la CPU como en la memoria para poder adaptarse a futuras actualizaciones y correcciones de errores.
@Dunk: Depende del negocio. En Automoción, se acepta comúnmente el 80% de todos los recursos (CPU, RAM, Flash) en SOP. En, por ejemplo, la electrónica de consumo barata puede ser aún más: ¿Qué tan probable es tener una actualización en un sistema con una vida útil de solo 2-3 años?
@Dunk: Podría estar equivocado, pero parece que estás acostumbrado al software de escritorio con memoria dinámica y todas las incertidumbres que conlleva. La gran mayoría de las aplicaciones integradas asignan todo de forma estática. Garantizado sin fugas de memoria. Entonces puede usar exactamente el 100% y estar bien para siempre mientras no lo modifique. Por supuesto, eso solo funciona si tiene una pila separada de su RAM de trabajo o si sabe exactamente cómo se comportará la pila en todo momento. Es una buena idea dejar algo de espacio para eso, pero 10-20% es suficiente para lo que he hecho.
El mayor problema en el software integrado son los punteros no autorizados, los desbordamientos del búfer, la división por cero y cosas por el estilo. Algunas MCU pueden lanzar excepciones en el hardware, similares a las interrupciones, pero todo lo que he usado continuará alegremente como si nada hubiera pasado. Habrá algún tipo de resultado, pero probablemente no sea lo que esperaba, por lo que tendrá que comprobarlo. Algunas cosas, como el desbordamiento o subdesbordamiento aritmético, son fáciles de verificar y corregir de inmediato; otras cosas, como punteros deshonestos, pueden pasar completamente desapercibidos hasta que una función que funcionó durante años decide explotar.
Es el desafío y la responsabilidad de los desarrolladores asegurarse de que NADA inesperado suceda ;-) Por lo general, el 80% deja suficiente margen para corregir errores, porque una corrección no cambia el tamaño del código (tanto). Si es así, entonces la prueba antes del SOP no fue lo suficientemente buena. La presión del costo y el tiempo aumentan el riesgo de eso. Pero la presión de los costos también requiere mantener el precio del microcontrolador lo más bajo posible. Actualizar el software es algo diferente, lo que puede requerir un margen mayor (por ejemplo, un nuevo códec para el sistema de sonido).
OK, me retractaré de mi comentario del 50%. He trabajado en 5 empresas diferentes en probablemente 50 proyectos y 20 clientes "únicos" y todos han usado la regla del 50%. Es por eso que aparentemente asumí erróneamente que era una práctica bastante estándar.
Si desea apuntar a un objetivo del 80 % o del 50 %, dependerá de su cliente. Con una especificación fija y solo se necesitan correcciones de errores, el 80% está bien. Las especificaciones poco confiables, el avance esperado de las características y un margen lo suficientemente grande como para permitirlo pueden llevarlo a pagar más por más espacio para la cabeza. Una vez terminamos comprando el doble de microcontroladores de los que necesitábamos y seleccionamos los que overclockearían lo suficiente para darnos el rendimiento que necesitábamos, eso era mucho más barato que un rediseño de PCB para un chip más potente.

Si tan solo fuera posible codificar su sistema embebido primero y luego construir el hardware. Eso facilitaría la vida de todos. Desafortunadamente, eso también significa que sus plazos están fuera de la ventana. Por lo general, el hardware debe diseñarse mucho antes de que se termine el software porque las piezas de hardware suelen tener largos plazos de entrega.

Por lo tanto, los desarrolladores de sw embebidos generalmente necesitarán estimar las necesidades de CPU y memoria de su programa. Su primer paso debe ser tratar de convencer a los chicos de hardware para que le proporcionen el microcontrolador/CPU más potente con la mayor cantidad de RAM posible. Eso rara vez funciona porque tienen requisitos y objetivos propios, pero de vez en cuando tienes suerte.

Si eso no funciona, entonces lo siguiente que haría es un diseño de software de alto nivel y dividir los módulos en funcionalidad. Luego estimaría líneas de código para cada función para cada módulo en el sistema. A continuación, puede utilizar una fórmula para convertir líneas de código en una estimación aproximada de la memoria de código. También investigaría cualquier requisito de memoria inusual (como arreglos grandes) y agregaría una estimación para acomodarlo. Luego agregue un porcentaje sobre ese total para cubrir todo lo que se haya perdido. Luego duplíquelo 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 muy difícil después de construirlo.

¿Dónde podemos encontrar la fórmula para convertir líneas de código en memoria de código?
Ese depende del lenguaje y el compilador que use. Si usa Assembler, una línea equivale aproximadamente a una palabra de memoria (cualquiera que sea el tamaño de palabra de su chip). Si usa C, puede ser de 3 a 5 palabras por línea y si usa C ++ o algo aún más complejo, aún puede ser mucho más. Lo mejor que puede hacer es compilar algunos programas escritos en ese idioma y comparar las líneas de código con la memoria de código para obtener un promedio.

Generalmente, los proveedores de microcontroladores colocan un rango de memoria en sus dispositivos que es adecuado para aplicaciones típicas. Por lo tanto, si solo necesita unos pocos pines de E/S y un SPI en un dispositivo de tamaño reducido, es poco probable que encuentre algo que venga con 500 kBytes de Flash y 64 kBytes de RAM. Con dispositivos más grandes, que están más cerca de los paquetes SoC, incluso el más pequeño es casi seguro lo suficientemente grande a menos que esté planeando hacer algunos cálculos numéricos serios, como el procesamiento de imágenes.

En un entorno profesional, la clave para elegir el microcontrolador adecuado es utilizar datos históricos. Tendrá un registro de los otros proyectos que ha desarrollado y sabrá qué memoria y otros recursos de silicio se requieren para implementar cada función. Sabrá lo que se espera que haga el producto y, por lo tanto, tendrá una buena lista de características y podrá calcular de forma rápida y precisa los recursos que el microcontrolador deberá proporcionar. Tratar de adivinar los requisitos de recursos a partir de una especificación de diseño inicial (desarrollada al comienzo del proyecto cuando se dispone de la menor información sobre el sistema) no es confiable en el mejor de los casos y solo los ingenieros con mucha experiencia, que han construido un completo base de datos de datos históricos en sus propias cabezas, tendrá algún tipo de éxito en el uso de este método.

Muchas empresas han adoptado un enfoque 'ágil' tanto para el software como para el diseño electrónico, lo que implica la creación de una 'biblioteca' de placas de características pequeñas (por ejemplo, placas RS-485, placas ADC, etc.) junto con placas de plataforma genéricas que albergan los microcontroladores. , de forma similar al uso de un kit de desarrollo y complementos. Luego, se puede crear un prototipo de un producto rápidamente (en cuestión de horas) seleccionando y conectando el conjunto de placas requeridas para las funciones. El software se ensambla de manera similar a partir de módulos de biblioteca y se puede portar y probar rápidamente. Una vez que se conoce el tamaño de la parte del código específica del hardware, generalmente es suficiente seleccionar la parte más pequeña que la contendrá. La excepción es la mencionada anteriormente donde la funcionalidad del dispositivo involucra grandes datos o algoritmos muy complejos. Este método proporciona una información precisa,

(Otra ventaja del enfoque Agile es que permite que el software y el desarrollo electrónico se realicen en paralelo, siendo el diseño electrónico un ejercicio para integrar el conjunto de placas de características y realizar el EMC relevante y otras cosas difíciles al mismo tiempo que el El software de aplicación se está desarrollando en los ensamblajes de prototipos. Todavía es necesario realizar algunas adaptaciones e integración, pero se realiza cuando el software y los componentes electrónicos están disponibles).

¿Cómo determina cuánto flash/RAM necesita para un microcontrolador?
RespuestasAquíPolítica de privacidad1y, 0v