Estoy acostumbrado a hacer cosas básicas y sencillas con microcontroladores, en términos relativos. Cosas como LED de conducción, motores en funcionamiento, rutinas básicas, GUI en LCD de caracteres, etc., pero siempre solo una tarea clave con a lo sumo algunas tareas secundarias. Esto me ha relegado a productos de gama baja ya que eso es realmente todo lo que se necesita en esos casos.
Me gustaría comenzar a diseñar cosas más complejas, pero la parte superior del continuo del microcontrolador no es algo a lo que he estado bien expuesto. Por lo tanto, he tenido un momento muy difícil tratando de elegir un microcontrolador donde haré muchas tareas al mismo tiempo: no puedo decir simplemente por un número MIPS y un pinout satisfactorio si tiene suficiente potencia para hacer lo que quiero. que hacer.
Por ejemplo, me gustaría controlar 2 motores BLDC con rutinas PI, junto con algunas comunicaciones serie y USB, una GUI y muchas otras tareas. Estoy tentado de tener un microcontrolador para cada motor y luego uno para las tareas diversas, de modo que puedo garantizar que la sobrecarga de las cosas varias no estropeará el funcionamiento crítico del motor. Pero no sé si esa es realmente una buena idea o una manera ingenua de hacer las cosas.
Creo que mi pregunta es realmente doble:
¿Es el enfoque todo en uno una buena idea cuando se tiene que hacer muchas tareas múltiples, o es mejor segmentar y aislar, y
¿Cómo puedo saber intuitivamente si el microcontrolador que estoy viendo tiene suficiente potencia de cálculo para hacer lo que necesito en función de mi lista de tareas?
Estoy mirando dsPIC33 moderados hasta ARC SoCs que ejecutan RTOS. Una forma sistemática de perfeccionar lo que necesito me ayudaría mucho.
Respuestas:
Las respuestas a sus preguntas son diferentes según cuál sea su objetivo final. Si necesita un puñado o menos de estos dispositivos, debe facilitar el desarrollo y no preocuparse por el costo de las piezas. Si va a hacer mil o más de estos, vale la pena analizar sus requisitos y reducir el costo del hardware del dispositivo.
Pequeñas cantidades
Si está ejecutando estos dispositivos de forma puntual o pequeña, entonces sus esfuerzos de desarrollo reducirán sus costos por artículo, y debe concentrarse en lo que será más fácil / rápido para su desarrollo, en lugar del costo / tamaño de la microelectrónica.
En general, la encapsulación puede disminuir la complejidad, aumentando su productividad. Si tiene algunos requisitos difíciles en tiempo real, como su control BLDC, bucles PID, etc., entonces puede encontrar más rápido el uso de controladores separados específicamente para aquellas tareas que se comunican con los controladores donde mantiene la interfaz de usuario y otras aplicaciones no reales. tareas de tiempo
Entonces, en este caso, la respuesta a sus preguntas es:
La escala se inclina ligeramente hacia la segmentación y el aislamiento. La razón principal es que la depuración de un sistema en tiempo real puede llevar mucho tiempo, y mantener esas tareas en su propio procesador limita las variables que debe medir o controlar cuando intenta encontrar por qué algo no funciona correctamente.
En este caso, la diferencia de costo entre un procesador de 32 bits con muchos recursos y un procesador de 8 bits con recursos limitados es pequeña en relación con la cantidad de tiempo que pasará trabajando en el desarrollo. Hay pocas razones para tratar de averiguar cuánta energía necesita: simplemente obtenga el procesador más grande que cree que puede desarrollar y úselo. Si en algún momento posterior necesita optimizar el costo del diseño, es relativamente fácil medir el uso real de los recursos del procesador, luego elija un procesador menor que pueda manejar la carga real. Hasta entonces, use el más grande y no se preocupe por encontrar el "mejor ajuste".
Producción en masa
Si planea fabricar muchos de estos dispositivos, entonces un análisis cuidadoso producirá ahorros de costos significativos. En términos generales, un microcontrolador más grande costará menos de dos microcontroladores capaces de reemplazar el microcontrolador individual, aunque ciertamente hay excepciones dependiendo de las tareas específicas requeridas. En estas cantidades, el costo del hardware probablemente será mucho mayor que el costo de desarrollo, por lo que debe esperar pasar más tiempo analizando sus requisitos y realizando el desarrollo de lo que lo haría si solo estuviera haciendo unos pocos.
El enfoque todo en uno generalmente será menos costoso durante la vida de todo el proyecto que los procesadores múltiples. Se requerirá más tiempo de desarrollo y depuración para asegurarse de que las diversas tareas no entren en conflicto, pero el diseño riguroso del software limitará eso casi tanto como lo haría tener un hardware separado.
Deberá comprender las tareas que desea realizar y cuántos recursos requieren. Supongamos que lo siguiente fuera cierto:
Sus rutinas PI de BLDC consumirán X ciclos de tiempo de procesador 100 veces por segundo, y cada uno necesita aproximadamente 50 bytes de RAM para funcionar, 16 bytes de EEPROM para el ajuste y 1k flash para el código. Cada uno necesitará 3 periféricos PWM de 16 bits en el microcontrolador. Es posible que deba especificar la fluctuación de fase, que tendrá requisitos específicos de latencia de interrupción.
Sus rutinas USB y en serie consumirán Y ciclos de tiempo de procesador según sea necesario, 2k RAM, 64 bytes EEPROM y 8k flash. Requerirá USB y periféricos en serie.
Su GUI consumirá Z ciclos de potencia del procesador 30 veces por segundo, y necesitará 2k de RAM, 128 bytes de EEPROM y 10k flash. Utilizará 19 E / S para las comunicaciones con la pantalla LCD, botones, perillas, etc.
Cuando comienzas por primera vez, puede ser difícil entender qué son realmente X, Y, Z, y esto cambiará un poco dependiendo de la arquitectura del procesador. Sin embargo, debería poder comprender, dentro de una estimación aproximada, cuánto ram, eeprom y flash necesitará su diseño y qué periféricos necesita. Puede elegir una familia de procesadores que cumpla con los requisitos de memoria y periféricos y que tenga una amplia gama de opciones de rendimiento dentro de esa familia. En ese punto, para el desarrollo, simplemente puede usar el procesador más potente de la familia. Una vez que haya implementado su diseño, puede pasar fácilmente de la familia en términos de poder a una opción de menor costo sin cambiar su diseño o entorno de desarrollo.
Después de haber hecho suficientes de estos diseños, podrá estimar mejor X, Y y Z. Sabrá que las rutinas PI de BLDC, aunque se ejecutan con frecuencia, son bastante pequeñas y requieren muy pocos ciclos. Las rutinas USB y serie requieren mucho ciclo, pero ocurren con poca frecuencia. La interfaz de usuario requiere algunos ciclos con frecuencia para encontrar cambios, pero requerirá muchos ciclos con poca frecuencia para actualizar una pantalla, por ejemplo.
fuente
Separaría el control del motor y tendría un microcontrolador separado que incluye PWM (quizás un PIC18) para cada uno de los dos motores BLDC, ya que el control PI es una tarea aislada una vez que se inicia y una vez que escribe el código, puede usarlo en ambos micros. Puede volver a conectarlos al microcontrolador principal a través de una interfaz como I²C y descargar los parámetros para el control PI desde allí si lo desea. Eso le permitiría modificarlos en su GUI.
Luego ejecutaría todo lo demás en el microcontrolador principal, como un PIC24 (un PIC32 es probablemente excesivo, según las tareas que enumeró). Además, los PIC24E más rápidos pueden funcionar casi tan rápido como un PIC32.
Al elegir un microcontrolador, primero calculo la cantidad de flash y RAM que necesito, y luego miro la longitud de la palabra y la velocidad del procesador. Para lo posterior, a menudo el requisito más difícil de cumplir es la interrupción más rápida que espera manejar. Si está emitiendo un sonido de 16 KHz, por ejemplo, y tiene una interrupción cada 62.5 µs, entonces será mejor que tenga un microcontrolador con un tiempo de instrucción en decenas de nanosegundos, o no podrá repararlo y obtener otro trabajo hecho.
fuente
Hay un enfoque semi formal que puede usar para ayudarlo a generar su respuesta. Recomiendo leer el capítulo 2 de "Diseño de sistemas integrados" de White, la mayoría de los cuales está disponible en Google Books .
Este capítulo habla sobre el diseño de arquitecturas de sistemas y ofrece un enfoque semi formal sobre cómo encapsular mejor las tareas. Si bien el capítulo trata principalmente de sistemas de un controlador, se extiende fácilmente a múltiples controladores. Le ayudará a imaginar qué recursos deben compartirse y lo ayudará a elegir su nivel de encapsulación para cada tarea.
Ella ofrece una variedad de puntos de vista a considerar, uno de los cuales muestro a continuación, pero hay muchas manipulaciones útiles. Esto, por supuesto, no tiene mucho sentido por sí solo, pero espero que lo aliente a leer el capítulo.
En cuanto a "cómo sé si tengo suficiente controlador", mi preferencia es poner tanta potencia en mi sandbox de diseño como pueda, y luego calcular cuántos recursos puedo reducir una vez que el diseño esté bien camino. La diferencia de precio entre un microcontrolador de $ 10 y un microcontrolador de $ 3 para fines de creación de prototipos podría ser solo semanas de reorganización y giro de pulgares esperando nuevas piezas, mientras que el diseño siempre puede seguir moviéndose si tiene suficiente potencia.
fuente
Trabajo en un sistema que es en general lo que estás describiendo: motores, IO, pantalla, 3x UART + SPI + I2C funcionando en un Coldfire 52259 (micro de rango medio de 32 bits ~ 80MHz) y no es demasiado difícil, aunque obtener la arquitectura de software correcta es importante: tenemos muchas cosas que se ejecutan en hardware e interrupciones (todo lo que el hardware puede manejar por sí solo, lo ejecutamos en hardware y servicio con interrupciones) dejando el bucle main () para hacer todo el mantenimiento.
Personalmente, no me gusta la mayoría de RTOS que he visto, en el extremo inferior hinchan un proyecto, agregan otra cosa para aprender, y obtendrás un mejor rendimiento del hardware haciendo las cosas directamente (usando las funciones de hardware disponibles + interrupciones) en lugar de fingirlo con software.
En el extremo superior, en estos días parece haber muy poco margen entre una MCU que es lo suficientemente compleja y poderosa como para beneficiarse realmente de un RTOS y algo (SoC) que solo ejecuta Linux incorporado.
Sin embargo, en ese caso, diría que hay algún valor en el uso de micros pequeños y baratos para manejar funciones críticas (por ejemplo, el control del motor, donde el tiempo o detenerse en un límite es crítico) bajo el mando de la CPU principal "cerebro", por lo que no está confiando en un sistema operativo "no en tiempo real" para hacer algo de manera oportuna.
fuente
La respuesta de todos los demás es mejor, pero tengo un poco que agregar que puede ser útil. Esto puede estar un poco fuera de lugar y me encantaría agregarlo como comentario, pero hay una regla de 50 repeticiones :(
La respuesta corta es que depende, ver arriba, pero ¿por qué no pensar también en los beneficios del procesador?
¿Por qué no pensar en los beneficios de los procesadores más pequeños? Esta es, después de todo, una pregunta sobre procesadores. Para tareas matemáticas y ciertas tareas no iterativas, múltiples procesadores pueden producir un impulso logarítmico. La regla de Amdahl establece que se puede lograr un impulso de1( ( 1 - p ) + ps) Pero esto viene. P es el porcentaje del cálculo que se puede dividir y s es la aceleración (depende del número de operaciones, hardware, etc.).
Por supuesto, costo, facilidad de implementación; etc. son importantes e incluso más importantes a tener en cuenta también.
fuente
La respuesta puede depender de los detalles de implementación. Algunas tareas son más fáciles de implementar de forma limpia y robusta en microcontroladores separados. El consumo de energía también puede ser una consideración: en general, un solo micro manejo de varias tareas requerirá menos energía que varios micros que manejan tareas individuales.
fuente
"Caballos de fuerza" es secundario a si puedes cumplir tus limitaciones en tiempo real.
Si tiene dos salidas PWM, y ambas necesitan cambiar al mismo tiempo, entonces debe tener el paralelismo necesario para poder hacer eso. Si tiene un controlador PWM dedicado que se encarga de la sincronización exacta, funcionará, incluso con un microcontrolador bastante pequeño, mientras que una solución basada en GPIO será enormemente compleja incluso si hay mucha potencia informática disponible.
Para la mayoría de los protocolos, las MCU modernas tienen implementaciones integradas de aquellas partes del protocolo que tienen restricciones en tiempo real, por lo que si puede encontrar una MCU que tenga los periféricos necesarios y la velocidad de CPU requerida para manejar los flujos de datos (es decir, el requisito de tiempo real degenerado en un requisito suave en tiempo real del formulario "podrá leer desde el FIFO antes de que esté lleno, y más rápido de lo que se llena"), esa sería la opción óptima.
Si no existe tal solución, sus opciones son mover las funciones a controladores separados, usando una solución CPU + FPGA (por ejemplo, FPGA con núcleo ARM duro), o una solución FPGA pura (opcionalmente con una CPU blanda, dependiendo de los requisitos de complejidad).
fuente