Karta SD i VS1011 na jednym SPI (xmega) + odtwarzanie wav

Nie wiem jak ugryźć coś takiego: karta SD i VS1011 na jednym SPI (xmega). Odtwarzane będą pliki zarówno mp3 jaki wav. No i w przypadku wav zastanawiam jak pożenić wszystko czasowo np dla pliku 48kHz 16bit stereo. Odczyt z karty SD jednego sektora 512B trwa zapewne ok 300 - 500 us, a więc na ten czas musiałbym zaprzestać transferu do VS (a przy odczycie tablicy FAT jeszcze raz tyle). Z kolei bufor FIFO VS to 32B czyli raptem 8 probek wav o czasie trwania ok 160us. Czyli co 160us musiałbym wysyłać nową paczkę sampli, ale przecież nie mogę przerwać odczytu z karty. Czy dobrze kombinuję i czy da się to jakoś rozwiązać programowo?

Moderated By dondu:

W przyszłości proszę nie dopisuj swojego tematu do innego, nie związanego bezpośrednio z zadawanymi przez Ciebie pytaniami. Wydzieliłem Twój post do nowego tematu.

Bufor audio fifo VS'a to ok 2kB (datasheet strona 28). 32 to minimalna ilość jaką *na pewno* przyjmie VS zgłaszając DREQ=1. Stąd próbek w buforze jest trochę więcej niż 32, czyli masz trochę więcej czasu niż Ci się wydaje .

Marico wrote:

Bufor audio fifo VS'a to ok 2kB (datasheet strona 28)

A co z buforem na wejściu oznaczonym jako Bitstream FIFO, nie jest to jakieś wąskie gardło?

Akurat pożenienie tego na jednej magistrali SPI ma sens niewielki - sam zauważyłeś, że układy VSxxxx pobierają dane w paczkach po 32 B, w efekcie procesor będzie cały czas sprawdzał DREQ i pojawią się dodatkowe problemy jak np. odczyt karty w międzyczasie. W XMEGA SPI masz sporo, więc nie bardzo jest sens sobie komplikować życie. Przykłady pożenienia SD z VS1xxxx możesz sobie ściągnąć z mojej książki "AVR. Układy peryferyjne" - w darmowych przykładach znajdziesz gotowe kody, tam masz jeszcze dodatkowo na SPI podłączony wyświetlacz, a transfer danych do VS odbywa się całkowicie sprzętowo, bez udziału programu. IMHO warto zobaczyć jak to działa, bo to pokazuje możliwości tych mikrokontrolerów. Tu masz filmik ilustrujący część funkcji przykładu:

tmf - w Twojej książce Układy Peryferyjne na s.517 napisałeś, że jest pewien odcinek czasu na odczyt sektora z SD i tym się zasugerowałem, a ponieważ tymczasowo rozmontowałem VS'a więc nie mam jak sprawdzić transferu większej paczki danych niż wspomniane 32B. Projektuję układ z udziałem wspaniałej XMEGI serii E, gdzie jest tylko jeden SPI (pozostałe 2 USARTy mam już "zapchane") dlatego pokusiłem się o pomysł połączenia linii SD i VS. Czy ostatecznie mój zamysł jest niewykonalny z plikami wav o wysokich częstotliwościach próbkowania?

Mam taki jeden odtwarzacz, gdzie VS ma wspólny SPI z SD. Jest t wersja bez DMA, działa i robi trochę innych rzeczy bez czkawki audio. Nie wiem po co się tak przejmujesz tymi 32 bajtami? Zapychasz bufor aż dreq=0. Pożniej mcu może robić coś innego bo bufor audio VS'a to 512 (2x16 bitowych) sampli. To Ci daje 10ms na przygotowanie kolejnego bufora (no ok, troszkę mniej, bo VS zrobi efekt "slow motion" jeśli bufor za bardzo mu się opróżni). Druga sprawa to po co mcu chcesz męczyć samplami wav 48kHz? Po to jest mp3 aby strumień miał mniejszy bitrate, dąży się do tego by zastąpić sample pcm w wysokim bitrate czymś, co ma mniejszy bitrate a jakość, khem, zbliżoną (strumieniem mpeg). Kiedyś nawet robiłem testy jak mocno można spowolnić feedowanie VSa aby nie doprowadzić do słyszalnych zniekształceń dźwięku. Doprowadzałem do tego, że DREQ żądał 1000-1200 bajtów (@128kbs) zanim się zwracał 0. I nie było żadnych słyszalnych zniekształceń. Czyli masz do dyspozycji grube ms (kilka na pewno) i nie ma co się przejmować 500us odczytem sektora SD.

No właśnie, rozgryzając niegdyś VS przyjąłem na sztywno 32B jako paczkę (wg docu oraz innych podpowiedzi) i nigdy nie testowałem na większych jednorazowych pakietach danych, a że testowałem tylko "powolne" pliki mp3 oraz SD i VS na osobnych magistralach teraz to się zemściło.

Marico wrote:

Druga sprawa to po co mcu chcesz męczyć samplami wav 48kHz? .

Powiedzmy, że lubie wyciągać z procków 7 poty i chcę zrobić coś uniwersalnego, co odtworzy inne pliki, nie tylko mp3, a ponieważ VS zapewnia dekodowanie WAV oraz pracę na SPI wraz innymi układami to nie chcę się w niczym ograniczać.
Jak tylko złożę nowego VS i potestuję wg. podpowiedzi dam znać.

daro2012 wrote:

No właśnie, rozgryzając niegdyś VS przyjąłem na sztywno 32B jako paczkę (wg docu oraz innych podpowiedzi) i nigdy nie testowałem na większych jednorazowych pakietach danych, a że testowałem tylko "powolne" pliki mp3 oraz SD i VS na osobnych magistralach teraz to się zemściło.

Więcej czytać datasheet'ów do układów, które się stosuje (najlepiej od-deski-do-deski) a mniej brać bezkrytycznie to co userzy piszą. Bo inaczej powstają mity i/lub uprzedzenia.

daro2012 - VS ma bufor na zdekodowane dane, w zależności od bitrate zapewnia on pewne podtrzymanie, niemniej niezbyt długie przy samplowaniu 48 kHz (bufor jest na 512 sampli stereo, w VS1003b na 2048 sampli stereo). Aktywny DREQ świadczy tylko o tym, że bez sprawdzenia możesz przesłać co najmniej 32 bajty do dekodera. Po przesłaniu 32 bajtowej paczki powinieneś sprawdzić, czy DREQ się nie zdezaktywował - jeśli tak, to znaczy, że bufor jest pełny. Producent nic nie pisze o długości bufora przed dekoderem, ale nie jest on zbyt wielki - to, że początkowo można przesłać sporo danych wynika zapewne z tego, że dekoder je maksymalnie szybko dekoduje, aż do zapełnienia bufora, który jest przed DACem. Po jego zapełnieniu dekoder oczekuje rzeczywiście paczek po max 32 bajty.
Nie ma większego problemu, żeby zmieścić się z odczytem sektora z karty SD. Problem jest w bibliotece obsługi FAT. Potencjalnie odczyt kolejnej porcji danych może wymagać odczytu co najmniej 2, a nawet 3 sektorów - sektora z właściwymi danymi oraz sektora zawierającego tabelę FAT. Niemniej z problemami przy odczycie mp3 zapewne się nie spotkasz. Potencjalnie gorzej będzie z wav - dla 48 kHz, 16 bit stereo musisz odczytać prawie 200 kB/s, ale przy podwójnym buforowaniu też nie będzie problemu, w XMEGA z łatwością osiągniesz szybkości odczytu na poziomie 700 i więcej kB/s. Gdyby z jakiś powodów to nie działało jak należy zawsze możesz do VSa wczytać sobie swojego plugina, który ci bufor wydłuży - masz do dyspozycji dodatkowo 5,5 kB RAM, zakładając, że kod plugina ci zjamie 100-200 bajtów, to na bufor pozostanie ponad 5 kB.