Jak V-USB może zepsuć wbudowany SPI ATmega328p?

Pracuję nad projektem V-USB, który pokazuje się jako klawiatura za pomocą ATmega328p. Część USB działa świetnie (to nie jest mój pierwszy projekt V-USB), ale po uruchomieniu stosu V-USB usbInit()wszystkie wywołania biblioteki kart SD kończą się niepowodzeniem. Jeśli wcześniej wywołam te same funkcje usbInit(), wszystko działa idealnie.

Używam klonu Arduino o nazwie Diavolino, ale bez frameworka Arduino / okablowania. Mam USB podłączony do cyfrowych I / O 2 i 3, a kartę SD do 10-13 (wbudowane linie SPI).

Przejrzałem bibliotekę kart SD i nie znalazłem żadnych śladów, używając żadnych przerwań lub rejestrów innych niż SPxx. Myślałem też o grepkodzie V-USB, ale nawet nie dotyka SPxxrejestrów.

Pierwszą oznaką problemu było odłączenie urządzenia, gdy miało ono uzyskać dostęp do karty SD. Następnie wstawiłem usbPoll()i wdt_reset()wywołałem wszystkie pętle obsługi kart SD i stwierdziłem, że w przypadku zapisu karta czeka na potwierdzenie z karty po wysłaniu dwóch ostatnich bajtów (CRC-16).

sd_rawUżywana przeze mnie biblioteka kart SD to Roland Riegel.

— dnet
źródło

Rozumiem, że V-USB wymaga dużej mocy obliczeniowej procesora i prawdopodobnie wprowadza niedopuszczalne opóźnienia w procedurach SPI. Zwykle operacje SPI nie są wrażliwe na czas, ale operacje zapisu i kasowania na SPI FLASH są zdecydowanie takie.

— Dave Tweed

Problem polega na tym, że nawet operacje odczytu nie działały przez większość czasu, a jak czytałem, komunikatory SPI są wykonywane niezależnie, jak tylko rejestry danych i kontroli zostaną ustawione przez działający kod.

— dnet

@DaveTweed - wrażliwy na czas pod względem konieczności oczekiwania na kartę tak, ale pod względem niemożności utrzymania karty w oczekiwaniu na program?

— Chris Stratton,

Prawdopodobnie czekasz na coś, co albo nie może się zdarzyć, albo nie może zostać wykryte; na przykład pin we / wy mógł zostać ponownie skonfigurowany i nie był już wejściem, lub fałszywe dane / zegary mogły zostać wysłane na kartę, powodując jej niepożądany stan. Upewnij się również, że mechanizm, za pomocą którego biblioteka SD realizuje wymagane opóźnienia, nie został uszkodzony ani przyspieszony.

— Chris Stratton

Być może masz również problemy z hałasem lub zasilaniem. Sprawdź swoje szyny za pomocą lunety i sprawdź linie SD za pomocą analizatora logicznego, aby zobaczyć, co się dzieje.

— Jim Paris,

Miałem taki problem z USART i rozwiązałem go, zmieniając ustawienia obserwatora. Jak wiadomo, V-USB używa psa stróżującego i jeśli poświęcisz więcej czasu na jedną operację, pies stróżujący zostanie aktywowany. Spróbuj wyłączyć psa stróżującego, a jeśli zobaczysz, że wszystko idzie dobrze, możesz zmienić czas psa stróżującego lub podzielić kod zakłócający (kody kart SD w twoim przypadku) na mniejsze części i „zresetować” psa stróżującego między nimi. Ale nie zapomnij ponownie aktywować swojego psa stróżującego po debugowaniu, ponieważ nie zaleca się używania V-USB bez tego.

— Sierpnia
źródło

Zauważ, że pytanie wspomina o tym, że wywołania wdt_reset () zostały wstawione do kodu SD; choć oczywiście jest możliwe, że nie wszędzie tak się dzieje.

— Chris Stratton,

Tak, ale naprawdę warto wypróbować kod z wyłączeniem psa stróżującego. Czasami, zwłaszcza gdy powrocie dane są przetwarzane w przerwania rutyny, kod utknie tam i pies zegarek zostanie aktywowany przed zerują

— sie