El Flash A25L032 tiene un modo de lectura normal y un modo de lectura rápida. También tiene modos de lectura dual y cuádruple que se explican por sí mismos. Sin embargo, la diferencia entre los modos normal y rápido no está del todo clara.
¿Qué hace que el modo rápido sea rápido? ¿ya que ambos usan un solo MISO de SPI? Sus diagramas de tiempo están abajo:
Lecturarápida:
¿Qué hace que el modo rápido sea rápido?
La diferencia está ciertamente bien oculta :-) Mire la tabla de Características de CA en la hoja de datos . Dice que el comando normal READ (03h) tiene una frecuencia de reloj máxima de 65 MHz. Mientras que todos los demás comandos, por lo tanto, incluyen el comando FAST_READ (0Bh), tienen una frecuencia de reloj máxima de 100 MHz:
EstaeslarazónporlacualFAST_READpuedesermásrápido,dependiendodelafrecuenciaderelojrealelegida.
Sinembargo,debidoaldummybyterequeridocuandoseusaelcomandoFAST_READ(peronocuandoseusaelcomandonormalREAD),siamboscomandosseusanparamuchossmallleeconunafrecuenciaderelojde<=65MHz,entonceselrendimientodelosdatosseríamáslentocuandoseusanloscomandosFAST_READ,encomparaciónconloscomandosREAD,debidoalasobrecargadetodoslosbytesficticios(unoporcadacomandoFAST_READenviadoaldispositivo).
Siseusaunafrecuenciaderelojmásrápida(>65MHz),ysiseusanmenoscomandosdeFAST_READ(perolasobrecargadelbyteficticioes"por comando"), entonces el mayor rendimiento comenzaría a ser mayor que sobrecarga de los bytes ficticios.
¿Por qué no tener un solo modo que pueda funcionar hasta 100MHz?
Esto está entrando en el ámbito de la especulación: sospecho de que se requiere una latencia mínima interna para iniciar el proceso de lectura de datos (¿quizás se esté cargando la bomba de carga interna?).
Mi hipótesis es que la latencia podría estar "oculta" detrás del tiempo requerido para recibir el comando READ a < = 65 MHz (es decir, velocidades relativamente más lentas), pero la latencia requerida (antes de comenzar a leer) es más larga que el tiempo necesario para recibir un comando READ a > 65 Mhz (es decir, velocidades relativamente más rápidas). Eso podría explicar por qué se necesita un protocolo de comando diferente (que agrega un byte adicional antes de que comience la fase de lectura de datos) para una lectura de velocidad más rápida. Se requiere un byte ficticio para los comandos FAST_READ y FAST_READ_DUAL_OUTPUT , y se requiere un byte de modo para el comando FAST_READ_DUAL_INPUT_OUTPUT . Todos estos bytes sirven para retrasar el inicio de la fase de salida de datos, lo que me sugiere un requisito de latencia interna fija, algo que he visto antes con otros dispositivos. Por supuesto, la verdadera respuesta tendría que venir del fabricante :-)
Después de haber recibido un cierto número de bits de dirección, un chip flash puede iniciar el proceso de lectura de una fila. Ese proceso se puede llevar a cabo simultáneamente con la recepción de los siguientes bits de la dirección. Si el maestro logra terminar de enviar la dirección y comenzar a descontar los datos antes de que el dispositivo esté listo, el dispositivo no podrá descartar los datos válidos (ya que no estaría disponible en la lógica de salida) y, en su lugar, se descartaría. datos erróneos.
Si el maestro hiciera una pausa suficiente entre el envío del borde ascendente del último bit de la dirección y el borde descendente para leer la primera palabra de los datos, al dispositivo probablemente no le importaría que la dirección y los datos estuvieran sincronizados. Tarifa de 100MHz o la más lenta de 65MHz. Sin embargo, en muchos casos es más fácil para un maestro del bus marcar una palabra adicional que demorar durante un breve período de tiempo, por lo que se especifican dos formas de leer los datos (use una velocidad de datos lo suficientemente lenta para eliminar la necesidad de una pausa, o inserte un byte ficticio para generar efectivamente una pausa de 80 ns, que se puede lograr con relojes de velocidad uniforme, simplificando la especificación si hubiera tenido que incluir un tiempo mínimo entre la recepción de un bit de dirección particular y el Lectura del primer bit de datos. En la mayoría de los casos en los que un sistema podría recibir datos a más de 65MHz, podría enviar el comando de lectura de alta velocidad completo con un byte extra en menos tiempo del que se necesitaría para enviar el comando de velocidad lenta a 65Mhz. Si bien hay algunos casos en los que el hardware para enviar un comando se limitaría a 65MHz, pero el hardware para registrar los datos podría hacer 100Mhz (*), y si bien podría haber sido útil si la especificación brindara ese escenario al decir que: el comando podría registrar los datos a 100Mhz una vez que el comando se haya transmitido por completo, no creo que tener que registrar el dummy adicional sería una dificultad incluso en ese caso.
(*) Este escenario sería principalmente relevante en los casos en que los datos se envían directamente a algún otro dispositivo. Como ejemplo simple, un dispositivo para emitir visualizaciones de video compuesto estático almacenado en la ROM puede usar datos almacenados como muestras empaquetadas de seis bits para cronometrar a una velocidad de cuatro muestras por ciclo de croma de 3,579,545.45Hz (una velocidad de datos de aproximadamente 85,909,090.9 bit / s -más rápido que 65Mhz). Si el microcontrolador estuviera funcionando a esa velocidad de reloj, su puerto SPI solo podrá funcionar a la mitad de esa velocidad, pero podría cambiar la fuente del reloj del chip flash entre el reloj SPI y el reloj sin procesar de 85.9MHz.
El circuito de detección interno toma alrededor de 15 ~ 20 ns (1 ~ 1.5 ciclos) para distinguir los datos. Con el sentido de datos de palabras, el circuito interno usa el ciclo de entrada A0 para detectar los datos del núcleo y luego marcar el punto A0. Por lo tanto, < 65MHz no necesita ciclos ficticios. Si va más allá de 65MHz, el circuito interno necesita un reloj exta para preparar los datos.
Si ese diseño de chip tiene doble sentido de palabra, entonces puedes intentar LEER con un reloj más rápido.