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

24

Digamos que está comenzando un proyecto incrustado con alguna funcionalidad conocida. Cuando selecciona un microcontrolador, ¿cómo selecciona cuánta RAM necesita?

¿Utiliza 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 después de tener un producto que funciona?

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

¿Qué se considera una buena práctica?

— efox29
fuente

Me parece que debería ser posible, desde un punto de vista teórico de la información, estimar el requerimiento de RAM dentro de un orden de magnitud (estilo de razonamiento dimensional), a partir de la especificación de la tarea. Hmmm ...

— Lyndon White

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 antiguos y determine si espera que sea más grande o más pequeño.

— jwsc

20

Personalmente, para proyectos de pasatiempos, tiendo a usar el microcontrolador más potente de la familia con la huella adecuada. Luego desarrollo el PCB, escribo un 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 arranque 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 sea que haya codificado anteriormente. Esto puede ser molesto si los registros internos cambian (sucede en el PIC) o si cualquiera 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 ahorrar una cantidad justa de cada unidad.

— David
fuente

Para mis proyectos personales, tiendo a utilizar un enfoque similar. Ese mismo método también se desliza en la oficina conmigo. No está mal, funciona, pero hay mejores formas, etc. ¡Apreciamos la entrada!

— efox29

Definitivamente habrá mejores formas en un entorno "real", ¡esperemos otras respuestas!

— David

Absativamente Desarrollar en un gran cajón de arena y cortar más tarde. El tiempo que ahorrará más que cubrirá los $ 4 adicionales que gasta por microcontrolador para desarrollar. Esto funciona para algo más que cosas de nivel hobby, y de hecho es aún más importante. ¡Imagínese a 12 personas esperando que ocurra un cambio a un controlador más grande en lugar de uno!

— Scott Seidman

13

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 reducirlo después.

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

Por lo tanto, una buena práctica es escribir algún tipo de especificación antes de comenzar 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? ¿Cúal? ¿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 a esto basándose en 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 te da una estimación aproximada. Hasta qué punto puede confiar eso depende de cuán detallado sea su análisis, y depende de su experiencia :-)
Agregar una margen de al menos 30..50% de su estimación es seguramente una buena idea.

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

— mic
fuente

2

Re: "80..90% RAM en uso". La práctica estándar es garantizar que solo use un máximo del 50% de utilización tanto en la CPU como en la memoria para poder acomodar futuras actualizaciones y correcciones de errores.

— Dunk

1

@Dunk: Depende del negocio. En automoción, el 80% de todos los recursos (CPU, RAM, Flash) en SOP es comúnmente aceptado. En, por ejemplo, en 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?

— Mic

@Dunk: Podría estar equivocado, pero parece que estás acostumbrado a un 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 pérdidas de memoria. Entonces puede usar exactamente el 100% y estar bien para siempre, siempre que 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 bastante fácil para lo que he hecho.

— AaronD

El mayor problema en el software embebido es punteros deshonestos, desbordamientos de búfer, dividir entre cero y cosas así. Algunas MCU pueden generar excepciones en el hardware, similares a las interrupciones, pero todo lo que he usado continuará alegremente como si nada hubiera pasado. Habrá un resultado de algún tipo, pero probablemente no sea lo que esperaba, por lo que tendrá que verificarlo. Algunas cosas, como el desbordamiento / desbordamiento aritmético, son fáciles de verificar y corregir de inmediato; otras cosas, como los punteros corruptos, pueden pasar completamente desapercibidos hasta que una función que funcionó durante años decida explotar.

— AaronD

3

Si desea apuntar al objetivo del 80% o al objetivo 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, la función esperada y un margen lo suficientemente grande como para permitirlo podrían llevarlo a pagar más por más espacio libre. Una vez terminamos comprando el doble de microcontroladores que necesitábamos y seleccionamos los que se overclockearían lo suficiente como para darnos el rendimiento que necesitábamos, que era mucho más barato que un rediseño de PCB para un chip más potente.

— Mark Booth

3

Si 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 plazo. Por lo general, el hardware debe diseñarse mucho antes de que el software esté listo porque las partes del hardware con frecuencia tienen largos plazos de entrega.

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

Si eso no funciona, entonces lo siguiente que haría sería 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. Luego puede usar 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 matrices grandes) y agregaría una estimación para acomodar eso. Luego agregue un porcentaje sobre ese total para cubrir todo lo que se perdió. Luego duplique eso para cumplir con el requisito típico de utilización del 50%.

Si, lleva tiempo. Sí, es necesario saltar a través de todos los aros porque cambiar el hardware es realmente difícil después de su construcción.

— Remojar
fuente

¿Dónde podemos encontrar la fórmula para convertir líneas de código en memoria de código?

— EasyOhm

Ese depende del idioma y el compilador que uses. Si usa Assembler, una línea equivale aproximadamente a una palabra de memoria (cualquiera sea el tamaño de palabra de su chip). Si usa C, podría tener entre 3 y 5 palabras por línea y si usa C ++ o algo aún más complejo, podría 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.

— Dakkaron

2

En general, los proveedores de microcontroladores colocan una gama de memoria en sus dispositivos que es adecuada para aplicaciones típicas. Por lo tanto, si solo necesita unos pines de E / S y un SPI en un dispositivo de tamaño reducido, es poco probable que encuentre algo que se envíe con 500 kBytes de Flash y 64 kBytes de RAM. Con dispositivos más grandes, que están más cerca de los paquetes de SoC, incluso el más pequeño es casi seguro que sea lo suficientemente grande, a menos que esté planeando hacer algunos cálculos 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 característica. 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 la menor información sobre el sistema está disponible) no es confiable en el mejor de los casos y solo los ingenieros con mucha experiencia, que han desarrollado una solución integral La base de datos de datos históricos en sus propias cabezas, tendrá cualquier tipo de éxito en el uso de este método.

Muchas compañías han adoptado un enfoque 'ágil' tanto para el software como para el diseño electrónico, que implica la construcción de una 'biblioteca' de placas pequeñas y características (por ejemplo, placas RS-485, placas ADC, etc.) junto con placas de plataforma genéricas que alojan 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 paneles necesarios 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 específica del hardware del código, generalmente es suficiente seleccionar la parte más pequeña que contendrá eso. La excepción es la mencionada anteriormente donde la funcionalidad del dispositivo involucra grandes datos o algoritmos muy complejos. Este método proporciona una precisa,

(Otra ventaja del enfoque ágil es que permite que el software y el desarrollo electrónico se realicen en paralelo, ya que el diseño electrónico es un ejercicio para integrar el conjunto de tableros de características y hacer la 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 se necesita un poco de integración y portabilidad, pero se realiza cuando el software y la electrónica de trabajo están disponibles.)

— Pastel de perro malvado
fuente