Velocidad máxima SPI de la pantalla TFT

Tengo una pantalla a color TFT de 1,8" de Banggood. Es muy agradable con los colores vivos.

Sin embargo, la actualización de la pantalla es lenta. Estoy limitado por la velocidad SPI de 1 MHz. Da como resultado una tasa de actualización de:

160 píxeles x 128 píxeles x 16 bits/píxel ÷ 1 MHz = 0,33 s por fotograma

Efectivamente, es aún más bajo ya que Teensy LC se detiene durante aproximadamente 1 ciclo después de cada byte y hay una sobrecarga entre las transacciones SPI. Así que es más como 0,5 s por cuadro o 2 fps, lo cual es muy notable. Es más como una animación de deslizamiento de izquierda a derecha (ver imagen a continuación).

Pantalla TFT de 1,8" con protoboard

Entonces mi pregunta es:

  • ¿La velocidad está limitada por el chip del controlador de pantalla, probablemente un ST7735 ?
  • ¿O la velocidad está limitada por el cableado de mi protoboard?
  • ¿Hay una pantalla más rápida disponible donde pueda usar el bus SPI a 4 u 8 MHz?

Actualizar

Aquí hay una foto de la parte inferior del tablero.

ingrese la descripción de la imagen aquí

No hay mucho que ver:

  • La ranura para tarjeta SD y las tres resistencias R1 a R3 no se utilizan.
  • La resistencia R4 cerca del pin LED (más a la derecha en la imagen) está conectada al pin LED y tiene 7,5 Ω (7R5).
  • La parte con tres patas en la esquina superior dice "V2PK". Supongo que es un regulador de voltaje que se usaría para la operación de 5V. Lo opero a 3.3V. También hay un condensador y un puente abierto cerca de él.

La parte interesante probablemente esté escondida entre la PCB y la pantalla.

Una pregunta aquí debe basarse en información sólida real: debe especificar el chip controlador real y verificar su hoja de datos. Su cableado debe ser bueno para más de 1 MHz. También puede considerar alimentar el SPI a través de un motor DMA en el chip Kinetis de Teensy. Y también debe considerar de dónde provienen los datos: si los está enviando a través del USB, mientras que en teoría eso podría ser rápido, las implementaciones típicas que probablemente haya utilizado podrían ser bastante lentas. Pero al final, no, SPI no se considera una interfaz de visualización de alta velocidad.
Estoy usando el DMA para alimentar el SPI. Y lo he comprobado en el alcance. Teensy puede generar fácilmente SPI adecuado con 2 MHz pero la pantalla deja de funcionar. Lamentablemente, no conozco la especificación exacta del chip del controlador de pantalla, ya que Banggood no la especificó y el chip no se ve en la placa. Sin embargo, basé mi implementación en la hoja de datos del ST7735 y parece coincidir.
@Codo, ¿podría publicar la imagen de la parte inferior de la pantalla? Necesito ver si hay resistencias en serie ... Alternativamente: ¿puede confirmar que la placa es exactamente lo que ha publicado? Como segunda pregunta: ¿probaste sin DMA (¿pero con un spi de 4MHz?)?
He añadido una imagen y una descripción de la parte inferior. No puedo ver ninguna resistencia en serie para MOSI y SCK.
@Codo Podría intentar alimentar la pantalla a 5V: el regulador regulará la potencia a 3.3V (las señales lógicas deben mantenerse a 3.3V). O puede acortar J1.
Después de un análisis más detallado, parece ser un problema de software en lugar de un problema de hardware. Pero aún no he encontrado la causa raíz. Las imágenes se generan en una Mac y se envían a través de USB a Teensy y luego a través de SPI a la pantalla. A pesar de que la imagen se divide en partes de 2K, la transmisión se aceleró a aproximadamente el 80 % de la velocidad de SPI, se implementó una administración de memoria sólida que descarta los datos si es insuficiente, un procesamiento eficiente en los controladores de interrupciones y a través de DMA, parece ocurrir un contratiempo impredecible. para velocidades superiores a 1MHz. La RAM Teensy 8K es bastante pequeña para este tipo de configuración...
Publique la solución como una respuesta automática a su pregunta, en lugar de modificar la pregunta. Definitivamente puede responder sus propias preguntas cuando encuentre soluciones, especialmente si no están completamente cubiertas por otras respuestas.

Respuestas (3)

TSCYCR , el ciclo de reloj serie (lectura) es de 150 ns. Eso es 6,6 MHz. Pero no espere milagros de una pantalla SPI. (podría funcionar bien a 10Mhz)
El software debe optimizarse para actualizar la menor cantidad de píxeles por actualización.

Todavía hay algunas cosas que puede hacer:
- Reducir la profundidad de color.
- Usa una palabra más larga. (por ejemplo: 16 en lugar de 8 bits)
- Asegúrese de que la rutina SPI, si se bloquea, sea lo más corta posible. No espere a que se complete el spi, espere a que el spi esté listo para una nueva palabra.

Si desea una visualización rápida, obtenga una paralela con un búfer de cuadros en el que pueda realizar operaciones.

Gracias por la referencia al TSCYCR. Entonces, el chip, si es un ST7735, debería ser capaz de alcanzar velocidades más altas. Ahora, si supiera qué parte no funciona más allá de 1 MHz. Y en cuanto a los consejos: la optimización para actualizaciones mínimas es sin duda una opción. Posiblemente también reducción de las profundidades de color. El bloqueo ciertamente no es un problema ya que estoy usando DMA. Las palabras más largas solo mejorarían la velocidad en aproximadamente un 6%.
De hecho, TSCYCW (en lugar de TSCYCR) es relevante ya que estoy escribiendo datos en la pantalla. TSCYCW es 66ns, que es 15 MHz. Aún más extraño...
No debe mirar TSCYCR, sino TSCYCW, que es 66ns. Esto significa 15 MHz. Con 8 MHz, puede subir "fácilmente" hasta 20 fps en esa pantalla.
@next-hack sí, eso es correcto. Excepto que cambiar la frecuencia SPI sobre la marcha puede ser un poco inconveniente. Es por eso que fui con el más lento.
Sí, pero por lo general no desea leer de la memoria de la pantalla, simplemente la usa como un dispositivo de solo escritura. Y ese modelo tampoco permite volver a leer los datos de la pantalla.
Resultó ser un problema de software. Pero su respuesta confirmó que aún no había alcanzado el límite de la pantalla. Así que seguí trabajando en ello y encontré la solución.

Obtuve el mejor resultado (más de 30 fps) usando la biblioteca TFT_eSPI https://github.com/Bodmer/TFT_eSPI donde el contenido se almacena en un sprite. La velocidad en baudios establecida en el archivo de configuración que funcionó a la perfección (en mi placa) fue. Este código se estaba ejecutando en un ESP32 que estaba conectado a la pantalla.

#define SPI_FRECUENCIA 40000000

Ahora está funcionando correctamente. En un Teensy LC funciona a 16 MHz, en un Teensy 3.2 funciona a 18 MHz. Ambas son las velocidades de reloj SPI máximas para estas placas.

Resultó ser un problema de software. El principal problema era que no había desactivado correctamente DMA. Entonces se activaría demasiado pronto en la siguiente transmisión SPI, es decir, comenzaría con el primer byte de la transmisión aunque se suponía que debía comenzar en el segundo byte. Esto mezcló algunas cosas y dejó al dispositivo esperando que se transmitiera el último byte.

Todavía no entiendo realmente por qué funcionó en frecuencias más bajas pero falló en las más altas.

Velocidad máxima SPI de la pantalla TFT
RespuestasAquíPolítica de privacidad1y, 0v