Come può V-USB rovinare l'SPI integrato di un ATmega328p?

Sto lavorando a un progetto V-USB che si presenta come una tastiera usando un ATmega328p. La parte USB funziona alla grande (non è il mio primo progetto V-USB), ma dopo aver avviato lo stack V-USB con usbInit(), tutte le chiamate alla libreria della scheda SD falliscono. Se prima chiamo le stesse funzioni usbInit(), tutto funziona perfettamente.

Uso un clone di Arduino chiamato Diavolino, ma senza il framework Arduino / cablaggio. Ho l'USB collegato agli I / O digitali 2 e 3 e la scheda SD a 10-13 (linee SPI integrate).

Ho guardato attraverso la libreria della scheda SD e non ho trovato alcun segno di esso usando interruzioni o registri diversi da SPxx. Ho anche greppensato al codice V-USB, ma non ha nemmeno toccato i SPxxregistri.

Il primo segno del problema è stato quando il dispositivo si è disconnesso quando doveva accedere alla scheda SD. Quindi ho inserito usbPoll()e wdt_reset()chiamato tutti i loop di gestione della scheda SD e ho scoperto che in caso di scrittura, la scheda attende per sempre il riconoscimento dalla scheda dopo aver inviato gli ultimi due byte (CRC-16).

La libreria di schede SD che uso è sd_rawdi Roland Riegel.

— dnet
fonte

Comprendo che V-USB richiede molta CPU e probabilmente introduce ritardi inaccettabili nelle routine SPI. Normalmente, le operazioni SPI non sono sensibili alla temporizzazione, ma le operazioni di scrittura e cancellazione su SPI FLASH lo sono sicuramente.

— Dave Tweed

Il problema è che anche le operazioni di lettura non hanno funzionato per la maggior parte del tempo e, come ho letto, le comunicazioni SPI vengono eseguite in modo indipendente non appena i dati e i registri di controllo vengono impostati dal codice in esecuzione.

— dnet,

@DaveTweed - tempo sensibile in termini di dover aspettare la carta sì, ma in termini di non essere in grado di tenere la carta in attesa del tuo programma ??

— Chris Stratton,

Probabilmente stai aspettando qualcosa che non può accadere o non può essere rilevato; ad esempio, il pin I / O potrebbe essere stato riconfigurato e non essere più un input, oppure dati / orologi spuri potrebbero essere stati inviati alla scheda, portandola in uno stato indesiderato. Assicurarsi inoltre che il meccanismo mediante il quale la libreria SD compie i ritardi richiesti non sia stato rotto o accelerato.

— Chris Stratton,

Potresti anche avere problemi di rumore o di alimentazione. Controlla le tue rotaie con un ambito e controlla le linee SD con un analizzatore logico per vedere cosa sta succedendo.

— Jim Paris,

Ho avuto un problema del genere con USART e l'ho risolto modificando le impostazioni del watch dog. Come sapete, V-USB utilizza un cane da guardia e se impiegate più tempo in una sola operazione, il cane da guardia viene attivato. Prova a disattivare il watch dog e se vedi che tutto va bene, puoi cambiare l'ora del watch watch oppure puoi dividere il codice interferente (i codici della scheda SD nel tuo caso) in parti più piccole e "Ripristinare" il watchwatch tra di loro. Ma non dimenticare di riattivare il tuo watch dog dopo il debug in quanto non è consigliabile utilizzare V-USB senza questo.

— agosto
fonte

Si noti che la domanda menziona avere chiamate wdt_reset () inserite nel codice SD; anche se ovviamente è possibile che ciò non sia stato fatto ovunque.

— Chris Stratton,

Sì, ma vale davvero la pena provare il codice disabilitando il watch dog. A volte, soprattutto quando i dati di ritorno è trasformato in una routine di interrupt, il codice non si blocca e il cane da guardia si attiva prima di essere azzerato

— Agosto