Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Dekoder MP3 i karta SD z AVRa?

robiw 16 Lis 2013 16:22 5703 42
  • #1 16 Lis 2013 16:22
    robiw
    Poziom 26  

    Witam Kolegów,
    Od jakiegoś czasu próbuję uruchomić prosty odtwarzacz MP3 oparty o dekoder STA013 oraz kartę SD. Dekoder ten skonfigurowany został tak by na swoim wyprowadzeniu DATA_REQ wystawiał stan niski, gdy jego bufor wewnętrzny jest w stanie przyjmować dane. AVR odczytuje dane z karty SD do potrójnego bufora (z uwagi na brak DMA) i w procedurze INT0 wysyła te dane do dekodera MP3 korzystając z programowej magistrali SPI (prędkość w granicach 1.5MHz). Sprzętowy SPI użyty został do obsługi karty SD przy użyciu PetitFS.

    Globalne, ważniejsze zmienne:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Pętla główna:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    ISR INT0:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Niby wszystko wydaje się być OK a jednak to nie działa :-(. Z dostępnych w sieci przykładów wiem, że dekoder średnio co 26ms gotowy jest na przyjęcie od 1 do 2kB danych a załadowanie jednej części bufora danych (1024 bajty) zajmuje ok.12ms przy wykorzystaniu PetitFS (zmierzone timerem sprzętowym) a jednak układ nie działa. Zwykle zaczyna dekodować, lecz pojawiają się jakieś trzaski a nie oczekiwany dźwięk i zaraz przestaje zgłaszać "chęć" odbierania danych. Sam dekoder skonfigurowany według datasheeta a do tego jego konfiguracja porównywana z wieloma dostępnymi w sieci przykładami - wydaje się być OK. Być może nie dostrzegam problemu, który jest ewidentny. Uprzejmie proszę o sugestie. Nie korzystam ze strumieniowego przesyłania danych tylko z takiego potrójnego buforowania, gdyż wymagało by to zmiany biblioteki PetitFS a nie chcę w to wnikać...robiw

    0 29
  • #2 16 Lis 2013 21:15
    Marico
    Poziom 19  

    Może napiszę banały, ale sprawdź:
    1. czy testowy plik mp3 prawidłowo odtwarza się na innym odtwarzaczu bez błędów.
    2. na początek testuj na pliku z małym bitrate (64kbs), być może testujesz na pliku z dużym br i mcu nie wyrabia się odpowiednio szybko wypełniać bufor dekodera i w efekcie dekoder się poddaje. NIe znam tego dekodera ale VSy przy zbyt wolnym uzupełnianiu bufora po prostu czekają na dane, efektem ubocznym są w takich przypadkach to po prostu pauzy w odtwarzaniu.

    0
  • #3 16 Lis 2013 21:33
    robiw
    Poziom 26  

    Tak, sprawdzałem na kompie - zresztą na kompie go utworzyłem. Mało tego, "wyrzucałem" na wyświetlacz pierwsze kilkaset bajtów tego pliku - odczyt z karty jest OK. Plik ma bitrate 32kbps. Problem w tym, że dekoder po chwili nie ściąga już wyprowadzenia DATA_REQ do zera choć powinien nawet wtedy gdy dostaje dane niezwiązane z danymi MP3 aż wypełni swój bufor. Wszystkie dane konfiguracyjne trafiają do niego po I2C - także sprawdziłem...próbowałem różnych plików konfiguracyjnych dostępnych w sieci tzw. patch file - niezbędne do STA013. DAC: CS4344 sterowany z dekodera po I2S...robiw

    0
  • #4 16 Lis 2013 23:26
    MarcinBukat
    Poziom 10  

    Bardzo głupie pytanie, ale jakiego AVRa używasz? Ma on wystarczająco ramu na 3kB bufor + inne?

    0
  • #5 16 Lis 2013 23:31
    robiw
    Poziom 26  

    No proszę ;-). 644A...robiw

    0
  • #6 18 Lis 2013 09:59
    Tytus Kosiarski
    Poziom 14  

    Witam

    Masz podłączone SCR_INT (pin 8 STA013) do Vdd? Sprawdź woltomierzem bezpośrednio na tym pinie. Jest to wymagane, by dekoder pracował w trybie Multimedia Mode i sam sterował pinem DATA_REQ (datasheet CD00001694.pdf, str. 9)

    Acha, jak masz zrobione programowe SPI? Procedura w obsłudze INT0:

    Code:
    SPIsendByte(byteToSend);  //Wysyłamy bieżący bajt danych poprzez programowy interfejs SPI


    KT

    0
  • #7 18 Lis 2013 10:54
    robiw
    Poziom 26  

    SRC_INT, BITEN i TESTEN do Vdd, SCANEN do masy.

    Programowe SPI:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #8 18 Lis 2013 11:38
    Tytus Kosiarski
    Poziom 14  

    U mnie zbocze opadające na SCK powoduje zatrzaskiwanie danych na MOSI dla STA013 przez ATmega, natomiast podczas trwania poziomu wysokiego na SCK jest ustalana nowa dana na MOSI przez ATmega lub brak jest transmisji na SPI. Twój komentarz i RESET_SCK na początku procedury SPIsendByte nie są jednoznaczne.

    Ponadto w pliku konfiguracyjnym do rejestru 0x0D STA013 u mnie przynajmniej jest wpisywana wartość 0x04, co odpowiada sytuacji jak wyżej (str. 11 i 30 pdf-a STA013). Sprawdź to.

    Procedura konfigu sprzętowego (u mnie) SPI:


    Code:
    SPI_INIT:      ; Enable SPI, Master,ustalanie danych na MOSI przy narastającym
    
                ;zboczu SCK,odczyt danych z MOSI przy opadającym zboczu SCK
          ldi    r16,(1<<SPE)|(0<<DORD)|(1<<MSTR)|(1<<CPOL)|(0<<CPHA)|(0<<SPR1)|(0<<SPR0)
          out    SPCR,r16
          ldi      r16,(1<<SPI2X)      ;set clock rate fck/2 (SPI2X=H,SPR1=L,SPR0=L)
          out      SPSR,r16
          ret


    I jeszcze zobacz to, co wpisujesz do STA013 podczas konfigu:

    Code:
          .dw      0x1401      ;MUTE on
    
          .dw     0x0700      ;Default is zero, not in Table 10, but is zero in ConfigPLL v1.0
          .dw     0x060C      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x0B03      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x5401      ;256X oversample, 32 bit words (allows 24 bit output)
          .dw     0x5523      ;I2S format for CS4334
          .dw     0x5204      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x5100      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x6555      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x6455      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x5010      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x610F      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw     0x05A1      ;14,745 MHz Clock, 256 Oversample, Table 10 in Datasheet
          .dw      0x0D04
          .dw     0x1804      ;Enable data request pin
          .dw      0x0C01
          .dw      0x7201      ;Start running STA013
          .dw      0x1400      ;MUTE Off
          .dw      0x1301      ;Start playing MP3


    Jest to fragment mojego pliku konfiguracyjnego dla kwarcu 14,745MHz. Starszy bajt jest adresem rejestru w STA013, młodszy bajt jest daną wpisywaną do niego.

    0
  • #9 18 Lis 2013 11:47
    robiw
    Poziom 26  

    Ale przecież konfiguracja SPI procesora (jak podałes powyżej) nie ma nic wspólnego z interfejsem I2S STA013, po którym to dane wysyła do DAC - ustawienia rejestru 0x0D...robiw

    0
  • #11 18 Lis 2013 12:12
    robiw
    Poziom 26  

    OK. Rozumiem już teraz. Jak wiesz, rejestr 0x0D ustala konfigurację interfejsu I2S STA013, więc nie ma nic do rzeczy, jeśli chodzi o SPI wejściowe natomiast masz tutaj rację: u mnie stanem aktywnym SCK magistrali SPI czyli takim, dla którego dane mają byc już ustalone jest logiczna 1, czyli najpierw (przy SCK=0) ustalam wartość na pinie MOSI (programowe) a później wysyłam zbocze narastające na SCK po czym powracam do stanu 0 na SCK. Z Twojego opisu wynika, że na odwrót niż powinno być. Racja?

    Dodano po 4 [minuty]:

    Chociaz nie, to nic nie da jak zmienię polaryzację bo ten rejestr 0x0D jednak konfiguruje wejściowe SPI a nie wyjściowe I2S:

    U mnie jest:

    //Ustawienia polaryzacji sygnału zegarowego SCRK wejsciowego interfejsu danych SPI
    STA013writeRegister(SCKL_POL_REG, SAMPLED_ON_RISING_EDGE);

    Czyli: rejestr 0x0D, wartość 0x00 czyli moje sendSPI działa prawidłowo. U Ciebie jest 0x0D, 0x04 stąd wymusiłeś odwrtoną polaryzację SPI...robiw

    Dodano po 11 [minuty]:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    0
  • #12 18 Lis 2013 12:31
    Tytus Kosiarski
    Poziom 14  

    A spróbuj odczytać przez I2C zawartość tego rejestru 0x0D(SCKL_POL)... Żeby mieć pewność, co do prawidłowej komunikacji mikrokontrolera z STA przez I2C, to może odczytaj też zawartość rejestru 0x01 (IDENT) - powinno być 0xAC. Po co to wszystko? - by mieć pewność, że prawidłowo jest wgrywany plik konfiguracyjny do STA013 przez I2C

    Dodano po 17 [minuty]:

    Jeszcze jedno mi przyszło na myśl, jak dołączyłeś definicje programowego SPI: jak długo trwa u Ciebie poziom wysoki na SCK_TICK? Z tego co zauważyłem, wydaje mi się, że są to tylko dodatnie szpilki na tle zera logicznego, ale mogę się mylić...

    0
  • #13 18 Lis 2013 12:43
    robiw
    Poziom 26  

    Odczytam zawartość rejestru 0x0D i zobaczymy. U mnie powinna to być wartość 0x00. Rejestr identyfikatora odczytywałem i otrzymuje wartość 0xAC jak należy się spodziewać. Co do programowego SPI masz rację, to są tylko "szpilki" dodatnie jednak i tak o dłuższym czasie niż minimalny 10ns (ATmega taktowana 16MHz). Zresztą wstawialem opóźnienie 1us między wyzerowaniem a ustawieniem SCK. Bez zmian. Co do plików konfiguracyjnych to widziałem w sieci różne ich wersje i tak do końca nie wiadomo skąd różnice poza faktem, iż mogły być dla różnych kwarców. Niemniej różnice pomiędzy nimi nie wynikały tylko z ustawień rejestrów odpowiedzialnych za ustawienia PLL itp. Generalnie dziwny temat z ta firma ST bo nawet nie piszą nigdzie po co ten plik... R

    0
  • #14 18 Lis 2013 12:56
    Tytus Kosiarski
    Poziom 14  

    Po to, że ten scalak ma jakieś wady w sofcie, i STMicro ratował się wypuszczając taki plik konfiguracyjny, po to, by w ogóle ten scalak ruszył i nie trzeba było go wycofywać z rynku (gdzieś tak wyczytałem). Następcą jest STA015 i podobno obywa się on już bez tego pliku. Zwróć uwagę, że w tym pliku są wpisy danych do rejestrów w ogóle nie wyszczególnionych w datasheet. Zresztą w google wpisz "sta013 patch" i już jest pierwszy odnośnik...

    0
  • #15 18 Lis 2013 13:32
    robiw
    Poziom 26  

    Tak. To wiem. Tyle, że można spotkać różne pliki. R

    0
  • #16 18 Lis 2013 13:48
    Tytus Kosiarski
    Poziom 14  

    Jeszcze to mi przychodzi na myśl: spróbuj wgrać jakąś krótką z małym bitrate mp3 do Flash, podłącz dekoder przez sprzętowe SPI do Atmegi (odłącz kartę SD) i zobaczymy wtedy... Poza tym nadal czekam na zawartość rejestru 0x0D ;)

    0
  • #17 18 Lis 2013 17:08
    robiw
    Poziom 26  

    Ten plik, który mam na karcie ma bitrate 32kbps. Jako, że układ mam już zmontowany to nie zmienię połączeń, jednak mogę jakoś przekopnwertowac kawałek pliku do Flasha i odczytywac w pętli i przesyła do STA013. Sygnature sprawdze jak bede w domu - jutro...r

    Dodano po 3 [godziny] 3 [minuty]:

    Rozumiem, że poniższy zapis:

    Cytat:
    If SCKL_POL is set to 0x00, the data (SDI) are sent with the falling edge of SCKR and sampled on the rising edge.


    odpowiada mojej procedurze programowego SPI, cho dziwna jest dla mnie częśc "(SDI) are sent with the falling edge of SCKR". Jak to sent skoro to jest wejście SPI. Rozumiem, że są przez STA013 próbkowane przy zboczu rosnącym, czyli jak napisałęm wcześniej, najpierw przy niskim stanie na SCK należy ustawi odpowiednią wartośc ma MOSI a później wygenerowaz roznące zbocze na SCK...tylko co to ma niby znaczyc "sent" w tym znaczeniu...robiw

    0
  • #18 19 Lis 2013 10:29
    robiw
    Poziom 26  

    Rejestry:
    0x01 -> 0xAC
    0x0D -> 0x00

    czyli tak jak skonfigurowano a STA013 zaczyna dekodować, słychać jakieś pojedyncze trzaski i przestaje, choć przecież nawet jakby mu wysyłać dokument Worda to powinien cały czas "prosić" o więcej a nie przestawać dekodować...brrr...robiw

    0
  • #19 19 Lis 2013 18:39
    Tytus Kosiarski
    Poziom 14  

    OK, dzięki, komunikacja z STA przez I2C wydaje się być poprawna.

    Odnośnie cytatu pasowało by moim zdaniem, gdyby tam było "set" zamiast "sent". Niemniej nowy bit danej ma wyjściu MOSI powinien być ustawiany przy opadającym zboczu SCKR, przy niskim poziomie na SCKR powinien być już stabilny stan na MOSI, ten stan zatrzaskiwany jest przez dekoder narastającym zboczem na SCKR, potem podczas trwania wysokiego poziomu na SCKR również powinien być stabilny stan na MOSI i dopiero podczas wystąpienia kolejnego zbocza opadającego na SCKR może znów się zmienić poziom logiczny na MOSI. Stąd moja propozycja użycia sprzętowego SPI do prób.

    0
  • #20 19 Lis 2013 19:18
    robiw
    Poziom 26  

    Tym niemniej, nawet jeśli założyć, że SPI programowe źle działa i STA dostaje jakieś inne dane, nie powinien przestawać żądać danych...robiw

    Dodano po 3 [minuty]:

    Jutro zrobię próbe z plikiem z Flasha, wrzuciłem tam 32kb plik z bitrate 32kbps. Potem spróbuję zmienić polaryzację SPI, choć moim zdaniem nie w tym tkwi problem :-(. Zaczynam sie zastanawiać czy STA jest sprawny lub Patch jest poprawny... robiw

    0
  • #21 20 Lis 2013 09:24
    robiw
    Poziom 26  

    Piosenka z Flasha sprawdzana, polaryzacja zmieniana. Bez zmian. Nadal nie działa. Nie korzystałem z INT tylko w pętli sprawdzałem, kiedy DATA_REQ==0 i wtedy wysyłałem po soft SPI dane do STA013 z tablicy w pamięci Flash. Trzaski przez ułamek sekundy (dokładnie układ odbierał 4389 bajtów) i koniec, znaczy się DATA_REQ==1 i tak zostawał już permanentnie. Brak sił...robiw

    0
  • #22 20 Lis 2013 14:41
    Tytus Kosiarski
    Poziom 14  

    Widzę, że muszę opisać pokrótce proces dekodowania strumienia mp3:
    Każde MP3 zbudowane jest z ramek poprzedzonych 4-bajtowymi nagłówkami. W tym nagłówku zapisane są różne informacje potrzebne do dekodowania, m.in. fsample, bitrate i inne (do znalezienia w Sieci). Dekoder przed rozpoczęciem dekodowania każdej skompresowanej próbki dźwięku z każdej pojedynczej ramki (to jest kilka ms dźwięku) musi poprawnie odczytać informacje z każdego nagłówka poprzedzającego dekodowaną ramkę, chociażby po to, by móc prawidłowo skonfigurować swoje wewnętrzne PLL. Potem, stosownie do odczytanych informacji z nagłówka, następuje dekodowanie tej ramki i wysłanie zdekodowanego strumienia PCM do DAC, co tochę czasu zajmuje. Wtedy DATA_REQ będzie == Low. Gdy już dekoder się z tym upora, ustawia DATA_REQ == High, oczekując nowej, poprawnej ramki mp3. Gdy chociażby jeden bit (nawet) w tym strumieniu przesyłanym przez SPI będzie przekłamany, to zależnie od jego miejsca dekoder może wypuścić na PCM jakieś śmieci (słyszalne jako trzask) lub W CAŁOŚCI odrzucić odebraną ramkę jako błędną i niczego nie wystawiać na PCM oraz utrzymać DATA_REQ == High, bo czeka na kolejną porcję danych.
    Cytat z datasheet:

    Cytat:
    When STA013 receives the input clock, as described
    in Section 2.1, and a valid layer III input
    bit stream, the internal PLL locks, providing to the
    DSP Core the master clock (DCLK), and to the
    Audio Output Interface the nominal frequencies of
    the incoming compressed bit stream. The STA013
    PLL block diagram is described in Figure 7.


    A "valid layer III input bit stream" to poprawnie przesyłane (bez przekłamań) przez SPI bit po bicie kolejne bajty pliku mp3.

    Podsumowując, skoro przez ułamek sekundy są trzaski, a potem (a może nawet w trakcie) DATA_REQ == High nonstop, to według mnie dekoder próbuje coś robić, ale nie rozpoznaje nadchodzącego strumienia danych przez Twoje soft SPI jako "valid layer III input bit stream"czyli poprawne ramki mp3, odrzuca je, i robiąc tak, leci aż do końca pliku, co wówczas zajmuje ułamek sekundy. Stąd upieram się, żebyś puścił dane do dekodera przez sprzętowe, poprawnie skonfigurowane SPI. Zresztą interfejs SPI może być dzielony między dekoder i kartę SD (do wyboru tego, czy tego na SPI służą sygnały Chip Select). Dla dekodera sygnałem CS będzie wówczas pin BIT_EN.

    0
  • #23 20 Lis 2013 15:23
    robiw
    Poziom 26  

    Hej,
    Ależ ja to wiem co przytoczyłeś choć dzięki za dogłębna analizę. Jednak pomyśl. Dekoder odrzuca wszystkie dane, których nie rozpoznaje jako dane mp3, w tym nagłówki itp itd, więc jeśli otrzymuje dane dla niego nieważne, np. zakładając złą polaryzacje itp, czyli "sieczkę" to przepuszcza je transparentnie przez "siebie" tak jakby nic nie dostał - utrzymując cały czas stan niski na DATA_REQ (tak go skonfigurowałem) bo nie ma nic do przetworzenia i wysłania na I2S.... a on tymczasem otrzymuje jakąś tam porcję danych, które wysyła jako trzaski (więc to nie są śmieci bo śmieci w ogóle by nie dekodował) i przestaje cokolwiek robić. Kawałek z flasha zamknięty jest w pętli, więc gdyby chciał więcej danych (i ściągnął DATA_REQ do masy czego nie robi) dostał by je od początku - sa zapętlone - 32kb...robiw

    0
  • #24 20 Lis 2013 15:52
    Tytus Kosiarski
    Poziom 14  

    Czyli zmieniałeś polaryzację sygnału DATA_REQ przez rejestr 0x0C? Ja cały czas zakładałem fabryczny konfig tego sygnału... Możesz mi podać zawartość rejestru 0x0C?

    Poza tym dekoder nie "przepuszcza je transparentnie przez siebie" błędnych danych, tylko je ignoruje, oczekując na nową porcję poprawnych danych i w domyślnej konfiguracji DATA_REQ (domyślna po resecie zawartość rejestru 0x0C) trzymając tą linię na High.

    0
  • #25 20 Lis 2013 17:09
    robiw
    Poziom 26  

    Tak, wiem tyle, że ja, jak zresztą już pisałem gdzieś na wstępie ustawiam wartość rejestru 0x0C na 0x05:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Nie sprawdzałem tego, ale zakładam, że skoro inny (0x0D) który sprawdzałem na Twoją prośbę ma taką wartość jaką ustawiam to ten także. Zresztą to DATA_REQ na chwilę jest ściągane do 0. Także nie tu upatrywałbym problemów. W sumie to nie wiem już gdzie :-(. Testowałem różne napotkane w sieci Patch file, gdyż są między nimi różnice. Wszystkie pochodziły z działających i dostępnych w sieci listingów. Nic, żadnego postępu. W weekend sprawdzę sprzętowe SPI choć IMHO nie tu tkwi problem - część z urządzeń w sieci korzystała z programowego SPI, zresztą to bardzo prosty interfejs...robiw

    0
  • #26 28 Lis 2013 10:36
    robiw
    Poziom 26  

    Sprawdziłem jeszcze jeden, dostępny w sieci plik konfiguracyjny, zmieniłem programowe SPI na sprzętowe (bez inwersji), plik wczytywałem z flasha - 32kbps...niestety bez zmian - pomysłów brak...robiw

    0
  • #27 28 Lis 2013 12:35
    Tytus Kosiarski
    Poziom 14  

    OK, dzięki za info.
    Jaki masz kwarc przy tym STA?

    Spróbuj też dać plik z większym bitrate (64 lub 128kbps) i puścić go z Flasha, jak się da. Ja spróbuję w ten weekend uruchomić swoją mptrójkę na STA i zdjąć jakieś oscylogramy.

    0
  • #28 28 Lis 2013 12:48
    robiw
    Poziom 26  

    Myślę, że albo problem jest jakiś banalny i nie mogę go zauważyć albo scalak jest uszkodzony. Nie ma powodu by "rezygnował" ze ściągania wyprowadzenia DATA_REQ do zera... Kwarc mam 14.4756 MHz. Próbowałem kilka sztuk. Inny plik jutro spróbuje. Nowy scalak tak czy inaczej w drodze. Oczywiście standardowo żadnego wsparcia od ST. Okropna firma...robiw

    0
  • #29 30 Lis 2013 16:55
    Tytus Kosiarski
    Poziom 14  

    Oscylogramy:
    1. DATA_REQ(na dole)_and_SCKR_5ms_dz
    Dekoder MP3 i karta SD z AVRa?
    2. SDI_SCKR(na dole)_1us_dz
    Dekoder MP3 i karta SD z AVRa?
    3. SCKR_5us_dz
    Dekoder MP3 i karta SD z AVRa?
    4. SCKR_1us_dz
    Dekoder MP3 i karta SD z AVRa?

    I teraz zonk, bo na pierszym oscylogramie jest, że transmisja po SPI przebiega przy DATA_REQ = Low, a wydawało mi się, że ma przebiegać przy DATA_REQ = High - ustawiłem zawartość rejestru 0x0C na domyślną wartość 0x01 w pliku konfiguracyjnym. Oscylogramy zdjąłem przy odtwarzanym pliku 192kbps.

    0
  • #30 01 Gru 2013 12:08
    robiw
    Poziom 26  

    Hmm, ten scalak zaczyna mnie "dobijać" bo co teraz z tego wynika w odniesieniu do dokumentacji, kompletny mętlik :-(. Przy ustawieniu rejestru 0x0C na 0x01 żądanie danych zgłasza stanem wysokim, a nie niskim jak na Twoich oscylogramach. Pomyślałbym, że to błąd w dokumentacji, bo u ST to norma (czasami celowa), lecz wiele listingów opierało się na niej i urządzenia ponoć działały. Widzę, że dość szybko go taktujesz, około 2.5MHz i że przy bitrate 192kbps dość często (co 15ms), ale dość krótko (bo 10ms) przebiega transmisja po SPI...robiw

    Dodano po 5 [godziny] 34 [minuty]:

    Ale zaraz, zaraz. Skoro w założeniach tak skonfigurowałeś STA013, że żądanie danych zgłasza stanem wysokim to program Twojej aplikacji musiał zostać tak napisany, iż reaguje na zbocze rosnące lub stan wysoki na wyprowadzeniu DATA_REQ, w związku z czym nie ma prawa wysyłać danych do dekodera w trakcie stanu niskiego. W takim razie jest inaczej niż pisałes, jeśli chodzi o konfiguracje lub sama aplikację. Możesz to sprawdzić bo coś tu nie gra... robiw

    0