Ventajas de los microprocesadores de 32 bits y 48-96 Mhz (como en Arduino Due)


10

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.


Bueno, lo primero que tengo en mente es que puedes procesar transmisiones de video en vivo, donde el Arduino no puede manejar eso. También permite algoritmos de cifrado avanzados o hashing (más rápido y más fácil que en Arduino). Me sorprende que Arduino haya lanzado una plataforma de 32 bits, pero solo muestra que algunas personas solo quieren hacer algo más que controlar un relé. ¡Es un gran día para Arduino!
Piotr Kula

No estará haciendo más que un trivial procesamiento de video en vivo en un procesador <100 MHz, a menos que lo haga en un núcleo de función especial adjunto. Y especialmente no en la memoria RAM bastante limitada en estos dispositivos. Un punto más realista es que el costo de estos chips simplemente no es sustancialmente más alto que el de las partes de 8 bits; puede ser más bajo que un ATMEGA con flash y ram comparables.
Chris Stratton

3
Hasta donde yo sé, Parallax Propeller es un chip personalizado sin relación con PIC32. ¿Alguna fuente de conexión?
AndrejaKo

Respuestas:


12

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.


1
Para acceder a cualquier ubicación de memoria con el ARM, primero se debe cargar un registro con una dirección que esté dentro de 4K; A muchos dispositivos de E / S se les asigna más de 4K de espacio de direcciones, aunque muchos solo usan unas pocas direcciones discretas. Por el contrario, los PIC 18Fxx pueden operar directamente en la mayoría de las ubicaciones de E / S con una sola instrucción, independientemente del estado de la banca. El medio por el cual se deposita la mayor parte de la RAM es bastante molesto, pero para ciertos tipos de bit-banging (el propósito para el que se diseñó la arquitectura PIC en la década de 1970) la arquitectura PIC funciona muy bien.
supercat

1
Por cierto, me parece curioso que, si bien un popular microprocesador de 8 bits de la década de 1970 podría procesar de manera eficiente estructuras de datos de 256 bytes alineados arbitrariamente, y un procesador de 16 bits popular podría funcionar bien con estructuras de datos de 65.536 bytes alineados en 16 límites de bytes o estructuras de datos alineadas arbitrariamente que procesadores de 8 y 16 bits más grandes y nuevos dificultan la escritura de código eficiente que se extiende a horcajadas sobre los límites de página / banco.
supercat

@supercat El rango de direcciones 4K para una instrucción de "Desplazamiento inmediato LDR / SRT" es verdadero, pero a menudo no es un problema. No estoy de acuerdo con el resto de tu comentario. Mirando los documentos Freescale M4, cada periférico no ocupa más de 4K del rango de direcciones, por lo que un solo "puntero de dirección base" es suficiente para acceder a todos los registros en ese periférico. También hay 32 registros de propósito general, cualquiera de los cuales se puede usar como un puntero de dirección base, por lo que acceder a múltiples periféricos rápidamente en la misma sección de código es relativamente sencillo.

1
@supercat Su segundo punto toca todo el debate RISC vs. CISC. ARM es una CPU RISC, lo que significa que está optimizada para realizar las tareas más frecuentes. Las tareas que no son frecuentes, como los accesos no alineados, requieren más trabajo o más tiempo (dependiendo del arco de la CPU). Veo esto como algo positivo, no negativo. Es por eso que obtenemos MCU rápidos de 32 bits por el precio de un viejo de 8 bits. Incluso con estas peculiaridades, tomaría una de estas CPU en un PIC cualquier día.

Hablo mal No quise decir que un registro base no podía manejar un periférico completo, sino que a menudo tenía que cargarse un registro para cada periférico (por lo que uno no podía simplemente dejar un registro sentado con IO_BASE_ADDR todo el tiempo) ) Para algunos tipos de código, puede ser muy útil poder establecer un bit de E / S en un solo ciclo con una instrucción como "bsf LATA, 4", sin tener que precargar ningún registro primero. Me gusta el ARM, pero el mapeo de E / S directa en el PIC puede ser bastante bueno (lástima que otros accesos a la memoria no sean tan buenos).
supercat

3

David Kessner está en lo correcto. Me gustaría agregar lo siguiente.

  1. Las MCU de 8 bits son las únicas MCU disponibles en paquetes PDIP que son fáciles de manejar y pegar en una placa de prototipos.
  2. Las MCU de 32 bits pueden usar menos energía que las MCU de 8 bits. No es necesariamente cierto que la MCU de 8 bits <20 MHZ utilizará menos energía que una Cortex M4.
  3. Las MCU de 8 bits a menudo son utilizadas por aficionados que generalmente no requieren mucho de la MCU. Tal vez unos cientos de líneas de código C simple.

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.


Para la creación de prototipos, hay sockets para LQFP, que funcionan bastante bien. Y, por supuesto, puede soldar LQFP a mano, solo requiere un poco de práctica. QFN, DFN y BGA No soldaría a mano, pero luego cada MCU de 32 bits de gama baja en el mercado viene con LQFP.
Lundin

1

Utilizamos un Freescale MCF52259 relativamente anticuado, un MCU de 32 bits ~ 80Mhz capaz.

Las razones / proceso de pensamiento para la elección fueron:

  • Estaba reemplazando un dispositivo M. Core de 32 bits, por lo que la transferencia era relativamente simple
  • También significaba que podíamos seguir con el IDE existente (CodeWarrior)
  • Necesitábamos mucho IO: control de paso / dirección en 3 motores paso a paso, 4 canales de PWM, 3 UART e I2C y SPI.
  • Sucedían muchas cosas (vea el último punto) y algunas de ellas debían suceder de manera oportuna, por lo que debíamos asegurarnos de que hubiera suficientes ciclos de CPU para hacer todo.
  • El código heredado chocaba con el tamaño del flash de 256k y la RAM de 32k del M.Core, por lo que duplicar el flash y la RAM hizo que la vida fuera fácil de poner en funcionamiento rápidamente.

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.