Zaloguj
Załóżmy, że mamy zbudować urządzenie, które musi informować obsługę o ważnych zdarzeniach za pomocą komunikatów głosowych. W przypadku, kiedy to urządzenie będzie wykorzystywać komputer, lub moduł embeded z wbudowanym systemem operacyjnym np. Linux, to sprawa jest w miarę prosta. Ale kiedy nie mamy do dyspozycji takich środków, to nawet przy zastosowaniu prostego mikrokontrolera można sobie poradzić dołączając kartę pamięci SD i sprzętowy kodek. Jednak wtedy potrzebne będzie napisanie oprogramowania odtwarzania. Będzie to zadanie tym trudniejsze im „słabszy” to będzie mikrokontroler. Najprostszym i zarazem najtańszym rozwiązaniem może się okazać zastosowanie specjalizowanego modułu. Jednym z takich modułów jest moduł firmy Catalex z układem YX5300.
Moduł z układem YX5300 jest oferowany przez firmę CATALEX. Po krótkim przeszukaniu Internetu nie znalazłem ani strony tej firmy, ani dokumentacji samego układu YX5300. Jest za to dostępny dokument Serial MP3 Player Manual zupełnie wystraczający do zaaplikowania układu.
Za kompletną płytka z układem YX5300 , stereofonicznym gniazdem słuchawkowym Jack 3,5 mm i złączem karty microSD zapłaciłem razem z przesyłką ok. 5 USD. Jest to cena bardzo atrakcyjna zwarzywszy na możliwości układu:
- Możliwość odtwarzania plików skompresowanych w formacie mp3 i nieskompresowanym WAV.
- Wspierane częstotliwości próbkowania: 8 kHz, 11,025 kHz, 12 kHz, 16 kHz, 22,05 kHz, 24 kHz, 32 kHz, 44,1 kHz i 48 kHz.
- Możliwość użycia kart Micro SD (maksymalnie 2 GB) i Micro SDHC (maksymalnie 32 GB). Format plików FAT16 lub FAT32.
- Sterowanie odtwarzaniem z użyciem interfejsu szeregowego UART pracującego z prędkością 9600 b/s.
- Poziomy logiczne na magistrali UART 3,3 V lub 5 V.
- Napięcie zasilania 3,2…5,2 V. Maksymalny pobór prądu 200 mA przy 5 V DC.
- Wbudowany wzmacniacz słuchawkowy.
- Cyfrowa regulacja poziomu sygnału audio w 30 krokach.
Komendy sterujące
Odtwarzacz wymaga, by pliki i katalogi na karcie SD miały nazwy zaczynające się od cyfr. Nazwa katalogu może być wyłącznie liczbą dwucyfrową na przykład 01, 02, 11, 23 itp. Nazwa każdego pliku musi się zaczynać od liczby trzycyfrowej na przykład 001-test1.mp3, 002-test2.mp3. Przykładową strukturę katalogów i nazw plików pokazano na rysunku 1.
Odtwarzacz identyfikuje pliki na dwa sposoby. Komenda odtwarzania może podać numer katalogu i numer pliku w katalogu. Można też identyfikować pliki za pomocą indeksu. Indeks jest nadawany w momencie wgrywania na kartę. Inaczej mówiąc – o kolejności odtwarzania decyduje kolejność nagrania plików na kartę.
Sterowanie odtwarzaczem odbywa się poprzez wysyłanie do niego komend. Komendy mają format pokazany w tabeli 1. Zestaw najważniejszych komend umieszczono w tabeli 2. Jeżeli bajt feedback (rysunek 2) ma wartość 01, to po każdym wysłaniu komendy moduł odpowiada sekwencją 7E, FF, 06, 41, 00, 00, FE, BA EF. Wyzerowany szósty bajt oznacza, że dane zostały odebrane prawidłowo. Oprócz potwierdzenia przesłania komendy mogą być wysyłane przez moduł ramki spontaniczne, niebędące reakcją na komendę, ale na zdarzenie, np. zakończenie odtwarzania konkretnego pliku, lub włożenie/wyjęcie karty SD. Ponadto, można wysyłać komendy pytające o status urządzenia. Te komendy umieszczono w tabeli 3.
Do testowania odtwarzacza użyłem modułu ewaluacyjnego Microchip Microstick II z 16-bitowym mikrokontrolerem PIC24FJ64GB002. Moduł ma wbudowany programator/debugger i jest wspierany przez wtyczkę MCC środowiska MPLAB X IDE. Oprócz modułu mp3 dołączonego do mikrokontrolera przez interfejs UART, użyłem niewielkiego wyświetlacza OLED z interfejsem SPI oraz impulsatora ze stykiem zwieranym przyciśnięciem osi (fotografia 2).
Za pomocą MCC (MPLAB Code Configurator) szybko skonfigurowałem interfejs UART. Obsługa jest oparta na systemie przerwań i ma programowy bufor nadajnika i odbiornika (rysunek 3). MCC na podstawie częstotliwości taktowania mikrokontrolera (8 MHz) i zadanej prędkości transmisji (9600 bps) konfiguruje rejestry liczników odpowiedzialnych za prędkość transmisji interfejsu UART. Przy okazji jest wyliczany błąd. Ten błąd jest nie do uniknięcia, jeśli częstotliwość taktowania nie jest specjalnie dobrana do oczekiwanych prędkości transmisji. Procedurę inicjalizacji UART wygenerowaną przez MCC pokazano na listingu 1.
Testowe odtwarzanie odbywa się w pętli nieskończonej. Na początku pętli jest sprawdzany warunek przyciśnięcia osi i zwarcia styku. Jeżeli oś jest wciśnięta, to program najpierw czeka na jej zwolnienie, a potem analizuje stan dwóch zmiennych: cont i pauza. Zależnie od ich stanu przyciśnięcie powoduje wysłanie komendy Pauza (PauzaP()), lub kontynuuj (ContP()). Obrócenie ośki enkodera powoduje zmianę poziomu sygnału audio ustawianą komendą VolSet z argumentem zmieniającym się od 0 do 32.
Moduł testowany w ten sposób działa bez problemu. Wszystkie funkcje są wykonywane prawidłowo. Po włączeniu potwierdzenia każde wysłanie komendy skutkuje przesłaniem ramki z danymi. W aplikacjach wymagających dużej niezawodności wskazane byłoby włączenie potwierdzenia i przesyłanie bajtów CRC. Dla mniej wymagających zastosowań nie jest to konieczne.
Moduł z portem USB
Zachęcony pozytywnymi doświadczeniami z modułem YX5300 zakupiłem również w bardzo przystępnej cenie kolejny moduł audio potrafiący odtwarzać pliki z karty SD, ale również z pamięci z interfejsem USB, czyli z tak zwanego pendrivea. Tego rodzaju pamięć jest dużo wygodniejsza od karty SD, ponieważ nie wymaga dodatkowego czytnika, a port USB jest w prawie każdym komputerze.
Po dostarczeniu modułu okazało się, że jest problem z dokumentacją. Sprzedawca przesłał mi link do dokumentacji po chińsku… Pomimo wielu poszukiwań nie udało mi się dotrzeć do dokumentacji napisanej po angielsku. Z konieczności musiałem posłużyć się translatorem Google. Tłumaczenie z chińskiego na polski, mówiąc oględnie, nie zachwyciło. Tłumaczenie z chińskiego na angielski było lepsze, ale tylko trochę. Pozostało posiłkować się częściowymi informacjami i uzupełniać je metodą eksperymentów z oprogramowaniem sterującym. Taka metoda okazała się bardzo pracochłonna, ale pozwoliła na zweryfikowanie działania przynajmniej najważniejszych komend pozwalających na uruchomienie odtwarzania.
- MUTE – sprzętowe wyciszenie – aktywne, gdy na wejściu jest poziom wysoki.
- ADKEY – sprzętowe sterowanie funkcjami odtwarzania.
- VCC – napięcie zasilające (3,3…5,4 V).
- RxD – linia danych odbieranych przez moduł.
- TxD – linia danych wysłanych przez moduł.
- GND – masa.
Poza złączem sterującym można podłączać słuchawki stereofoniczne do standardowego złącza Jack 3,5 mm lub głośnik do dwóch wyprowadzeń: „SP–” i „SP+”.
Przed opisem interfejsu sterującego warto wspomnieć, że moduł ma wbudowaną możliwość sterowania podstawowymi funkcjami poprzez dołączenie 8 styków zwiernych do specjalnego wejścia ADKEY tak jak to zostało pokazane na rysunku 5. Zwieranie styków połączonych szeregowo z różnymi rezystancjami powoduje wymuszenie różnych napięć na ADKEY. Te napięcia są mierzone przez wewnętrzy przetwornik analogowo cyfrowy i na podstawie tych pomiarów wykonywane są poszczególne komendy. Ponieważ nie testowałem tego trybu pracy, a nie mogłem skopiować chińskich znaków z rysunku do translatora, to przypisanie funkcji do poszczególnych styków należy traktować orientacyjnie. Prawidłowość przypisania funkcji sterujących do styków można łatwo zweryfikować po zbudowaniu układu z rysunku 5. Sterowanie poprzez wejście ADKEY można włączyć lub wyłączyć komendą przesyłaną interfejsem UART. Domyślnie ta funkcja jest włączona, co pozwala na pracę w tym trybie bez konieczności użycia sterownika mikroprocesorowego.
Komendy sterujące modułem można przesyłać wykorzystując standardowy interfejs sterujący UART. Parametry transmisji to: prędkość 9600Bd, jeden bit stopu, brak bitu parzystości i brak sterowania przepływem danych. Podobnie jak w wypadku YX5300, do sterowania wystarczą dwie linie: RxD i TxD.
Format ramki sterującej pokazano na rysunku 6. Od razu rzucają się w oczy podobieństwa z układem YX5300, co sugeruje tego samego producenta układu scalonego.
Ramka rozpoczyna się od bajtu startu 7Eh. Po nim następuje bajt określający ilość przesyłanych bajtów od bajtu komendy do bajtu stopu lub liczba przesyłanych bajtów tj. wszystkie bajty w ramce bez bajtu startu i stopu. Pola parametru mogą nie występować w ogóle lub może ich być różna liczba, zależnie od rodzaju komendy. Każda ramka kończy się bajtem stopu o wartości EFh.
Komendy odtwarzacza
Zestaw podstawowych umieszczono w tabeli 6. W tym przypadku ramka sterująca nie zawiera pola parametrów. Na przykład żeby wykonać komendę PLAY trzeba wysłać sekwencję 7E 02 01 EF, a komendę PAUSE sekwencję 7E 02 02 EF. Po wysłaniu komendy moduł odpowiada wysłaniem sekwencji znaków ASCII:
- „OK” dla prawidłowo rozpoznanej i zdekodowanej komendy.
- „ERR” dla nierozpoznanej komendy.
W tabeli 7 umieszczono zestaw komend z 8-bitowym argumentem (hex) przeznaczonych do konfigurowania pracy modułu. Ustawienie poziomu głośności może wyglądać następująco: 7E 03 31 1E EF.
Ostatni zestaw komend ma argument 2-bajtowy (16-bitowy) i jest przeznaczony do wybierania pliku do odtwarzania. Komenda 41h wybiera numer pliku (utworu) do odtwarzania. Na przykład, aby odtworzyć plik numer 8 trzeba wysłać komendę 7E 04 41 00 08 EF. Komendy wyboru pliku działają podobnie, jak w module z YX5300. Można identyfikować pliki za pomocą indeksu lub podając numer folderu i numer pliku w folderze. W razie komendy „Wybierz plik z folderu” (42h) folder musi mieć nazwę od 01 do 99, a pliki nazwę 001do 255.mp3 (lub 1do 255wav). Jeżeli foldery i pliki nie będą tak nazywane, to funkcja wyboru plików 42h nie będzie działała poprawnie. Na rysunku 7 pokazano strukturę folderów i plików zapisanych na pendrive w trakcie testowania modułu odtwarzacza.
Żeby odtworzyć plik nr 002 z katalogu 01 trzeba wysłać komendę 7E 04 42 01 02 EF.
Testy praktyczne
Napięcia zasilające i interfejs sterujący jest taki sam, jak w module YX5300, więc zastosowałem taki sam układ testowy z modułem Microstick II, wyświetlaczem OLED i impulsatorem. Dokładnie w taki sam sposób został skonfigurowany układ UART oraz obsługa wyświetlacza i impulsatora. Funkcje komend zapisują bufor BufCmd kolejnymi bajtami przesyłanymi przez UART do modułu. Na listingu 7 pokazano funkcję PlayMp3(), wysyłającą komendę PLAY o kodzie 01h. Najpierw do bufora BufCmd[] są zapisywane bajty: startu, liczba danych, kodu komendy i stopu. Potem na ekranie wyświetlacza jest wyświetlana informacja o uruchomieniu odtwarzania „PLAY TRACK” i jest wywoływana funkcja WriteCmdMp3() z argumentami: wskaźnikiem na bufor z bajtami do wysłania i ilością danych do wysłania (listing 8). Po wysłaniu bajtów komendy program odczekuje 50 ms na odebranie potwierdzenia. To o wiele dłużej, niż potrzeba. Każdy bajt to 10 bitów przesyłanych z prędkością 9600 b/s, więc przesłanie jednego bajtu trwa 1/9600×10=1,04 ms. Trzy bajty potwierdzenia to ok. 3 ms, 4 bajty odpowiedzi po komendach o status modułu to ok. 4 ms, jednak podczas obserwacji transmisji na oscyloskopie widać było, że moduł odpowiada dopiero po pewnym czasie.
Z zestawu komend konfigurujących najczęściej używana będzie komenda ustawiania głośności – pokazano ją na listingu 10. W tym wypadku, po kodzie komendy jest wysyłany jeden bajt argumentu mogący mieć wartość z zakresu 0…30. Do przedstawionych wyżej komend trzeba dołączyć komendę wyboru pliku na podstawie numeru katalogu i numeru pliku (listing 11) i można zbudować prosty, ale funkcjonalny odtwarzacz plików mp3.
Podsumowanie
Pokazane tu moduły odtwarzania plików dźwiękowych są głównie przeznaczone do zastosowań przemysłowych. Zbudowanie „konsumenckiego” odtwarzacza plików muzycznych mp3 jest również możliwe, ale kłopotliwe. Przeszkodą mogą być narzucone nazwy plików, ale głównie brak możliwości odczytania rzeczywistej nazwy pliku będącej jednocześnie nazwą utworu. Żeby skutecznie wybierać utwory do odtwarzania, trzeba za każdym razem zmieniać ich nazwę, aby zaczynała się od trzycyfrowej liczby.
Podczas testów okazało się, że oba moduły radzą sobie z podanymi częstotliwościami próbkowania, ale gorzej jest z przepływnością. Na początku przez zupełny przypadek umieściłem na nośniku pliki z przepływnością 320 kb/s. Moduł YX5300 jakoś sobie poradził. Moduł z interfejsem USB odtwarzał materiał dźwiękowy ze sporym poziomem szumów i chwilowymi zniekształceniami. Widać było, że wbudowany mikrokontroler nie bardzo radził sobie z takim plikiem. Materiał nagrany z przepływnością od 64 kB/s do 128 kb/s był odtwarzany z dobrą jakością. Zważywszy na przeznaczenie modułów trudno to zakwalifikować jako wadę, bo przepływność 128 kb/s daje już bardzo dobrą jakość odtwarzanego dźwięku.
Na pewno ze względu na bardzo korzystny stosunek cena/możliwości warto się zainteresować zastosowaniem tego rozwiązania we własnych konstrukcjach, szczególnie tych amatorskich. W zastosowaniach profesjonalnych problemem może być stabilność dostaw.
Tomasz Jabłoński, EP
