Parece que hoy se lanzó Arduino Due (32 bits, 84 Mhz, SAM3X8E basado en ARM-Cortex-M3).
Además, claramente hay una miríada de procesadores en esta categoría (32 bits / 48-96 Mhz / ARM), así como las placas de prototipos correspondientes:
- NXP LPC1768 / mBed
- STM32 / Descubrimiento
- PIC32 / ChipKit
- Hélice PIC32 / Parallax
- LM4F120 / TI Launchpad
- etc.
Estoy tratando de entender el atractivo de estos microprocesadores "intermedios", que para mí parecen estar entre el AVR / MSP430 / etc de gama baja. (pros: económico, de baja potencia, tamaño reducido) y el ARM7 / etc de gama alta (pro: capaz de obtener instrucciones mucho mayores por segundo).
¿En qué situaciones o formas son los microprocesadores basados en 32 bits / 48-96 Mhz / ARM una opción adecuada? Más específicamente, me pregunto en qué aplicaciones o en qué parámetros harían una elección superior durante el diseño, tanto en los microcontroladores de 8 bits de gama baja como en los procesadores ARM7 de muy alta gama.
Respuestas:
Este es uno de esos temas que puede ser muy debatido. Hay tantos puntos de vista diferentes, y diferentes cosas son importantes para diferentes personas. Trataré de dar una respuesta integral, pero entiendo que siempre habrá alguien que no esté de acuerdo. Solo entiendo que aquellos que no están de acuerdo conmigo están equivocados. (Es una broma.)
Sumario rápido:
Esta respuesta será larga, así que permítanme resumir esto por adelantado. Para la gran mayoría de las personas, la última cosecha de chips ARM Cortex-M0 / M3 / M4 ofrece la mejor solución, las mejores características por el costo. Esto es incluso cierto cuando se comparan estas MCU de 32 bits con sus antepasados de 8 y 16 bits como el PIC y el MSP430. Los M0 se pueden comprar por menos de US $ 1 / cada uno y los M4 por menos de US $ 2 / cada uno, así que, excepto por las aplicaciones muy sensibles al precio, las soluciones ARM son muy buenas. Los M0 tienen muy poca potencia y deberían ser lo suficientemente buenos para la mayoría de las personas. Para aquellos que son muy sensibles a la potencia, los MSP430 podrían ser una mejor opción, pero vale la pena considerar los M0 incluso para estas aplicaciones.
Si está interesado en un análisis más profundo, siga leyendo, de lo contrario, puede dejar de leer ahora.
Ahora miraré cada área y compararé los diferentes MCU:
Velocidad de ejecución
Por supuesto, las MCU de 32 bits serán más rápidas. Tienden a tener una velocidad de reloj más rápida, pero también hacen más trabajo para cada uno de esos relojes. Las MCU como ARM Cortex-M4 incluyen instrucciones de procesamiento DSP e incluso pueden tener soporte de punto flotante en hardware. Las CPU de 8 y 16 bits pueden funcionar con números de 32 bits, pero no es eficiente para hacerlo. Hacerlo consumirá rápidamente los registros de la CPU, los ciclos de reloj de la CPU y la memoria flash para el almacenamiento del programa.
Facilidad de desarrollo
En mi opinión, esta es la razón más valiosa para usar MCU modernas de 32 bits, pero también la menos apreciada. Permítanme comparar esto con los PIC de 8 bits. Esta es la peor comparación de casos, pero también la mejor para ilustrar mis puntos.
Los PIC más pequeños básicamente requieren que la programación se realice en lenguaje ensamblador. Es cierto que hay compiladores de C disponibles incluso para los PIC de 8 bits, pero esos compiladores son gratuitos o buenos. No puede obtener un compilador que sea bueno y gratuito. La versión gratuita del compilador está paralizada porque su optimización no es tan buena como la versión "Pro". La versión Pro cuesta aproximadamente US $ 1,000 y solo admite una familia de chips PIC (chips de 8, 16 o 32 bits). Si desea utilizar más de una familia, entonces tiene que comprar otra copia por otros US $ 1,000. La versión "estándar" del compilador realiza un nivel medio de optimización y cuesta alrededor de US $ 500 por cada familia de chips. Los PIC de 8 bits son lentos para los estándares modernos y requieren una buena optimización.
En comparación, hay muchos buenos compiladores de C para MCU de ARM que son gratuitos. Cuando hay limitaciones, esos límites generalmente están en el tamaño máximo de memoria Flash que es compatible. En las herramientas de Freescale Codewarrior, este límite es de 128 KB. Esto es suficiente para la mayoría de las personas en este foro.
La ventaja de usar un compilador de C es que no tiene que molestarse (tanto) con los detalles de bajo nivel del mapa de memoria de la CPU. La paginación en el PIC es particularmente dolorosa y es mejor evitarla si es posible. Otra ventaja es que no tiene que molestarse con el lío de entregar números de 16 y 32 bits en una MCU de 8 bits (o números de 32 bits en una MCU de 16 bits). Si bien no es muy difícil hacer esto en lenguaje ensamblador, es un problema en la parte trasera y es propenso a errores.
Hay otros compiladores que no son ARM C que funcionan bien. El compilador MSP430 parece hacer un trabajo razonable. Las herramientas de Cypress PSoC (especialmente PSoC1) tienen errores.
Modelo de memoria plana
Una MCU que ha paginado RAM / registros / Flash es simplemente estúpido. Sí, estoy hablando de los PIC de 8 bits. Tonto, tonto, tonto. Eso me apagó tanto de los PIC que ni siquiera me he molestado en mirar sus cosas más nuevas. (Descargo de responsabilidad: esto significa que los nuevos PIC podrían mejorarse y simplemente no lo sé).
Con una MCU de 8 bits es difícil (pero no imposible) acceder a estructuras de datos de más de 256 bytes. Con una MCU de 16 bits que se incrementa a 64 kbytes o kwords. Con MCU de 32 bits que sube hasta 4 gigabytes.
Un buen compilador de C puede ocultar mucho de esto al programador (también conocido como You), pero incluso así afecta el tamaño del programa y la velocidad de ejecución.
Hay muchas aplicaciones MCU para las que esto no será un problema, pero, por supuesto, hay muchas otras que tendrán problemas con esto. Se trata principalmente de la cantidad de datos que necesita (matrices y estructuras) en RAM o Flash. Por supuesto, a medida que aumenta la velocidad de la CPU, también aumentan las probabilidades de usar estructuras de datos más grandes.
Tamaño del paquete
Algunos de los PIC pequeños y otras MCU de 8 bits están disponibles en paquetes realmente pequeños. 6 y 8 pines! Actualmente, el ARM Cortex-M0 más pequeño que conozco está en un QFN-28. Si bien un QFN-28 es lo suficientemente pequeño para la mayoría, no lo es para todos.
Costo
El PIC más barato es aproximadamente un tercio del precio del ARM Cortex-M0 más barato. Pero eso es realmente US $ 0.32 vs. US $ 0.85. Sí, esa diferencia de precio es importante para algunos. Pero creo que a la mayoría de las personas en este sitio web no les importa esa pequeña diferencia de costos.
Del mismo modo, cuando se comparan MCU más capaces con el ARM Cortex-M0 / M3 / M4, generalmente el ARM Cortex sale "aproximadamente" o en la parte superior. Al tener en cuenta las otras cosas (facilidad de desarrollo, costos de compilación, etc.), los ARM son muy atractivos.
Segundo resumen
Supongo que la verdadera pregunta es: ¿por qué NO usarías un ARM Cortex-M0 / M3 / M4? Cuando el costo absoluto es super importante. Cuando el consumo de energía súper bajo es crítico. Cuando se requiere el tamaño de paquete más pequeño. Cuando la velocidad no es importante. Pero para la gran mayoría de las aplicaciones, ninguna de estas aplica y el ARM es actualmente la mejor solución.
Dado el bajo costo, a menos que haya una buena razón para no usar un ARM Cortex, entonces tiene sentido usar uno. Permitirá un tiempo de desarrollo más rápido y fácil con menos dolores de cabeza y mayores márgenes de diseño que la mayoría de las otras MCU.
Hay otras MCU de 32 bits que no son ARM Cortex disponibles, pero tampoco veo ninguna ventaja para ellas. Existen muchas ventajas al elegir una arquitectura de CPU estándar, incluidas mejores herramientas de desarrollo y una innovación más rápida de la tecnología.
Por supuesto, las cosas pueden cambiar y lo hacen. Lo que digo es válido hoy, pero podría no serlo dentro de un año o incluso un mes a partir de ahora. Haz tu propia tarea.
fuente
David Kessner está en lo correcto. Me gustaría agregar lo siguiente.
Estoy de acuerdo en que en estos días hay pocas razones para no usar MCU de 32 bits. Solo los usaría [MCU de 8 bits] por 2 razones: me gusta la facilidad del paquete PDIP (no requiere soldadura); A menudo no necesito más potencia / complejidad de lo que puede ofrecer una MCU de 8 bits.
El factor decisivo es realmente las herramientas disponibles.
fuente
Utilizamos un Freescale MCF52259 relativamente anticuado, un MCU de 32 bits ~ 80Mhz capaz.
Las razones / proceso de pensamiento para la elección fueron:
En estos días es más rentable (y conveniente) sobreespecificar / expandir las capacidades del hardware (almacenamiento, velocidad, E / S, etc.) que pasar un valioso tiempo de desarrollo optimizando el código para introducirlo en una MCU marginalmente más barata / más pequeña a menos que sea espacio o El poder son grandes problemas.
En nuestro caso, el dispositivo era el doble de las especificaciones de M.Core por la mitad del precio, ir a un MCU más barato solo ahorraría centavos por placa, pero costaría mucho tiempo de desarrollo y limitaría el potencial de desarrollo futuro sin cambiar nuevamente los MCU.
Si estuviéramos construyendo un millón de tableros, valdría la pena hacer el ejercicio de ingeniería de costos para reducir las cosas, pero tal como están las cosas, no vale la pena el tiempo de desarrollo.
fuente