¿Cómo se me ocurre una lista de requisitos para un microcontrolador para mi proyecto? ¿Cómo puedo encontrar microcontroladores que encajen?

He estado trabajando en un proyecto de control de eBike en el Arduino MEGA2560. El programa ejecuta 3 lazos de control PID, un lazo de control de capacidad de la batería (interpolación basada en tablas de búsqueda), un velocímetro (muestras basadas en un interruptor de láminas), así como una pantalla LCD para mostrar información. Sus entradas son 3 señales analógicas: voltaje de la batería, corriente y entrada del acelerador del usuario, así como una entrada digital: señal de encendido/apagado del velocímetro (interruptor de láminas). Actualmente, con todo esto ejecutándose en aritmética "larga", el Arduino logra completar 10 bucles por segundo. Dado que la pantalla LCD TFT consume enormes cantidades de potencia de cálculo, estoy pensando en sustituirla por una pantalla alfanumérica.

Las salidas consisten en una señal analógica del acelerador que va a un controlador de motor, la pantalla LCD y, potencialmente, algunos otros dispositivos que requieren señales analógicas. Por lo tanto, los convertidores ADC son esenciales y DAC sería muy útil, aunque actualmente estoy usando la salida Arduino PWM con un filtro de paso bajo RC. Del mismo modo, la capacidad de leer señales digitales y analógicas sin interrumpir el procesador sería genial.

Me gustaría potencialmente hacer un producto de consumo a partir de esto, por lo que quiero construir mi propia plataforma desde cero con un microcontrolador diferente que pueda darme al menos 100 muestras por segundo (10 veces lo que Arduino está logrando). Además, para evitar puntos flotantes, mis cálculos usan variables largas y, en consecuencia, números mayores de 16 bits, por lo que asumo que una MCU de 32 bits sería una buena idea. Además, una MCU capaz de realizar cálculos de punto flotante podría ser interesante para simplificar las matemáticas en el código.

Al final, no estoy seguro de cómo comenzar a buscar MCU que satisfagan estos requisitos y permitan una transición rápida desde el entorno Arduino. ¡Cualquier guía sobre cómo encontrar tales MCU sería muy apreciada!

UH oh. A este sitio web no le gustan las preguntas que piden recomendar piezas.
No necesariamente quiero que me recomienden piezas, sino solo un método o plataforma o alguna guía sobre cómo encontrar la plataforma que necesito.
Esta es mucho mejor que su pregunta anterior, pero sigue siendo muy amplia y algunos puntos de sus requisitos no están claros. Por ejemplo, ¿qué quiere decir con "sin interrumpir el procesador"? Supongo que tampoco quieres hacer E/S sondeadas. También necesita obtener un mejor manejo de exactamente cuánto cómputo se necesita hacer en cada conjunto de muestras.
Debería considerar el uso de matemáticas enteras. Es la cosa justa que hacer.
@ScottSeidman ¿las matemáticas largas son muy diferentes de las matemáticas enteras? Porque para la precisión que me gustaría, necesito números que sean demasiado grandes para ser enteros.
Las matemáticas enteras, largas o cortas, son mucho más rápidas que las de punto flotante; y la matemática entera que es más larga que la profundidad de bits "nativa" del procesador también será lenta. Así que 32 bits suena como una muy buena idea, tal vez uno de los dispositivos de tipo "DSP".
@EliottW: no tiene un coprocesador para hacer flotadores de doble precisión, incluso si cambia a un STM32f4. Tenga en cuenta que, independientemente de las mejores intenciones, sus entradas ADC y cualquier salida DAC tienen una precisión de enteros. Puede hacerse espacio utilizando números enteros de 32 o 64 bits y desplazándose hacia la izquierda, dejando muchos LSB con los que trabajar. En otras palabras, cambie la representación a, digamos, 1/128 de un ADC LSB. Luego, haga sus cálculos de enteros de tal manera que no multiplique los errores de redondeo, es decir, todas sus multiplicaciones primero, seguidas de divisiones de enteros.
Er... espera. ¿Planeas o no planeas usar la aritmética de coma flotante? Usted hace declaraciones que sugieren ambos.
Usaré la aritmética entera al final. Ya cambié mi código para incluir los errores de ronda por timin git a valores más altos.
@duskwuff -- sin flotadores.
Si bien algunas personas lo hacen, la mayoría de las personas generalmente no eligen un micro al azar porque piensan que podría cumplir con algunas especificaciones. Por lo general, usa lo que sabe como línea de base, tal vez hace algunas capturas de tiempo y, si lo que sabe no cumple con los requisitos, se ramifica a micros que son similares a lo que sabe pero que cumplirán con las especificaciones. Así que mire todas las variaciones de micros que conoce, si ninguna de ellas funciona, lea lo que otros sugieren como alternativas. Cuanto más se acerque a algo para lo que ya tiene números, más fácil será estimar el rendimiento del otro dispositivo.
Como sugerencia específica, si te sientes cómodo con Arduino, ¿por qué cambiar? Solo quédate con un Atmel AVR.
Me pregunto qué tipo de cálculos estás haciendo para obtener solo 10 muestras/segundo. Tengo la sensación de que debería poder optimizar el software para obtener un mejor rendimiento.
La pantalla LCD TFT estaba tomando la mayor parte de la potencia computacional. Lo reemplacé con una pantalla LCD alfanumérica que me da un poco más del doble de la frecuencia de muestreo. Sin ninguna pantalla, el código sube hasta 100Hz...
Pensado así. Piense en actualizar la pantalla con menos frecuencia y hacer todas las cosas críticas en el tiempo en una rutina de interrupción y fácilmente puede ir 10 veces más alto. Honestamente, pensé en tu proyecto y creo que podría caber en un AT tiny 88 (con la pantalla basada en HD44780).

Respuestas (6)

(Esta es una guía genérica. Sospecho que también podría beneficiarse de la optimización del código, pero eso está fuera del alcance de este sitio web).

Paso 1: dimensionamiento aproximado, presupuesto, proveedor

Elige uno de:

  • Ordenador (Raspberry Pi, Beagleboard, placa PC104, Intel Edison, etc). Arranca un sistema operativo de propósito general y tiene mucha potencia de procesamiento. Más caro y hambriento de energía. $10-$100.

  • UCM grande. ARM Cortex-A / PIC32 / dsPIC / AVR32 / TI C series DSP, etc. Potencia informática decente, sistema operativo opcional. ~$5.

  • UCM pequeño. Cortex-M / PIC16. Realmente no hay suficiente espacio para un verdadero sistema operativo, tal vez solo un programador de tareas liviano. ~$2.

  • MCU diminuto. Realmente solo para aplicaciones en las que le importa hasta el último microamperio de consumo de energía. ~$1 o menos.

También debe considerar en esta etapa qué proveedores y cadenas de herramientas le gustan y cuáles no. Eche un vistazo al costo de cosas como dispositivos de depuración en circuito e IDE.

Paso 2: periféricos mínimos

¿Necesita cosas como USB? PCI? ¿HDMI? ¿SATA? ¿ADC o DAC inusualmente rápidos? Casi todos los de la categoría "pequeños" o "diminutos" no los tienen, aunque el USB está bastante disponible.

Paso 3: prototipo

Elija algo que cumpla con los criterios anteriores, al azar si es necesario, comience, descubra qué tan factible es y cuánto espacio / potencia de procesamiento necesita. Ya has hecho algo de esto. Escribir en C debería hacer que gran parte de la lógica sea portátil.

Una vez que tengas el prototipo, puedes decirte a ti mismo: "Necesito uno como este, pero con más X" y dejar que eso guíe tus decisiones.

Paso 4: Reducir

Por lo general, es más fácil comenzar con el miembro más grande (la mayoría de Flash y RAM) de una familia de CPU, escribir v1 de su aplicación y luego elegir uno más pequeño y económico para que se ajuste. También puede dedicar tiempo al arte de adaptar el software a menos recursos. Lo que vale la pena depende de cuántas unidades vas a hacer.

Paso 0: Cadena de herramientas (entorno de desarrollo de firmware). Encuentre entornos de desarrollo que pueda hacer que funcionen para usted. Aquí es donde se gana o se pierde. Incluso si tiene silicio que se ajusta perfectamente, pero no puede hacer que el entorno de desarrollo de firmware funcione (por cualquier motivo), entonces su proyecto no despegará. (Caso en cuestión: el IDE de Arduino ha hecho despegar su prototipo basado en Arduino).
Categorizar Cortex-M como "MCU pequeño" y PIC32/AVR32 como "MCU grande" parece un poco desafortunado. Personalmente, no he usado PIC32/AVR32, pero basándome en un vistazo rápido al rango de especificaciones, diría que todas deberían estar en el mismo grupo. (Hay microcontroladores Cortex-M que funcionan a >200 MHz, tienen muchos megabytes de memoria flash y más de medio megabyte de RAM)

Buen proyecto. Aquí hay algunos consejos, pero sería difícil generalizar esto para cada proyecto.

Comience con los requisitos computacionales

Esto es lo que le dirá qué tipo de núcleo necesita y el rendimiento general de la MCU. Le sugiero que comience con esto, ya que obviamente no se puede ampliar con componentes externos, a diferencia de los periféricos.

Primero, parece que usa operaciones matemáticas pesadas con números enteros grandes dentro del ciclo. Entonces, como sugirió, 32 bits serían útiles aquí, por lo que ARM es un candidato ideal. En cuanto a la frecuencia de operación: actualmente, estás usando un Arduino MEGA2560 (funcionando a 16 MHz, supongo) y puedes hacer 10 bucles/s. Si desea lograr 100 bucles/s, debería estar bien con un Cortex-M3/M4 en el rango de 100 MHz o más (estimación aproximada). Tenga en cuenta que el Cortex-M4F tiene una unidad de punto flotante.

Ya hemos reducido la selección.

Requisitos de memoria

Esta es fácil: elija la MCU que tenga la mayor cantidad de RAM/Flash de su gama para el prototipo. Una vez que valide el prototipo, cambie a la MCU del mismo rango que tiene suficiente RAM/Flash, ahora que conoce sus requisitos exactos.

Tenga en cuenta que no creo que su aplicación necesite grandes cantidades de memoria.

Ahora, los periféricos

Necesitas absolutamente algo de ADC. Todos los MCU del rango que estamos viendo tienen algunos, por lo que no es un criterio útil. Tampoco lo son las entradas/salidas digitales, salvo que necesites un número muy elevado de ellas (que no parece ser tu caso).

Parece que necesitas un DAC. Sin embargo, esto es algo que en realidad no encontrará fácilmente y reducirá demasiado los candidatos. Por lo tanto, no mantenemos ese requisito y nos quedaremos con un PWM y un paso bajo (que, en realidad, es ciertamente aceptable).

No menciona ninguna interfaz de comunicación, excepto la pantalla LCD (más adelante). De todos modos, todos los MCU tienen I2C/SPI/UART/... si necesita alguno.

la pantalla de cristal líquido

Este es más complicado, porque hay muchas soluciones diferentes que imponen requisitos completamente diferentes a la MCU. Pero no elija la pantalla LCD dependiendo de la MCU. Elija la pantalla LCD que desea para su producto y luego seleccione la MCU que la controlará de manera eficiente.

  • Si desea una pantalla LCD de caracteres: lo más fácil y menos restrictivo para la MCU es hablar con ella a través de alguna interfaz en serie (a menudo SPI). De esta manera, no usará demasiados PIN, puede usar MCU más pequeños/más baratos y la velocidad no es un problema.
  • Si desea una pantalla LCD TFT gráfica: si es pequeña, el enlace serial aún puede ser apropiado. Sin embargo, para 320x200 o más grande y si desea tener una buena interfaz gráfica, querrá comunicarse con una interfaz paralela. En este caso, usa algo de GPIO (pero eso pondrá más carga en la MCU porque tendrá que golpear las líneas de control) o elige una MCU que tiene una interfaz LCD dedicada (que a menudo es lo mismo que un interfaz de memoria externa). Este último impone una fuerte restricción de la elección de MCU, pero no tiene otras restricciones fuertes, así que...

Ahora tu eliges

Vaya al sitio web de ST Micro / NXP / Atmel y use sus herramientas de selección de MCU. También pasará mucho tiempo leyendo hojas de datos. Tómese este tiempo. No se desperdicia. Todo lo que aprenderá aquí, incluso si no lo usa específicamente para este proyecto, puede ser útil.

En este punto, también debe ver la cantidad de PIN que realmente necesitará y verificar el esquema de multiplexación de los candidatos de MCU elegidos para verificar que puede usar todas las funciones de PIN que necesita. Porque, obviamente, querrá tomar las MCU con la menor cantidad de pines que cumplan con sus requisitos (por razones de costo/bienes raíces de PCB).

Consulte los precios/disponibilidad en Mouser/Digikey. Pero no deberías necesitar algo particularmente caro aquí. Tal vez 5€ más o menos.

Lo último sobre el control LCD

Parece que la actualización de la pantalla LCD es parte de su bucle principal. no debería Especialmente si estás repitiendo 100 veces por segundo, es inútil. Haga que el bucle de control calcule todo y ajuste el comando del motor en cada iteración, pero solo actualice los valores para que se muestren en algún lugar de la memoria. Luego, haga que otro ciclo con menor prioridad muestre esta información al usuario cuando no haya nada más importante que hacer.

Sí, idealmente, requiere un cambio de tareas y esas cosas. En realidad, un sistema operativo real (busque FreeRTOS, Coocox OS, Nuttx, ... son muy pequeños, se usan en gran medida en Cortex-M y proporcionan los mecanismos multitarea necesarios).

¡Muchas gracias por su completa respuesta! Me doy cuenta de que todas las MCU ARM Cortex funcionan con 3.3V. Mi señal del acelerador necesita escalar entre 1 y 5V. Supongo que si quiero usar un controlador ARM, tendré que encontrar una manera de aumentar el voltaje, ya que estará limitado a 3.3 V desde la MCU.
Sí. La señal del acelerador es la salida analógica, ¿verdad? En ese caso, podría usar un opamp para amplificarlo.
No estoy seguro de estar de acuerdo con la última oración sobre requerir "un sistema operativo real". Supongo que depende de la cantidad de soluciones listas para usar que desee. Si desea algo en lo que simplemente pueda introducir su lógica de negocios y comenzar a trabajar con unidades, sí, un sistema operativo completo (¡tenga en cuenta que esto no tiene que significar algo como Windows o incluso Linux!) es ciertamente útil.
Si desea algo que pueda ejecutarse con menos recursos, no es tan difícil armar un ejecutivo multitarea cooperativo que pueda ejecutarse con muchos menos recursos informáticos que cualquier cosa que se parezca a un sistema operativo moderno de propósito general. Para ver un ejemplo de esto, eche un vistazo a la computadora de guía Apollo y su ejecutivo. Algunas de las opciones de diseño allí, en particular, algunas de las que deciden qué no incluir. -- podría reducir bastante la complejidad de la implementación. No me sorprendería que algo así se pudiera concretar en unos días, cuando se conozcan los requisitos.
@MichaelKjörling, por supuesto, no quise decir algo ni remotamente como Linux. Sino algo como FreeRTOS, Coocox OS o Nuttx, por ejemplo. Estos son los que considero SO reales , aunque muy pequeños. Escribí eso porque, de hecho, hacer esto en bare-metal llevará más tiempo, será difícil de depurar y será menos flexible. Y el entorno Arduino (aunque estoy lejos de ser un experto en esto) no parece proporcionar mecanismos de asignación de tareas (y, como tal, no lo considero un sistema operativo real ).
ah Bueno, leí mal la parte "real", entonces. Solo para el beneficio de nosotros, los forasteros que ocasionalmente terminamos aquí, es posible que desee considerar aclarar esa parte en su respuesta.

Tenga en cuenta que este es un tema amplio que se puede responder correctamente utilizando múltiples enfoques (subjetivos).

Además, el formato stackexchange no es bueno para diseñar soluciones para problemas. Por ejemplo, rara vez consigues que la gente diseñe hardware para ti. Más bien, propone un diseño de hardware y hace preguntas al respecto.

Dicho esto...

Comience con las características del procesador que no puede cambiar. Como la velocidad y el tamaño de la memoria (si corresponde). Investigue si necesita interrupciones y qué tan complejo debe ser el manejo de interrupciones.

Si necesita soporte periférico como ADC o DAC, la situación es más compleja. En caso de que estas características estén integradas en el procesador o sean externas al procesador. El precio, la precisión e incluso el ruido son factores en esta decisión.

Si se van a admitir periféricos externos, considere el tipo de comunicaciones en serie que son necesarias. El hardware externo puede necesitar SPI, I2C u otro tipo de UART. Si la tasa de datos es alta, puede ser mejor encontrar un procesador con funciones DMA asociadas con sus puertos de comunicación en serie.

Finalmente, si se trata de una aplicación de procesador integrada (que normalmente significa un procesador dedicado a una tarea), considere dividir los requisitos en varios grupos y asignar un procesador a cada uno. Por ejemplo, es probable que un procesador de pantalla GUI no necesite una función ADC. Este enfoque objetivo para resolver problemas ha demostrado ser exitoso en el software y, con la caída de los precios de los procesadores, también se puede aplicar al hardware.

En el mundo real, este enfoque es iterativo. Es decir, muchos proyectos comienzan con un procesador e intercambian diferentes procesadores a medida que ocurren problemas de hardware y/o software o cambia el alcance del proyecto.

Usted es un mejor juez de qué tipo de números esperar que el compilador. Evitaría el enfoque genérico de usar flotadores. Por ejemplo, puede ser que los resultados flotantes no sean los mismos en diferentes plataformas. Usaría la aritmética de enteros y adaptaría la solución a sus necesidades.

No vi a nadie mencionar el costo de las herramientas. Mi empresa eligió un TI CC2541 y descubrió que solo se compilaba con un compilador IAR de $ 4k, definitivamente un espectáculo para un aficionado. También el programador. Puede ser $ 20 o mucho más. Las herramientas más baratas parecen más la norma ahora, por lo que tal vez esto sea una cosa del pasado pronto.

Además, si lo refluye usted mismo, los paquetes como TQFP son más fáciles que, digamos, BGA. Un BGA grande es difícil de acertar, según la experiencia personal.

Si el producto es relativamente sensible al precio y tiene una financiación de desarrollo decente, puede adquirir un montón de placas de evaluación y perfilar el código en cada una para tener una idea. Eso debería ser bastante sencillo si su código está escrito en C portátil. Además del micro, evaluará las cadenas de herramientas con versiones de demostración antes de desembolsar el costo de un IDE completo como IAR o Keil. En algunos casos, puede perfilar el código de cuello de botella directamente en el IDE sin hardware.

Si está muy limitado en cuanto al costo de desarrollo, es posible que deba comprometerse a encontrar algo que no cueste demasiado para la configuración de desarrollo.

Por ejemplo, ST tiene una placa de evaluación ARM Cortex M7 con una bonita pantalla a color por menos de $100. Tiene una FPU con funciones DSP para que pueda hacer cualquier cosa de la que hable fácilmente, probablemente ejecute un bucle PID a 100kHZ en lugar de solo 100Hz. Probablemente sea una exageración a menos que esa pantalla sea una prioridad.

Si busca un procesador más económico sin FPU, probablemente querrá perfilar el código PID en su forma final. Asegúrese de que se incluyan todos los factores de escalado, linealización y calibración, ya que pueden sumarse en términos de tiempo de procesamiento.

A menudo, los periféricos y la calidad y disponibilidad del middleware asociado (y los términos de la licencia) influirán en gran medida en su elección. Si necesita el modo de host BT o Wifi o USB y archivos FAT para almacenar en una memoria USB, o una interfaz SD rápida, todos estos serán factores importantes. Algunos chips tienen un controlador LCD incorporado y un controlador digitalizador que pueden permitir el uso de un panel TFT relativamente económico. No pase por alto las tarifas de licencia a veces altas.

Si tiene alguna idea de la memoria de programa requerida, la velocidad de procesamiento y los periféricos (incluya FPU en esto), puede realizar una búsqueda paramétrica en el distribuidor antes de profundizar en las hojas de datos. Algunas cosas que son demasiado restrictivas pueden ser: paquete de orificio pasante, DAC interno, Ethernet PHY interno, FPU. Es probable que ninguno de estos sea necesario y pueden restringir indebidamente sus opciones de manera prematura.

Buena suerte con eso, es mucho trabajo hacerlo correctamente. En mi experiencia, es una economía falsa cortar demasiado en un nuevo producto porque los clientes inevitablemente pedirán cosas que no anticipó y desea tener alguna capacidad adicional para suministrar eso sin comenzar de nuevo. Por otro lado, si el producto es demasiado caro, no podrá vender lo suficiente con márgenes adecuados para sostener el negocio.

Hay múltiples plataformas diferentes que puede comenzar a buscar, como Arduinos, microcontroladores PIC, FPGA y mucho más. Trabajé con Arduinos en el pasado y tiene un puerto ADC capaz de alcanzar 74kS/s. 100 muestras por segundo es extremadamente lento y me pregunto cómo lo descubrió. Por otro lado, desea preguntarse si necesitará algún tipo de interfaz como SPI, CAN, I2C o UART. Todos ellos pueden tener sus propios beneficios y usted debe considerar si hablará con uno o más esclavos. El último paso, pero probablemente el más importante, sería adivinar cuántos pines del microcontrolador necesitará usar.

"La capacidad de leer señales analógicas a digitales sin interrumpir el procesador sería excelente". Puedo hacer una suposición descabellada al decir que no desea lidiar con búferes externos o internos que circularán sus datos y potencialmente ralentizarán su procesamiento de datos. ¿Está bien? Si es así, eso es más programación para usted, pero los procesadores generalmente son capaces de manejar la velocidad de 100 muestras por segundo. Dependerá de usted programar el reloj, la frecuencia de muestreo y el resto.

Además, considere las interrupciones en su programa si desea seguir muestreando datos continuamente y realizar otras tareas cuando se levanta una bandera.

Creo que te has perdido el punto. Tiene un prototipo construido en un Arduino. El muestreo no es lento. Los lazos de control SON lentos. Tiene tres controladores PID que se calculan usando punto flotante en el Arduino, por lo que son más lentos que la melaza en un invierno antártico. Entonces, el muestreo no es el problema. El código ineficiente es.
Tienes razón sobre eso.
Sí, el problema es que aunque mis bucles están en aritmética larga y no en puntos flotantes, hay tantos cálculos que hacer que como el Arduino toma una muestra una vez por bucle, mi frecuencia de muestreo es muy pequeña (actualmente 20 muestras por segundo) .