¿Por qué los dispositivos relativamente más simples, como los microcontroladores, son mucho más lentos que las CPU?

Hay otros factores que contribuyen a la velocidad.

• Memoria: el rendimiento real suele estar limitado por la latencia de la memoria. Las CPU de Intel tienen cachés grandes para compensar esto. Los microcontroladores no suelen hacerlo. La memoria flash es mucho más lenta que la DRAM.

• Consumo de energía: a menudo es un gran problema en las aplicaciones integradas. Las CPU Intel de 200 MHz reales consumieron más de 10 vatios (a menudo mucho más) y necesitaron un gran disipador de calor y un ventilador. Eso requiere espacio y dinero, y ni siquiera cuenta la lógica externa y la memoria que lo acompaña. Un AVR de 20 MHz toma aproximadamente 0,2 vatios, que incluye todo lo que necesita. Esto también está relacionado con el proceso: los transistores más rápidos tienden a tener más fugas.

• Condiciones de funcionamiento: como señala Dmitry en los comentarios, muchos microcontroladores pueden operar en un amplio rango de voltaje y temperatura. Ese ATMega que mencioné anteriormente funciona de -40C a 85C, y puede almacenarse en cualquier cosa desde -65C a 150C. (Otras MCU funcionan hasta 125C o incluso 155C). El voltaje VCC puede ser de 2.7V a 5.5V (5V +/- 10% para un rendimiento máximo). Esta hoja de datos del Core i7 es difícil de leer, ya que recortan el VCC permitido durante la fabricación, pero las tolerancias de voltaje y temperatura son ciertamente más estrechas: ~ 3% de tolerancia de voltaje y temperatura máxima de unión de 105C. (Mínimo 5C, pero cuando se tira de > 100 amperios, las temperaturas mínimas no son realmente un problema).

• Recuento de puertas: Más simple no siempre es más rápido. Si lo fuera, Intel no necesitaría arquitectos de CPU. No es sólo la tubería; También necesitas cosas como una FPU de alto rendimiento. Eso aumenta el precio. Muchas de las MCU de gama baja tienen CPU de solo enteros por esa razón.

• Presupuesto del área del troquel: los microcontroladores tienen que ajustar una gran cantidad de funcionalidad en un solo troquel, que a menudo incluye toda la memoria utilizada para la aplicación. (SRAM y la memoria flash NOR confiable son bastante grandes). Las CPU de las computadoras hablan con periféricos y memoria fuera del chip.

• Proceso: esos 5V AVR se realizan en un proceso antiguo de bajo costo. Recuerda, fueron diseñados desde cero para ser baratos. Intel vende productos de consumo con altos márgenes utilizando la mejor tecnología que el dinero puede comprar. Intel también está vendiendo CMOS puro. Los procesos de MCU necesitan producir memoria flash en chip, que es más difícil.

Muchos de los factores anteriores están relacionados.

Puede comprar microcontroladores de 200 MHz hoy ( aquí hay un ejemplo ). Por supuesto, cuestan diez veces más que los 20 MHz ATMegas ...

La versión corta es que la velocidad es más complicada que la simplicidad, y los productos baratos están optimizados para ser baratos, no para acelerar.

Una de las principales razones técnicas subyacentes para las bajas velocidades es que las MCU baratas / pequeñas solo usan memoria flash en el chip para el almacenamiento del programa (es decir, no se ejecutan desde la RAM).

Las MCU pequeñas generalmente no almacenan en la memoria caché del programa, por lo que siempre necesitan leer una instrucción de flash antes de ejecutarla, cada ciclo. Esto proporciona un rendimiento determinante y # ciclos / operación, es más barato / más simple, y evita problemas similares a las PC donde el código y los datos se mezclan creando un nuevo conjunto de amenazas de desbordamientos de búfer, etc.

La latencia de lectura de la memoria flash (en el orden de 50-100ns) es mucho más lenta que la lectura de SRAM o DRAM (en el orden de 10 ns o inferior), y esa latencia debe incurrirse en cada ciclo, lo que limita el reloj. velocidad de la pieza.

¿Por qué la gente monta una bicicleta o una pequeña motocicleta cuando tienes un automóvil de Fórmula 1? Seguramente debe ser mejor conducir, digamos 300 km / hy llegar a todas partes al instante.

En pocas palabras, no hay necesidad de ser más rápido de lo que son. Quiero decir, seguro que hay un poco y los microcontroladores más rápidos permiten algunas cosas, pero ¿qué vas a hacer al decir una máquina expendedora que está en uso continuo durante aproximadamente 1 hora al día? ¿Qué vas a hacer en un mando a distancia para un televisor?

Por otro lado, tienen otras capacidades importantes, como el bajo consumo de energía, que son MUCHO más sencillas de programar, etc. Básicamente, no son procesadores y hacen cosas diferentes.

Hay muchos controladores ARM que se ejecutan a cientos de MHz o más. ¿Quién necesita un PIC de 500 MHz y está dispuesto a pagar lo suficiente por parte para justificar máscaras de un millón de dólares para un proceso cercano al estado de la técnica?

El popular ATmega328 se ha hecho con tecnología de 350 nm, que está bastante por detrás de las últimas CPU de Intel de producción ( 14 nm para Skylake ).

Incluso los controladores de 8 bits más económicos han ido aumentando lentamente en velocidad, y puede obtener controladores PIC de 32 y 64 MHz (por ejemplo, PIC18F14K22) que aún funcionan a 5 V (esto último es una consideración en el costo total del sistema ).

Una consideración es que estos controladores tienen una arquitectura que está optimizada para espacios de memoria pequeños y velocidades de reloj lentas. Una vez que comienza a alcanzar altas velocidades de reloj, tiene que reajustar las cosas con preescaladores, etc.

Se hizo un intento hacia atrás (a fines de la década de 1990) para producir controladores tipo PIC muy rápidos, con la idea de que el firmware podría sustituir a los periféricos si el microcontrolador fuera lo suficientemente rápido. Por ejemplo, podrías golpear un UART. No creo que todos fueran tan exitosos comercialmente- Scenix- > Ubicom- > Qualcomm (juego terminado).

Imagina que uno quiere producir automóviles. Un enfoque sería utilizar un conjunto de equipos en la fábrica de forma secuencial, construyendo un automóvil a la vez. Este enfoque se puede hacer con una cantidad modesta de equipo moderadamente complicado, por lo que muchos equipos pueden usarse para realizar más de un paso. Por otro lado, gran parte del equipo en la fábrica todavía estaría inactivo la mayor parte del tiempo.

Otro enfoque es configurar una línea de ensamblaje, de manera que tan pronto como el equipo que realizó el primer paso de la producción haya terminado esa operación en el primer automóvil, pueda comenzar a iniciar la operación correspondiente en el próximo automóvil. Tratar de reutilizar un equipo en varias etapas del proceso de fabricación sería complicado, por lo que en la mayoría de los casos sería mejor usar más equipos que estén optimizados para realizar una tarea muy específica (por ejemplo, si es necesario perforar 50). agujeros de 10 tamaños diferentes, luego una configuración mínima del equipo incluiría un taladro con 10 bits y un mecanismo de cambio rápido, pero una línea de ensamblaje podría tener 50 taladros, cada uno con un bit instalado permanentemente y sin necesidad de un cambio rápido) .

Para cosas como DSP o GPU, es posible alcanzar velocidades muy altas a precios relativamente bajos porque la naturaleza del trabajo a realizar es muy consistente. Desafortunadamente, muchas CPU deben ser capaces de manejar errores arbitrarios de instrucciones de diferente complejidad. Hacer eso de manera eficiente es posible, pero requiere una lógica de programación muy compleja. En muchas CPU modernas, la lógica necesaria para "hacer el trabajo" no es demasiado complicada o costosa, pero sí lo es la lógica necesaria para coordinar todo lo demás.