Actualmente estoy trabajando en una PCB para un cubo LED de 8x8x8. El diseño de PCB en el estado actual se puede encontrar a continuación:
El ATmega328P (16Mhz) utilizará SPI para enviar los datos necesarios a cuatro chips TLC5940 (escala de grises de 12 bits, controlador LED de 16 canales) y un TPIC6B595 (registro de desplazamiento de 8 bits). Para obtener FPS lo suficientemente alto y aún tener suficiente tiempo de CPU para los efectos, la interfaz SPI debe ejecutarse a 8 MHz.
No estoy seguro del diseño correcto para evitar problemas como datos dañados.
Partes de diseño relevantes para estas preguntas:
A) Datos SPI: desde el pin ATmega SPI hasta el primer TLC y luego conectados en cadena a través de los siguientes tres TLC hasta el TPIC (cada rastro ~ 2-3 cm de largo)
B) Reloj SPI: desde el pin del reloj SPI de ATmega en dos direcciones. En primer lugar, al encabezado del ISP correspondiente y, en segundo lugar, en todos los TLC al TPIC. Cada pin de reloj de datos TLC está conectado por una rama muy corta de la línea de reloj. La línea termina en el pin de reloj del chip TPIC. (longitud total de la línea ~ 23-25 cm de largo sin ramas)
C) Reloj GS: Necesario para mantener en funcionamiento el PWM de escala de grises de los TLC. A través del fusible CKOUT establecido, se envía una señal constante de 8 Mhz a través de esta línea a todos los pines del reloj en escala de grises TLC (~20 cm de largo sin ramas).
D) En blanco: De ATmega a todas las TLC, terminando en la última. Por lo general, nivel GND, alternado regularmente para restablecer el contador PWM en TLC. Durante la actualización de datos para los TLC, es alto durante los primeros bytes transmitidos y luego se vuelve a establecer bajo mientras el resto de los bytes se desplazan hacia afuera (para reducir el tiempo de inactividad del LED)
E) Latch: Desde ATmega conectado a todas las TLCs y el chip TPIC. Siempre bajo excepto por un cambio rápido (cuando SPI no está activo)
F) Capas de PCB: Líneas rojas arriba, líneas azules abajo. El fondo tiene además un relleno de suelo completo, como se ve en la ampliación de un TLC:
Mis preguntas sobre el diseño de transmisión de datos:
1) ¿Está bien enrutar esas líneas más de ~14 cm en paralelo? Blank y latch ("líneas tranquilas") están en el medio y las líneas "ruidosas" GS Clock y SPI clock en el exterior (0,05 pulgadas de distancia entre cada línea), pero por lo tanto cerca de los pines IC.
2) ¿Están bien las ramas cortas de 90° para conectar cada IC a las líneas de datos o esto creará problemas?
3) ¿Qué pasa con la reflexión/terminación de la señal (para el reloj SPI y GS)? He leído varios artículos sobre ese tema, pero realmente no entendí todo. Algunas personas afirman que a 8Mhz no hay problema. Otros diferencian entre la duración del trance y así sucesivamente. Algunas soluciones, como la terminación de la línea final, aparentemente solo funcionan para una sola carga, por lo tanto, esto obviamente no funcionará para mí. Hasta ahora no he encontrado nada concreto/claro con respecto a este tema. Siento que esto podría ser un factor decisivo para mi tablero en este momento.
4) ¿Qué pasa con la ruta de retorno de la señal? Traté de hacer posible que la corriente de retorno siguiera el rastro superior relevante en la capa inferior, pero quedan algunos obstáculos (como las conexiones del reloj GS, el pestillo y los rastros en blanco a los pines del PLC). ¿Sigue siendo aceptable el diseño a este respecto?
Atentamente,
ratuso
Esta respuesta ( ¿Se necesitan resistencias de terminación para UART, I2C y SPI? ) básicamente le dice que un SPI de 50 MHz probablemente sea bueno para pistas de> 7 cm. Todo lo que tiene que hacer es mantener el reloj y los datos aproximadamente de la misma longitud. El SPI unidireccional es bastante indulgente debido a la naturaleza dual de registrar los datos en un borde y luego volver a registrarlos en el otro.
A 8 MHz, el período es de 125 ns y el tiempo dado para que los datos se asienten (después de que cambien en un flanco de reloj) es, por lo tanto, de 62 ns. Tendría que hacer que las longitudes de las líneas de datos y SCL sean enormemente diferentes para llegar a un retraso cercano a los 60 nanosegundos.
Esta respuesta solo se aplica al envío de datos desde un maestro; surge otro problema mayor cuando se vuelven a ingresar datos desde un esclavo: esto determina la longitud máxima de la pista / cable en última instancia, pero si solo está enviando datos de maestro a esclavo, entonces no hay problema.
usuario98663
usuario98663
oscuro