Um cartão SD no modo SPI respeita a seleção de chips / seleção de escravos? Parece estar sendo redefinido no meu aplicativo

Eu tenho um aplicativo em que tenho um microcontrolador (NXP LPC1343 ) conectado a um FPGA via SPI de 16 bits. Há também um cartão SD que usa a mesma porta SPI (MISO / MOSI), mas com um pino CS / SS diferente (ambos estão ativos baixos, conforme a especificação SPI). Uma das coisas que preciso fazer é gravar dados do FPGA em um arquivo no cartão SD usando o FAT32 , e esse é o trabalho do microcontrolador. O microcontrolador está executando o FatFS , que eu trabalhei de maneira confiável por si só.

Como o microcontrolador possui apenas uma pequena quantidade de RAM, apenas uma pequena quantidade de dados pode ser armazenada em buffer de uma só vez. Portanto, o micro precisa ler um buffer do FPGA, alterar o modo SPI para 8 bits e gravar esses dados no FATFS. Lembre-se de que, para configurar o cartão SD para o modo SPI, um comando deve ser enviado enquanto o barramento SPI estiver em execução a 400 kHz e uma certa quantidade de espera deve ocorrer. Portanto, eu gostaria de ter que executar a inicialização apenas uma vez.

No entanto, a realização de transações no FPGA, mesmo mantendo CS alto no cartão SD, parece colocar o cartão SD em um estado estranho, de modo que ele precisa passar pela inicialização novamente. É claro que isso é indesejável, pois a inicialização pode demorar vários milissegundos, para gravar apenas 4 kB ou mais de dados (novamente limitado pela pequena capacidade de RAM do meu micro). Como preciso escrever vários megabytes o mais rápido possível, isso reduz o desempenho de cerca de 500 kB / s para menos de 100 kB / s.

Estou ciente de que os cartões SD não são tecnicamente totalmente compatíveis com SPI, mas como esse problema pode ser corrigido?

fpga spi sd nxp

— Zuofu
fonte

Deveria honrá-lo, tanto quanto eu sei. Talvez tente um cartão SD diferente?

— Marko

Esta é uma grande pergunta. Obrigado por perguntar (e responder).

— markrages

Ok, eu descobri isso na verdade. Eu deveria ter pesquisado um pouco mais profundamente. Acontece que os cartões SD não agem exatamente como dispositivos SPI ao compartilhar um barramento, de acordo com Como usar o MMC / SDC :

No barramento SPI, cada dispositivo escravo é selecionado com sinais CS separados e vários dispositivos podem ser conectados a um barramento SPI. O dispositivo escravo SPI genérico aciona / libera seu sinal DO por sinal CS de forma assíncrona para compartilhar um barramento SPI.

No entanto, o MMC / SDC aciona / libera o sinal DO em sincronização com o SCLK. Isso significa que existe a possibilidade de conflito de barramento com o MMC / SDC e quaisquer outros escravos SPI conectados a um barramento SPI. A imagem à direita mostra o tempo de acionamento / liberação do MMC / SDC (o sinal DO é puxado para 1/2 V _cc para ver o estado do barramento). Portanto, para fazer com que o MMC / SDC libere o sinal DO, o dispositivo mestre deve enviar um byte após a desativação do sinal CS.

O cartão SD e o FPGA provavelmente estavam tentando conduzir o DO e o cartão SD foram perdidos, por isso foi redefinido. Enviar um byte extra parece ter corrigido.

— Zuofu
fonte

Isso permite que você alterne entre o FPGA e o cartão, certo? Você também achou que poderia interromper durante a transferência de dados e continuar? Pelo que diz elm-chan, parece que isso não é possível, mas eu estaria interessado em saber se você o confirmou ou não.

— krs013

Sim, funciona como esperado para alternar entre FPGA e SD, mas você não pode interromper a transferência entre as chamadas para o FatFS. Pelo menos eu não era capaz de fazer isso funcionar. Isso significa que você não pode (por exemplo) responder a uma interrupção durante uma gravação e leitura de arquivo de um sensor usando o barramento SPI compartilhado.

— Zuofu