¿Cómo puede V-USB arruinar el SPI incorporado de un ATmega328p?

Estoy trabajando en un proyecto V-USB que aparece como un teclado usando un ATmega328p. La parte USB funciona muy bien (no es mi primer proyecto V-USB), pero después de comenzar con la pila V-USB usbInit(), todas las llamadas a la biblioteca de tarjetas SD fallan. Si llamo a las mismas funciones antes usbInit(), todo funciona perfectamente.

Yo uso un clon de Arduino llamado Diavolino, pero sin el marco de Arduino / cableado. Tengo el USB conectado a E / S digital 2 y 3, y la tarjeta SD a 10-13 (líneas SPI incorporadas).

Miré a través de la biblioteca de tarjetas SD y no encontré ninguna señal usando interrupciones o registros que no sean SPxx. También pensé en grepel código V-USB, pero ni siquiera toca los SPxxregistros.

La primera señal del problema fue cuando el dispositivo se desconectó cuando se suponía que debía acceder a la tarjeta SD. Luego puse usbPoll()y llamé wdt_reset()a todos los bucles de manejo de la tarjeta SD, y descubrí que en caso de escritura, la tarjeta espera para siempre el reconocimiento de la tarjeta después de haber enviado los dos últimos bytes (CRC-16).

La biblioteca de tarjetas SD que uso es sd_rawde Roland Riegel.

— dnet
fuente

Tengo entendido que V-USB consume mucha CPU, y probablemente está introduciendo retrasos inaceptables en las rutinas SPI. Normalmente, las operaciones SPI no son sensibles al tiempo, pero las operaciones de escritura y borrado en SPI FLASH definitivamente lo son.

— Dave Tweed

El problema es que incluso las operaciones de lectura no funcionaron la mayor parte del tiempo y, como he leído, las comunicaciones SPI se realizan de forma independiente tan pronto como el código en ejecución establece los datos y los registros de control.

— dnet

@DaveTweed: tiempo limitado en términos de tener que esperar la tarjeta sí, pero en términos de no poder mantener la tarjeta esperando su programa?

— Chris Stratton

Probablemente esté esperando algo que no puede suceder o no puede ser detectado; por ejemplo, el pin de E / S podría haberse reconfigurado y dejar de ser una entrada, o podrían haberse enviado datos / relojes espurios a la tarjeta, lo que lo ha llevado a un estado no deseado. También asegúrese de que el mecanismo por el cual la biblioteca SD logra los retrasos requeridos no se haya roto o acelerado.

— Chris Stratton

También puede tener problemas de ruido o de suministro de energía. Verifique sus rieles con un alcance y verifique las líneas SD con un analizador lógico para ver qué está sucediendo.

— Jim Paris

Tuve un problema como ese con USART y lo resolví cambiando la configuración del perro guardián. Como sabe, V-USB utiliza un perro guardián y si dedica más tiempo a una operación, el perro guardián se activa. Intente desactivar el perro guardián y si ve que todo va bien, puede cambiar la hora del perro guardián o puede dividir el código interferente (los códigos de la tarjeta SD en su caso) en partes más pequeñas y "Restablecer" el perro guardián entre ellos. Pero no olvide volver a activar su perro guardián después de la depuración, ya que no se recomienda usar V-USB sin eso.

— ago
fuente

Tenga en cuenta que la pregunta menciona tener llamadas wdt_reset () insertadas en el código SD; aunque, por supuesto, es posible que esto no se haya hecho en todas partes.

— Chris Stratton

Sí, pero realmente vale la pena probar el código deshabilitando el perro guardián. A veces, especialmente cuando los datos que se devuelven se procesan en una rutina de interrupción, el código se queda atascado allí y el perro guardián se activa antes de reiniciarse

— Ago