Como o V-USB pode estragar o SPI embutido de um ATmega328p?

Estou trabalhando em um projeto V-USB que aparece como um teclado usando um ATmega328p. A parte USB está funcionando muito bem (não é meu primeiro projeto V-USB), mas depois que eu inicio a pilha V-USB usbInit(), todas as chamadas para a biblioteca de cartões SD falham. Se eu chamo as mesmas funções antes usbInit(), tudo funciona perfeitamente.

Eu uso um clone do Arduino chamado Diavolino, mas sem a estrutura do Arduino / fiação. Eu tenho o USB conectado às E / S digitais 2 e 3 e o cartão SD para 10-13 (linhas SPI embutidas).

Examinei a biblioteca de cartões SD e não encontrei nenhum sinal usando interrupções ou registros que não sejam SPxx. Também pensei grepno código V-USB, mas ele nem sequer toca nos SPxxregistros.

O primeiro sinal do problema foi quando o dispositivo foi desconectado quando deveria acessar o cartão SD. Depois, coloquei usbPoll()e wdt_reset()liguei em todos os loops de manipulação de cartão SD e constatei que, em caso de gravação, o cartão aguarda eternamente o reconhecimento do cartão depois de enviar os dois últimos bytes (CRC-16).

A biblioteca de cartões SD que utilizo é sd_rawde Roland Riegel.

— dnet
fonte

Entendo que o V-USB consome muita CPU e provavelmente está introduzindo atrasos inaceitáveis nas rotinas SPI. Normalmente, as operações SPI não são sensíveis ao tempo, mas as operações de gravação e exclusão no SPI FLASH definitivamente são.

— Dave Tweed

O problema é que mesmo as operações de leitura não funcionavam na maioria das vezes e, como eu li, as comunicações SPI são feitas de forma independente assim que os registros de dados e controle são definidos pelo código em execução.

— dnet

@DaveTweed - tempo sensível em termos de ter que esperar pelo cartão sim, mas em termos de não ser capaz de manter o cartão esperando pelo seu programa?

— Chris Stratton

Provavelmente você está esperando por algo que não pode acontecer ou não pode ser detectado; por exemplo, o pino de E / S pode ter sido reconfigurado e não ser mais uma entrada ou dados / relógios falsos podem ter sido enviados para o cartão, colocando-o em um estado indesejado. Verifique também se o mecanismo pelo qual a biblioteca SD realiza os atrasos necessários não foi quebrado ou acelerado.

— 22812 Chris Stratton

Você também pode ter problemas de ruído ou de fonte de alimentação. Verifique seus trilhos com um escopo e verifique as linhas SD com um analisador lógico para ver o que está acontecendo.

— Jim Paris

Tive um problema assim com o USART e resolvi-o alterando as configurações do cão de guarda. Como você sabe, o V-USB usa um cão de guarda e, se você dedicar mais tempo a uma operação, o cão de guarda é ativado. Tente desativar o cão de guarda e, se vir tudo bem, você pode alterar a hora do cão de guarda ou dividir o código que interfere (os códigos do cartão SD no seu caso) em partes menores e "Reiniciar" o cão de guarda entre eles. Mas não se esqueça de reativar seu cão de guarda após a depuração, pois não é recomendável usar o V-USB sem isso.

— Agosto
fonte

Observe que a pergunta menciona ter chamadas wdt_reset () inseridas no código SD; embora, é claro, seja possível que isso não tenha sido feito em todos os lugares.

— Chris Stratton

Sim, mas vale a pena tentar o código desativando o cão de guarda. Às vezes, especialmente quando os dados retornando é processada em uma rotina de interrupção, o código fica preso lá e o cão de guarda é ativado antes de ser reposto

— agosto