9 votos

¿Una tarjeta SD en modo SPI respeta el chip select/slave select? Parece que se reinicia en mi aplicación

Tengo una aplicación donde tengo un microcontrolador (NXP LPC1343 ) que está conectado a un FPGA mediante SPI de 16 bits. También hay una tarjeta SD que utiliza 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 necesito hacer es escribir los datos de la FPGA en un archivo de la tarjeta SD usando FAT32 y este es el trabajo del microcontrolador. El microcontrolador funciona FatFS que he conseguido que funcione de forma fiable por sí mismo.

Dado que el microcontrolador sólo tiene una pequeña cantidad de RAM, sólo se puede almacenar una pequeña cantidad de datos a la vez. Por lo tanto, el micro tiene que leer un buffer de la FPGA, cambiar el modo SPI a 8 bits, y luego escribir esos datos en el FATFS. Recordemos que para configurar la tarjeta SD para el modo SPI, hay que 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 sólo una vez.

Sin embargo, la realización de transacciones en la FPGA incluso mientras se mantiene el CS alto en la tarjeta SD parece poner la tarjeta SD en un estado extraño tal que necesita pasar por la inicialización de nuevo. Esto, por supuesto, no es deseable, ya que la inicialización puede tardar varios milisegundos, con el fin de escribir sólo 4 kB o así de datos (de nuevo 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 compatibles con SPI, pero ¿cómo se puede solucionar este problema?

0 votos

Debería honrarlo, por lo que sé. ¿Tal vez probar una tarjeta SD diferente?

0 votos

Esta es una gran pregunta. Gracias por plantearla (y responderla).

7voto

Zuofu Puntos 3002

Bien, en realidad lo he resuelto. Debería haber buscado un poco más en Google. Resulta que las tarjetas SD no actúan exactamente como los dispositivos SPI cuando comparten un bus según Cómo utilizar MMC/SDC :

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

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

Probablemente la tarjeta SD y la FPGA estaban tratando de manejar DO y la tarjeta SD perdió, por lo que se reinició. El envío de un byte extra parece haberlo solucionado.

0 votos

Esto permite alternar entre la FPGA y la tarjeta, ¿no? ¿También has comprobado que puedes interrumpir durante la transferencia de datos y reanudarla? Por lo que dice elm-chan, parece que eso no es posible, pero me interesaría saber si lo has confirmado o desmentido.

1 votos

Sí, funciona como se espera para alternar entre FPGA y SD, pero no se puede interrumpir la transferencia entre las llamadas a FatFS. Al menos yo no he conseguido que eso funcione. Eso significa que no puedes (por ejemplo) responder a una interrupción durante la escritura de un archivo y leer de un sensor usando el bus SPI compartido.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X