¿Modo SPI multimaestro? ¿O alguna forma inteligente de cambiar solo el tiempo entre dos maestros?

Tengo una pantalla LCD que funciona con un micro bastante potente, con GPU y todo tipo de cosas. Sin embargo, resulta que tardará más de 5 segundos en arrancar el núcleo. Desde la perspectiva de la experiencia del usuario, 5 segundos para ver cualquier imagen/animación de inicio en la pantalla después del encendido es inaceptable.

Así que estaba pensando en incluir un micro separado muy barato que pueda mantener la línea maestra durante los primeros segundos y proporcionar la imagen de arranque. Luego entregaría el bus SPI al micro principal.

Por supuesto, este no es el único caso de uso del micro más pequeño. También lo usaría para todo el control de la retroiluminación. El micro más grande podría entrar en un estado de suspensión y me gustaría que el micro más pequeño aún mantuviera la pantalla encendida. (Entonces, básicamente, el micro principal simplemente le dirá al micro pequeño qué brillo mantener encendido y un brillo predeterminado en caso de que el micro principal duerma).

¿Hay alguna manera de que pueda mantener el micro pequeño como maestro durante los primeros 5 segundos y luego dejarlo ir al micro principal por el resto del tiempo (y como beneficio adicional, devolvérselo al micro pequeño cuando el micro principal entre en modo de suspensión) )?

¡Gracias!

Para que quede claro: SPI es el método de comunicación entre los dos micros, así como con LCD, ¿verdad? ¿Tiene alguna E/S de repuesto en el micro pequeño y el micro principal que se pueda usar para enviar señales entre ellos?
Bueno, tendré SPI entre la pantalla LCD y el micro principal y la pantalla LCD y el micro pequeño. Lo más probable es que las comunicaciones entre el micro pequeño y el micro principal sean algo como UART o I2C. ¿Esto complicaría las cosas en absoluto?

Respuestas (4)

El principal problema aquí es probablemente no elegir un MUX adecuado; la mayoría de los interruptores analógicos probablemente funcionarán. Sino más bien cómo sincronizar "GPU" y "MCU". Debido a que MCU debería estar hablando la mayor parte del tiempo, excepto cuando GPU toma el control, entonces debería estar en silencio.

La GPU no puede simplemente cortar los cables SPI cuando le plazca, porque entonces corromperá una transferencia SPI en curso. Esto puede tener efectos secundarios muy malos si la MCU se interrumpe al escribir comandos en la pantalla.

Puede resolver esto haciendo que los dos dispositivos escuchen entre sí/líneas SS y use eso como un medio de "arbitraje".

GPU:

  • Cuando la salida de línea /SS de MCU esté baja, permanezca en silencio durante la transmisión en curso.
  • Cuando /SS de MCU sube, tome el bus iniciando una transferencia SPI y, por lo tanto, extraiga /SS de GPU bajo.

UCM:

  • Antes de iniciar una transmisión SPI, verifique la línea /SS de la GPU.
  • Si la línea /SS de GPU es alta, podemos enviar.
  • Si la línea /SS de la GPU es baja, pase a modo pasivo/suspensión durante un cierto período de tiempo, antes de volver a comprobarlo.

MUX:

  • Conéctelo de modo que las dos líneas /SS diferentes se utilicen como selección de canal, determinando la fuente de MOSI y CLK. (MISO no debería ser necesario para la mayoría de las pantallas). Ya sea encontrando un interruptor adecuado o invirtiendo la señal de uno de los maestros a través de BJT o similar.
  • Quizás pueda hacer que la MCU/SS sea recesiva conectándola a través de una resistencia de extracción de 10k, de modo que la GPU/SS pueda anularla sin tener dos salidas compitiendo. Supongo que hay muchas maneras de resolver esto.
Revisé esto antes y me dijeron que no se pueden hacer cambios en la placa con la GPU. Esta placa utiliza búferes de conversión de nivel, por lo que la línea SS que llega desde aquí a la placa LCD es unidireccional. Entonces, la GPU no tendría forma de ver si la MCU ha bajado o alto la línea. Así que tendré que usar su última declaración con HLP anulando la MCU.
@HassanNasir No necesita cambiar la placa de la GPU, solo el firmware de la GPU. El MUX, los convertidores de nivel, los conmutadores de polaridad, etc. se pueden colocar en una placa entre la placa GPU y la placa LCD. Aunque si la GPU no puede escuchar /SS, entonces no veo cómo puede hacer que esto funcione bien. Obtendrá perturbaciones en la pantalla cada vez que la GPU interrumpa la MCU.
En lugar de escuchar la línea /SS (que no puede debido a los búferes de conversión de nivel), ¿podría usar la interfaz i2c con el pequeño micro para verificarlo antes de enviar algo?
@HassanNasir ¿Simplemente usar un convertidor de nivel bidireccional? 74HCT245 o similar.
El convertidor de nivel está en la PCB con el micro principal que no se puede cambiar. El cambio a un convertidor bidireccional agregaría costos, lo que haría aún más difícil realizar dichos cambios.

Probablemente sería más sencillo elegir un "micro pequeño" que tenga dos interfaces SPI. Utilice uno como maestro para controlar la pantalla y el otro como esclavo conectado al "micro grande".

Luego, el firmware de su micro pequeño puede arbitrar entre pasar las transacciones del micro grande a través de la pantalla y enviar sus propios comandos.

Tenga en cuenta que enviar datos a la pantalla de esta manera es sencillo. Pero si el gran micro necesita leer algo de la pantalla, se requiere pensar un poco más.

es posible? El micro principal utilizará su GPU para enviar varias animaciones a la pantalla LCD a una alta velocidad de fotogramas. Agradezco que el micro más pequeño no esté realizando ningún procesamiento en este momento, pero ¿aún puede actuar como un medio para enviar a través de los comandos SPI? Supongo que debería funcionar siempre que haya suficiente ancho de banda en el bus SPI.
Tal vez no. Para ser honesto, antes de comenzar a considerar las soluciones de hardware, estaría observando de cerca la secuencia de arranque del micro grande, así que vería si no se podía insertar algún código en un punto temprano para inicializar la pantalla y colocar su imagen de salpicadura. ¿Qué tipo de procesador es de todos modos? Nunca antes había oído hablar de una GPU que emitiera a SPI.
También consideré esto cuando escribí mi respuesta. Es la solución más fácil pero tendrá una latencia de 1 cuadro SPI en el mejor de los casos. SPI a LCD a menudo también es bastante rápido, por lo que es posible que deba "DMA a través" de los datos. Si ese tipo de retraso es aceptable, esta es la solución más fácil.

La forma directa de implementar lo que desea es insertar algunos circuitos entre los procesadores y la pantalla. Este circuito puede tomar dos formas:

  1. Utilice un chip multiplexor de cuatro bits de ancho que pueda multiplexar las cuatro líneas de control SPI (SPI_CS, SPI_CLK, MISO, MOSI) para cada uno de los dos maestros a la interfaz de pantalla. El control de selección para el MUX vendría de su MCU de bajo costo.
  2. Utilice dos búferes triples separados de 4 bits de ancho para seleccionar una interfaz maestra u otra para la interfaz SPI en la pantalla. Normalmente, se usaría la misma parte para ambos maestros y, por lo tanto, se necesitarían dos líneas de control desde la MCU de bajo costo para controlar el estado triple de los dos búferes (u otra puerta inversora agregada). Alternativamente, con una cuidadosa selección de piezas, puede encontrar dos chips de búfer tristate, uno con una habilitación alta activa y el otro con una habilitación baja activa que luego pueden conectarse y controlarse desde un pin de la MCU de bajo costo.

Este esquema requiere que tenga cuidado cuando cambia la pantalla de un maestro a otro. Le gustaría evitar cambiar mientras hay una transacción SPI activa en curso en la interfaz. Algunos dispositivos pueden confundirse cuando esto sucede. Otros dispositivos SPI se recuperarían simplemente llevando la señal SPI_CS al nivel inactivo durante un período de tiempo.

El interruptor analógico Quad SPDT también serviría como http://www.ti.com/lit/ds/symlink/ts3a5018.pdf Ese es un nivel de 3.3V, también hay interruptores de nivel de 5V.

¿Modo SPI multimaestro? ¿O alguna forma inteligente de cambiar solo el tiempo entre dos maestros?
RespuestasAquíPolítica de privacidad1y, 0v