¿Una tarjeta SD en modo SPI respeta la selección de chip/selección de esclavo? Parece que se está reiniciando en mi aplicación

Tengo una aplicación donde tengo un microcontrolador (NXP LPC1343 ) que está conectado a un FPGA a través de SPI de 16 bits. También hay una tarjeta SD que usa el mismo puerto SPI (MISO/MOSI) pero con un pin CS/SS diferente (ambos son activos bajos, según la especificación SPI). Una de las cosas que debo hacer es escribir datos del FPGA en un archivo en la tarjeta SD usando FAT32 , y este es el trabajo del microcontrolador. El microcontrolador ejecuta FatFS , que he llegado a funcionar de manera confiable por sí mismo.

Debido a que el microcontrolador solo tiene una pequeña cantidad de RAM, solo se puede almacenar en búfer una pequeña cantidad de datos a la vez. Por lo tanto, el micro tiene que leer un búfer del FPGA, cambiar el modo SPI a 8 bits y luego escribir esos datos en el FATFS. Recuerde que para configurar la tarjeta SD para el modo SPI, se debe enviar un comando mientras el bus SPI está funcionando a 400 kHz, y tiene que pasar una cierta cantidad de espera. Por lo tanto, me gustaría tener que realizar la inicialización solo una vez.

Sin embargo, realizar transacciones en la FPGA incluso mientras se mantiene CS alto en la tarjeta SD parece poner la tarjeta SD en un estado extraño, de modo que necesita pasar por la inicialización nuevamente. Esto, por supuesto, no es deseable, ya que la inicialización puede tomar varios milisegundos, para escribir solo 4 kB o más de datos (nuevamente limitado por la pequeña capacidad de RAM de mi micro). Como necesito escribir varios megabytes lo más rápido posible, esto reduce el rendimiento de unos 500 kB/s a menos de 100 kB/s.

Soy consciente de que las tarjetas SD no son técnicamente totalmente compatibles con SPI, pero ¿cómo se puede solucionar este problema?

Debería honrarlo, hasta donde yo sé. ¿Tal vez pruebe con una tarjeta SD diferente?
Esta es una gran pregunta. Gracias por preguntar (y responder) eso.

Respuestas (1)

Está bien, lo descubrí en realidad. Debería haber googleado un poco más profundo. Resulta que las tarjetas SD no actúan exactamente como dispositivos SPI cuando comparten un bus de acuerdo con Cómo usar MMC/SDC :

En el bus SPI, cada dispositivo esclavo se selecciona con señales CS separadas y varios dispositivos se pueden conectar a un bus SPI. El dispositivo esclavo SPI genérico impulsa/libera su señal DO mediante la señal CS de forma asíncrona para compartir un bus SPI.

Sin embargo, MMC/SDC activa/libera la señal DO al sincronizarse con el SCLK. Esto significa que existe la posibilidad de un conflicto de bus con MMC/SDC y cualquier otro esclavo SPI conectado a un bus SPI. La imagen de la derecha muestra la temporización de activación/liberación del MMC/SDC (la señal DO se lleva a 1/2 V cc para ver el estado del bus). Por lo tanto, para hacer que MMC/SDC libere la señal DO, el dispositivo maestro debe enviar un byte después de que se desactive la señal CS.

La tarjeta SD y la FPGA probablemente estaban tratando de impulsar DO y la tarjeta SD se perdió, por lo que se reinició. Enviar un byte adicional parece haberlo solucionado.

Esto te permite alternar entre la FPGA y la tarjeta, ¿verdad? ¿También encontró que podría interrumpir durante la transferencia de datos y reanudar? Por lo que dice en elm-chan, parece que eso no es posible, pero me interesaría saber si lo confirmaste o lo desaprobaste.
Sí, funciona como se esperaba para alternar entre FPGA y SD, pero no puede interrumpir la transferencia entre llamadas a FatFS. Al menos no pude hacer que funcionara. Eso significa que no puede (por ejemplo) responder a una interrupción durante la escritura y lectura de un archivo desde un sensor usando el bus SPI compartido.