Existen numerosas plataformas de MCU y, una vez que alguien se ha acostumbrado a una, suele ser reacio a cambiar de plataforma.
Mi pregunta es: Si uno empezara a utilizar una MCU para tareas de propósito general hoy en día, ¿cómo elegiría una? ¿Cuáles son los puntos de venta únicos de las diferentes plataformas?
Hace un año, di una charla sobre el tema de la elección de microcontroladores (duró aproximadamente una hora y media). La audiencia eran programadores de software de alto nivel y los fabricantes. La mayoría de la audiencia no tenía experiencia previa μC, el resto ha jugado con Arduino solamente. El recuento de la audiencia fue de alrededor de 30. Por lo tanto, esto fue una multidifusión, a diferencia de una clínica de uno a uno.
La diapositiva clave de la charla fue esta:
Dimensiones
para comparar microcontroladores. La lista está en orden descendente.
- Entorno de desarrollo (cadena de herramientas)
- Entorno de desarrollo
- ¿He mencionado el entorno de desarrollo?
- Soporte
- Notas de aplicación
- Apoyo de los compañeros: conocimiento tribal, amigos, foros, teh codes [sic]
- Características
- Memoria
- Periféricos
- Destreza de cálculo
- Consumo de energía
- Coste
p.d.
Debería definir el ámbito al que se limita esta respuesta mía. Veo esta cuestión de la selección de la plataforma a través de dos tipos de lentes. El primero es el de un prototipador. El segundo es un desarrollador de equipos profesionales con precios de calle del orden de 3.000 dólares y cantidades de cientos al año. La lente del aficionado no está muy lejos también. En estos casos, el coste incremental del microcontrolador es pequeño, comparado con el coste de desarrollo, o con el coste del equipo profesional en el que va el microcontrolador.
Hay, por supuesto, una perspectiva muy diferente de la producción en masa. Cuando alguien elige un microcontrolador para un dispositivo barato que se producirá en grandes cantidades (los juguetes convencionales son un buen ejemplo), se guiará por el coste del hardware. Un modesto ahorro en el coste del hardware multiplicado por un gran volumen de producción (en cientos de miles o más) puede justificar el dolor de usar un entorno de desarrollo poco manejable y un microcontrolador a precio de ganga con un soporte mediocre.
Se centra en el entorno de desarrollo. Para mí tiene sentido. ¿Cuáles fueron sus conclusiones?
@ArikRaffaelFunke Pues esas viñetas de mi post de arriba son las conclusiones. ¿No son lo suficientemente concluyentes? Mi objetivo para la charla era: (1) Proporcionar una lista mínima de las preguntas, que deben hacerse durante el proceso de selección. (2) Mostrar dónde y cómo buscar respuestas. He evitado específicamente sacar conclusiones contundentes del tipo: la familia X es buena si..., la familia Y es buena si...
Para volúmenes pequeños y requisitos típicos, sí. Pero a veces hay que elegir la mejor tecnología. O si el volumen es enorme, se puede justificar un dolor de cabeza bastante importante en el desarrollo si se ahorran unos cuantos céntimos por widget, lo que incluye tener soluciones basadas en piezas de la competencia probadas y listas para saltar.
Dado que esta cuestión no ha bastante produjo la plataforma de comparación que yo estaba esperando, he intentado crear uno yo mismo por el estudio de la literatura así como de las otras respuestas. Tal vez esto puede ayudar a que alguien más en el futuro.
Por favor, hágamelo saber si hay algún error o si hay información que puede agregar.
Notas acerca de la comparación:
PIC:
AVR:
Arm Cortex-M:
PSoc: (de Rocketmagnet la respuesta)
Hélice: (de Rocketmagnet la respuesta)
USB:
La "leyenda" de la lista de abajo:
Propiedades del dispositivo más económico: (en aprox. orden de precio)
Ethernet:
Algunas notas aquí: El Propeller no tiene interrupciones en absoluto y no hay soporte para la depuración en el IDE oficial. En su lugar, el mecanismo de depuración preferido parece ser conectar la cosa a un televisor y utilizar una biblioteca proporcionada que muestra las variables en la pantalla. Tampoco hay finalización de código, ni simulador, ni integración con sistemas de gestión de código, ni implementación inusual de includes... Tampoco hay periféricos de hardware excepto los dos contadores por núcleo, hasta donde yo sé.
¿También tienes una fuente para el emulador AVR de 20 dólares? Ese es el precio habitual de los programadores, por lo que he visto.
@AndrejaKo Estaba pensando en el Olimex AVR-USB-JTAG . Gracias por las notas sobre la hélice. Las incluiré en mi próxima edición.
La elección de la MCU depende en gran medida del tipo de proyectos en los que vayas a trabajar. ¿Vas a fabricar dispositivos sencillos, superbaratos y de gran volumen, como luces intermitentes para bicicletas? ¿Estás desarrollando complejos prototipos de robots que tienen que lidiar con numerosos y extraños dispositivos IO y sensores?
Yo me dedico sobre todo a esto último. El principal problema para mí es tratar de encontrar microcontroladores que tengan el conjunto de periféricos que quiero. Esto es muy difícil ya que nuestros requisitos no parecen ser la corriente principal. Queremos cosas como 5 canales PWM, 5 decodificadores de cuadratura, 2 puertos SPI no estándar y una UART con IO negada.
Los únicos MCU que he visto que pueden manejar ese tipo de requisitos con facilidad son el PSoC y el Propeller.
El Propeller es básicamente ocho MCU de 32 bits en un solo chip. Si quieres algún tipo de periférico, sólo tienes que programar uno de los MCU para que realice esa función. Así que puedes tener lo que quieras.
Los PSoCs vienen en dos sabores, 3 y 5. El 3 es un núcleo 8051, y el 5 es un ARM cortex M3. También se incluyen en el chip bloques digitales y analógicos reconfigurables que pueden convertirse en una amplia gama de periféricos: ADCs, filtros, op-amps, DACs, SPI, UART, decodificador de cuadratura, generador de CRC, etc.
El entorno de desarrollo es fantástico. Tienes la edición de código fuente habitual de un IDE típico, pero también tienes un editor de esquemas. Literalmente, puedes conectar cualquier circuito digital que quieras, conectando los periféricos con puertas, flipflops, etc. ¿Necesitas 5 PWMs? Fácil, sólo tienes que ponerlos en el esquema, conectarlos, y ya está. Incluso puedes escribir tus propios periféricos en Verilog si quieres algo que no se proporciona. Una gran parte de tu aplicación puede ser simplemente implementada en este tipo de hardware.
La verdadera ventaja es que puedes quedarte con un solo chip, sabiendo que puede hacer frente a una gran cantidad de proyectos que querrás hacer en el futuro. Lo que me molestaba de los PIC era tener que buscar constantemente entre docenas de dispositivos el que tuviera el conjunto de periféricos que necesitaba. Ahora ya no tengo ese problema.
@ArikRaffaelFunke -- otra consideración es el empaquetado. Si planeas construir tus propios prototipos, entonces es mucho más fácil trabajar con paquetes DIP. La mayoría de los PICs y ATmel AVRs vienen en DIPs, al igual que el Propeller. Los PSoC 3 y 5 no.
Utilizar más de una plataforma está bien. Seleccionar la mejor para cada trabajo y también la disponibilidad de código y ejemplos relacionados con el trabajo.
La mayoría de ellos tienen buenas herramientas de desarrollo, arduino tiene visual studio, pic tiene una gran herramienta y otros también. Así que, para mí, es lo rápido y fácil que puedo conseguir el trabajo bien hecho, + ¿cuántas personas de código abierto que trabajan en la misma cosa?
Pero ¿cómo se puede encontrar esa información sin dejarse engañar por el desorden del marketing? Es decir, hay que encontrar gente que haya utilizado el hardware y la cadena de herramientas para obtener toda esa información. ¿Cómo se encuentran esas comunidades en su trabajo? ¿O es que te basas en lo que te dice el ingeniero de aplicaciones?
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
2 votos
Díganos qué tipo de proyectos y volúmenes tiene en mente, y nos ayudará a responder a la pregunta.
3 votos
El uso general es mucho demasiado amplia. No tiene mucho sentido utilizar el mismo uC para el parpadeo de un LED de bicicleta y para un RTOS con una pantalla táctil en color de alta resolución.
1 votos
Sí, lo ideal sería tener varias fichas con las que esté familiarizado para problemas de diferente tamaño, y estar preparado para coger una nueva si es la más adecuada para una tarea.
2 votos
@WoutervanOoijen La idea con esta pregunta era la siguiente: hay muchas tareas que cualquiera de las plataformas puede manejar fácilmente (es decir, tareas de propósito general). Entonces, uno es completamente libre de elegir entre las plataformas. En este caso, los "factores blandos", como la facilidad de uso, el número de componentes externos, etc., pasan a ser dominantes. - Quería averiguar qué hacen bien/mal las distintas plataformas en comparación con otras.
7 votos
R E L I G I Ó N