Politechnika ŁódzkaInstytut Informatyki
Instytut Informatyki 90-924 Łódź, ul. Wólczańska 215, budynek B9 tel. 042 631 27 97, 042 632 97 57, fax 042 630 34 14 email: [email protected]
PRACA DYPLOMOWA MAGISTERSKA
Programowa realizacja radiainternetowego w oparciu o system
mikrokontrolerowy
Wydział Fizyki Technicznej, Informatyki i Matematyki StosowanejPromotor: dr inż. Michał MorawskiDyplomant: Adrian CiabiadaNr albumu: 137970Kierunek: InformatykaRodzaj studiów: Studia dzienneSpecjalność: Sieci komputerowe i systemy teleinformatyczne
Łódź, wrzesień 2011
Spis treści
1 Wstęp 3
1.1 Problematyka tematu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Omówienie innych rozwiązań w dziedzinie . . . . . . . . . . . . . . . . . . . . . . . 5
2 Cel i zakres pracy 8
3 Opis użytego sprzętu oraz środowiska 10
3.1 Specyfikacja techniczna podzespołów . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Opis konfiguracji środowiska . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Charakterystyka interfejsów szeregowych . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2 I2S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Realizacja praktyczna tematu 20
4.1 Schemat działania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Rozwiązania w zakresie obsługi strumienia wejściowego . . . . . . . . . . . . . . . . 21
4.3 Programowa realizacja dekodera MP3 . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Konfiguracja przetwornika cyfrowo-analogowego . . . . . . . . . . . . . . . . . . . . 32
4.5 Obsługa programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Ograniczenia techniczne współpracy zastosowanych urządzeń 40
6 Podsumowanie 42
6.1 Możliwości i ograniczenia programu . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Kierunek rozwoju aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Bibliografia 44
Spis rysunków 46
Spis tabel 47
Załączniki 48
2
Rozdział 1
Wstęp
1.1 Problematyka tematu
We wstępie do niniejszej pracy przedstawiono podstawowe zagadnienia i pojęcia
związane z realizowanym tematem. Przedmiotem tego opracowania jest programowa
realizacja radia internetowego (odbiornika) w oparciu o system mikrokontrolerowy.
Takie sformułowanie tematu może stanowić o atrakcyjności przedmiotu badań. Pra-
ca ta może być bowiem interesująca zarówno dla osób posiadających wykształcenie
ukierunkowane w dziedzinie informatyki, jak i dla osób bez specjalistycznej wiedzy.
Czytelnik, który odebrał wyższe wykształcenie techniczne zapewne zwróci uwagę na
to, że w pracy tej oparto się na układzie mikrokontrolerowym. Co należy rozumieć
pod taką nazwą? W literaturze fachowej zaznacza się granicę między mikrokontro-
lerem, a mikroprocesorem. Ten ostatni jest określany jako element, który nie jest
w stanie pracować samodzielnie. Do jego działania potrzebne jest natomiast rozbu-
dowane otoczenie, składające się z magistrali systemowej oraz pamięci programu,
pamięci danych i układów wejścia/wyjścia. Mikrokontroler jest niczym innym jak
mikroprocesorem wyposażonym w te niezbędne elementy[19]. W niniejszej pracy
stosowane będzie takie nazewnictwo.
Trzeba przyznać, że urządzenia oparte na technologii mikrokontrolerowej są obec-
nie powszechne. Poczynając na obsłudze bramy garażowej, a skończywszy na sys-
temach sterujących rakiet kosmicznych. Ukierunkowanie w stronę specjalizowanych
autonomicznych urządzeń realizujących określone zadania, zdaje się mieć uzasadnio-
ne przyczyny. Po pierwsze takie urządzenia są niejednokrotnie atrakcyjne cenowo.
Koszt wytworzenia serii jednakowych płytek drukowanych z zabudową elementów
3
SMD1 jest stosunkowo niewielki. Nawet dla klienta detalicznego nabycie układu sca-
lonego rodziny ARM czy ATMEGA nie stanowi najmniejszego problemu. Oprócz
korzystnej ceny zakupu taka sytuacja obniża koszty utrzymania danego systemu czy
instalacji. Kiedy dane urządzenie przestanie funkcjonować, można bez większych
nakładów je wymienić. Kolejną niekwestionowaną zaletą jest łatwość projektowania
urządzeń z wykorzystaniem mikrokontrolerów. Większość z nich jest wyposażona
we wszystkie standardowe interfejsy szeregowe. Warto również w tym miejscu po-
wiedzieć o rosnących możliwościach systemów typu embedded (ang. „wbudowany”).
Systemy takie bazują często na nowoczesnych rozwiązaniach rodziny ARM. Mikro-
kontrolery te dysponują odpowiednią dla większości zastosowań ilością pamięci RAM
i ROM oraz taktowane są zadowalająca częstotliwością. Oczywiście nie są to warto-
ści porównywalne z nowoczesnymi mikroprocesorami stosowanymi w komputerach
PC. Podobnie jest z elastycznością. W przypadku mikrokontrolera nie możemy „do-
łożyć do środka” dodatkowej pamięci. Jednak w przypadku większości zastosowań
te dwa ograniczenia nie mają znaczenia. Działającego układu się nie modernizuje.
Warto jedynie na etapie rozpoczecia projektu odpowiednio dobrać układ do swo-
ich potrzeb. Projekt będący przedmiotem tej pracy został zrealizowany w oparciu
o mikrokontroler serii Cortex-M3 należący do rodziny ARM. Szczegóły techniczne
znajdują się w rozdziale 3.
Dla czytelnika będącego nieobeznanym w temacie architektury i technicznej stro-
ny projektu zapewne ważniejsze będzie, co aplikacja ma robić. Zadaniem autora
było zaprojektowanie aplikacji zapewniającej możliwość odbioru radia internetowe-
go. Zagadnienie to zdaje się być interesujące. W dzisiejszych czasach strumieniowy
przekaz multimediów cieszy się powodzeniem. W ten sposób można słuchać audycji
radiowych, oglądać programy telewizyjne za pośrednictwem Internetu. W szczegól-
ności radio internetowe stało się rozpowszechnione. Wiele osób zamieszkujących po-
za ojczyzną może w ten sposób dalej słuchać swoich ulubionych stacji. Tym samym
możemy słuchać programów z całego świata. Wybór jest szeroki. Warto odwiedzić
katalogi internetowe2 zawierające zbiór najróżniejszych programów.
W wielu krajach podejmuje się próby wprowadzenia technologii cyfrowego nadawa-
nia audycji radiowych DAB3. Jednak technologia ta dotąd nie przyjęła się. Lepsza
jakość dźwięku nie okazała się wystarczająca by wyprzeć analogową transmisję FM.
Wielokrotnie mówi się, że nie cyfrowe lecz internetowe radio może wyprzeć tech-
nologię analogową. Właśnie taka forma przekazu w chwili obecnej zyskuje coraz to1Surface Mount Device element elektroniczny przeznaczony do montażu powierzchniowego2Przykładowo: http://dir.xiph.org/, http://www.shoutcast.com/3Digital Audio Broadcasting
4
większą dominację.
Początków strumieniowego przekazu danych audio możemy upatrywać w latach 90’.
Pierwsza próba została podjęta w 1994 roku podczas koncertu Rolling Stones. Jed-
nakże w tamtych czasach problemem były ograniczenia związane z przepustowością
łącz. Późniejszy rozwój metod kompresji wspomógł rozwój internetowych rozgłośni
radiowych. Stopniowo również polepszały się parametry łącz, co dało możliwości
zwiększenia jakości odbioru. Postęp zaowocował rosnącymi dochodami tej branży
liczonymi w setkach milionach dolarów.
Reasumując uzasadnionym wydaje się być wniosek, że temat pracy jest ciekawym
zagadnieniem zarówno w ujęciu praktycznym, jak i jako zagadnienie techniczne.
1.2 Omówienie innych rozwiązań w dziedzinie
Koncepcja budowy niezależnego urządzenia realizującego funkcjonalność odbioru ra-
dia internetowego jest powszechnie znana. Oprócz zasadniczego zastosowania takich
projektów, wzbogacane są one o funkcjonalność nagrywania obieranej muzyki na no-
śniki pamięci. Zależnie od możliwości danego układu bazowego (ilość pamięci RAM,
taktowanie CPU) dany odbiornik może mieć zdolność dekodowania różnej liczby
formatów kompresji.
W rozdziale tym pragnę pokazać projekty, napotkane w trakcie realizacji pracy. Trze-
ba zaznaczyć, że często rozwijane są one komercyjnie, co skutkuje brakiem wglądu
w szczegóły implementacji. Jednak można również spotkać projekty rozwijane w spo-
sób otwarty.
Jednym z gotowych urządzeń dostępnych na rynku jest urządzenie firmy Logitech
(Logitech Squeezebox Internet Radio Music Player). Zapewnia ono obsługę forma-
tów audio: MP34, FLAC5, WAV6, AIFF7, WMA8, Ogg Vorbis9, HE-AACv210, Apple
Lossless11. Posiada ponadto zarówno interfejs Ethernet jak i bezprzewodowy 802.11g.
Problemem może być cena. W tej chwili to oraz podobne urządzenia kosztują około
600-700 zł.4MPEG-1/MPEG-2 Audio Layer 3 - standard kompresji audio5Free Lossless Audio Codec - metoda bezstratnej kompresji dźwięku6wave form audio format - format nieskompresowanych plików audio7Audio Interchange File Format - opracowany przez Apple format nieskompresowanych plików audio8Windows Media Audio - format kompresji dźwięku wprowadzony przez Microsoft9stratny kodek dźwięku z rodziny Ogg10rozszerzenie formatu AAC (ang. Advanced Audio Coding)11kodek bezstratnej kompresji dźwięku
5
Innym ciekawym projektem, w którego źródło udostępniono pełny wgląd jest ra-
dio internetowe firmy Watterott. Koncepcja została oparta o zastosowanie mikro-
kontrolera Cortex-M3 producenta Luminary Micro (symbol układu LM3S6950[11]).
Proces dekodowania skompresowanych danych realizowany jest sprzętowo w oparciu
o układ VLSI (symbol układu VS1053[14]). Użycie zewnętrznego dekodera jest in-
teresującym rozwiązaniem. Pozwala to oszczędzić często ograniczoną pamięć RAM
i zredukować obciążenie procesora. Poniżej prezentuję schemat blokowy rozwiązania
firmy Watterott[6]. MCU jakie zastosowano w tym przykładzie posiada 64KB pa-
mięci RAM, 256KB pamięci FLASH i maksymalnie taktowany jest częstotliwością
50Mhz. Niska częstotliwość oraz niewielka ilość dostępnej pamięci uzasadnia użycie
zewnętrznego układu dekodującego pliki mp3 (VS1053).
Rysunek 1.1: Projekt firmy Watterott[6]
Warto zwrócić uwagę na opcjonalne zastosowanie pamięci FRAM. Pamięci takie
dołączane interfejsem SPI12, I2C13 bądź równoległym często mogą stanowić rozwią-
zanie ewentualnych ograniczeń zasobów. Wspomniany mikrokontroler nie posiada
interfejsu I2S14, co również uzasadnia użycie układu VLSI. Radio można obsługiwać
zarówno poprzez klawisze funkcyjne, interfejs na stronie WWW oraz pilota zdalnego12Serial Peripheral Interface - rodzaj synchronicznego interfejsu szeregowego13Inter-Integrated Circuit - dwuprzewodowy interfejs szeregowegy14Integrated Interchip Sound - interfejs szeregowy dla cyfrowych urządzeń audio
6
sterowania. Projekt ten nie ustępuje wielu komercyjnym rozwiązaniom.
Reasumując należy stwierdzić, że czynniki takie jak - coraz większa popularność in-
ternetowych stacji radiowych, rosnąca ilość osób mających dostęp do łącz wysokiej
przepustowości, postęp w dziedzinie mikrokontrolerów będą determinowały rozpo-
wszechnienie takich urządzeń i powstawanie nowych projektów.
7
Rozdział 2
Cel i zakres pracy
Można stwierdzić, że cel tej pracy wykracza poza skonstruowanie odpowiedniego
programu. Intencją autora było bowiem poszerzenie posiadanej dotychczas wiedzy
i wdrożenie w dziedzinę systemów wbudowanych. Obrany temat stanowi ku temu
dobrą sposobność. Ponadto dla studenta specjalizacji sieci komputerowych ważnym
powinno być by wybrane zagadnienie łączyło się z dobrze znanymi mu pojęciami
i mechanizmami. Tak jest w przypadku realizowanej pracy. Co więcej stanowi ona
sposobność do poznania zasad działania kontrolera Ethernet oraz stosu protokołów
TCP/IPv4 (wersji 4.) od podstaw. Na uwagę zasługuje również fakt, iż opisywa-
ny projekt ma dużą wartość praktyczną. Tym samym jest on ukierunkowany na
konkretny cel.
Jak wynika z treści rozdziału 1 przedmiotem tej pracy jest projekt radia interneto-
wego, o programowej implementacji dekodera MP3. Wstęp przedstawia niezbędne
terminy i zagadnienia dotyczące tematu. W drugiej części wspomnianego rozdzia-
łu omówiono również podobne projekty. Rozdział 3 opisuje wybrane rozwiązania
sprzętowe oraz użyte narzędzia programistyczne. Podrozdział 3.1 przedstawia za-
stosowane w projekcie układy i urządzenia. Zawarto w nim wiele odniesień do not
katalogowych producentów. Znaczące dane zostały opracowane w formie tabel. Na-
stępny podrozdział 3.2 zawiera informacje dotyczące ustawień środowiska progra-
mistycznego. Fragment ten może stanowić dla wielu osób krótki przewodnik, jak
poprawnie dokonać konfiguracji dla omawianego rodzaju mikrokontrolerów. Fakt, iż
wypracowanie poprawnych ustawień nie jest proste, może stanowić o dużej wartości
tego rozdziału.
W niniejszym opracowaniu najbardziej obszernym jest rozdział 4. Wyjaśniono w nim
szczegóły dotyczące zastosowanych rozwiązań. Zaprezentowano również fragmenty
8
kodu źródłowego aplikacji. Rozdział ten w prawdzie nie podejmuje wszystkich kwe-
stii implementacyjnych, ale prezentuje te, które zdaniem autora są najistotniejsze.
W treści tej części pracy postarano się przedstawić wpierw ogólny zarys funkcjo-
nowania aplikacji. Temu celowi służy podrozdział 4.1. Następnie pokazano budowę
najważniejszych komponentów. Podrozdział 4.2 przedstawia zagadnienia dotyczące
obsługi kontrolera Ethernet oraz stosu TCP/IPv4. Następny podrozdział 4.3 opisu-
je funkcjonowanie biblioteki dekodującej pliki mp3. We fragmencie tym pokazano
sposób jej konfiguracji oraz implementację API (z ang. Application Programming
Interface, interfejs programowania aplikacji). Z kolei podrozdział 4.4 zawiera infor-
macje dotyczące konfiguracji przetwornika cyfrowo-analogowego. W części tej zawar-
ty został również opis metod zaopatrywania układu DAC (z ang. Digital to Analog
Converter, przetwornik cyfrowo-analogowy) w dane.
Rozdział 5 stanowi zestawienie wszystkich problemów występujących w trakcie re-
alizacji projektu. Z punktu widzenia czytelnika, który pracuje nad podobnym pro-
jektem ta część będzie stanowiła najciekawszą i najbardziej wartościową część pracy.
Ostatni rozdział to podsumowanie niniejszego opracowania. Zawarto w nim infor-
macje na temat ograniczeń funkcjonowania programu, jak i perspektywach rozwoju.
9
Rozdział 3
Opis użytego sprzętu oraz
środowiska
3.1 Specyfikacja techniczna podzespołów
Omawiany projekt został wykonany na bazie mikrokontrolera z rdzeniem ARM
Cortex-M3 produkcji NXP Semiconductors o oznaczeniu LPC1769. Wybrane pa-
rametry tego układu zostały zamieszczone w tabeli 3.1
Tabela 3.1: Dane mikrokontrolera LPC1769[4]
Model: LPC1769
Częstotliwość taktowania MCU: do 120MHz
Rozmiar pamięci flash: 512k
Rozmiar pamięci RAM: 32kB SRAM + 2x16kB AHB RAM
Interfejsy: 4 UART, 2 CAN, 2 SSP, SPI, 3 I2C, 2
wej. I2S 2 wyj. I2S
Peryferia: Ethernet, 12-bitowy przetwornik
analogowo-cyfrowy 10-bitowy prze-
twornik cyfrowo-analogowy
Istotne dla realizacji projektu, będącego przedmiotem tej pracy jest wysoka czę-
stotliwość MCU oraz rozmiar pamięci RAM. Seria LPC17xx przez długi czas była
jedną z najbardziej atrakcyjnych cenowo i wydajnościowo. NXP wprowadziło jednak
mikrokontrolery serii 18xx. Zasługują one na uwagę ze względu na rozmiar pamięci
RAM, który przekracza 100kB.
Układ LPC1769 posiada przetworniki DAC/ADC. Możliwe jest ich użycie, tak by
10
uzyskać analogowe wyjście/wyjście sygnału audio. Ze względu na niską jakość wspo-
mnianych przetworników zaopatrzono się w bardziej zaawansowany układ DAC
(TLV320AIC23B - opis w dalszej części tego rozdziału). Spośród szeregu interfejsów,
jakimi dysponuje układ LPC1769 podczas realizacji tematu przydatne okazały się
I2S oraz I2C. Zasadniczą zaletą wybranego przeze mnie układu jest obecność kon-
trolera Ethernet MAC. Jego realizacja pokazana jest na rysunku 3.1. Z kontrolera
zostało wyprowadzone złącze interfejsu RMII1.
Rysunek 3.1: Schemat blokowy układów serii LPC17xx[2]
RMII definiuje standard połączeń sterowników warstwy fizycznej i kontrolerów MAC.
Nazwa Reduced wywodzi się od tego, że w porównaniu z MII2, omawiane rozwiązanie
wykorzystuje mniejszą liczbę fizycznych połączeń. Ograniczeniem RMII jest wspar-1Reduced Media Independent Interface - interfejs kontrolerów Ethernet2Media Independent Interface - interfejs kontrolerów Ethernet
11
cie tylko dla 10/100Mbit/s. Do działania całości interfejsu Ethernet wymagane jest
jeszcze dołączenie sterownika warstwy fizycznej.
W celu ułatwienia pracy dokonano zakupu zestawu uruchomieniowego, który oprócz
mikrokontrolera posiadał także sterownik Ethernet PHY3. Omawiany moduł to
MMlpc1769-1-2-1-1 wyprodukowany przez firmę Propox [21]. Poniżej przedstawiam
schemat blokowy.
Rysunek 3.2: Schemat blokowy minimodułu[21]
Oprócz dołączenia układu DP83848[23], oscylatorów, gniazda Ethernet minimoduł
został wyposażony w pamięć DataFlash o pojemności 4MB. jest ona dostępna po-
przez interfejs SPI.
Do omawianego minimodułu producent przewidział płytę ewaluacyjną, która rów-
nież została zakupiona. Jest to zestaw układów oznaczony symbolem EVBmm[22].
Minimoduł umieszcza się w specjalnej podstawce na płycie. Wyjścia mikrokontro-
lera są wyprowadzone na złącza kołkowe pozłacane (tzw. goldpiny). Płyta EVBmm
obejmuje:
• Złącza USB
• 8 mikroprzełączników3Physical Control Layer
12
• 8 diod LED do ogólnego zastosowania
• Sygnalizator dźwiękowy (buzzer)
• 2 potencjometry
• Dwa porty RS232 wraz z diodami LED4 sygnalizującymi pracę
• Złącze do programowania/debuggowania w systemie JTAG
• Złącze karty SD/MMC5
• Kodek audio
Podłączenie poszczególnych peryferiów odbywa się poprzez połączenie wyprowadzeń
danego układu z wyprowadzeniami nóżek minimodułu MMlpc1769.
Na płycie EVBmmTm znajduje się kodek audio TLV320AIC23B[12].
Główne cechy tego układu to:
• Wyjście słuchawkowe typu Jack 3,5mm / Wyjście liniowe Jack 3,5m / Stereo-
foniczne wejście liniowe Jack 3,5mm / Wejście mikrofonowe Jack 3,5mm
• Napięcie zasilania 3,3V (co jest zgodne z logiką reszty układów)
• Interfejs Audio kompatybilny z I2S, Left Justified, Right Justified, lub DSP6
• Częstotliwości próbkowania od 8kHz do 96 kHz
• Długości słowa cyfrowych danych audio: 16,20,24,32 bity
• Sterowanie zasobami kodeka : interfejs I2C lub SPI
• Praca w trybie Master lub Slave
• Cyfrowy filtr nadpróbkujący
• Wbudowany wzmacniacz słuchawkowy
Układ ten posiada zarówno przetwornik analogowo-cyfrowy jak cyfrowo-analogowy.
W realizowanym projekcie używam wyłącznie układu kodeka jako DAC. Podstawowe
cechy tego układu prezentuje tabela 3.2.
Szczegóły dotyczące konfiguracji i obsługi układu TLV320AIC23B zostaną przed-
stawione w rozdziale 4.4Light-Emitting Diode - półprzewodnikowy element optoelektroniczny5Secure Digital, MultiMedia Card - standardy kart pamięci6Digital Signal Processor - wyspecjalizowany układ przetwarzania sygnału cyfrowego
13
Tabela 3.2: Parametry DAC układu TL320AIC23B[12]
3.2 Opis konfiguracji środowiska
Podczas realizacji pracy posługiwałem się programatorem/debuggerem JTAG-lock-
pick[5]. JTAG służy do realizacji metody ISP (In-System Programming). Rozwią-
zanie to daje możliwość przeprogramowania układu bez jego demontażu z urządze-
nia. Oprócz interfejsu JTAG zakupiony programator posiada także wyprowadzenia
UART oraz RS-232. Obsługa interfejsu UART daje możliwość dodatkowego debu-
gowania aplikacji, bez ustawiania breakpointów czy zatrzymywania rdzenia. Można
natomiast wypisać na konsolę wartość zmiennej bądź inny dowolny napis.
Jako narzędzia wspierającego ISP użyto OpenOCD[3] (Open On-Chip Debugger)
w wersji 0.4.0. W przypadku stosowanego układu niezbędne było jednak poprawienie
domyślnego skryptu konfiguracyjnego.
Zapis
r e s e t c o n f i g t r s t a n d s r s t s r s t p u l l s t r s t
musiał zostać zastąpiony przez:
r e s e t c o n f i g t r s t a n d s r s t s epara te
Po dokonaniu tej modyfikacji oraz usunięciu zworki na płycie ewaluacyjnej progra-
mowanie układu odbywa się bez żadnych problemów. By połączyć się z układem
należy wydać polecenie:
openocd −f t a r g e t / lpc1768 . c f g −f i n t e r f a c e / j tagkey . c f g
14
Spośród kilku możliwości jako Toolchain wybrany został Sourcery G++ Lite w wersji
2010.1.0.188[15]. Ponieważ jest sponsorowany przez ARM Ltd. pozostaje w zgodno-
ści z najnowszymi specyfikacjami. Oprócz Sourcery można wybrać takie toolchain
jak GNUARM[16] czy WINARM[7].
Jako IDE użyłem środowiska Eclipse (dla języka C). Zostało ono, poprzez doin-
stalowanie wtyczek, wzbogacone o możliwości debuggowania układu. Ważne jest
by utrzymać zgodność między wersją wtyczki, a wersją Eclipse. Częste trudności
z poprawnym uruchomieniem są w wielu przypadkach wynikiem niezgodnych wer-
sji. Drugim problemem okazują się poprawne komendy wydawane do debuggera.
Poniżej przedstawiona została poprawna konfiguracja.
Rysunek 3.3: Konfiguracja GDB w Eclipse Helios
Poprawne ustawienie środowiska nie jest zadaniem łatwym. Skrypty konfiguracyjne
OpenOcd nie zawsze są zawsze poprawne. Utworzenie dobrej, stabilnej konfiguracji
może pochłonąć wiele czasu. Warto jednak zrobić to dobrze, gdyż zła konfiguracja
utrudni bądź uniemożliwi pracę.
15
Rysunek 3.4: Zakładka ustawień z komendami do GDB
3.3 Charakterystyka interfejsów szeregowych
Rozdział ten ma za zadanie przybliżyć czytelnikowi zastosowane w niniejszej pracy
interfejsy. We fragmencie tym omówiono funkcjonowanie:
• I2C
• I2S
Ogólna wiedza na temat działania wymienionych interfejsów jest niezbędna do dal-
szych rozważań zawartych w rozdziale 4.
3.3.1 I2C
Interfejs ten został opatentowany i opracowany przez firmę Philips. Dlatego I2C jest
zastrzeżoną nazwą. Odpowiednikiem dla produktów firmy Atmel jest interfejs TWI.
Cechy charakterystyczne opracowanego interfejsu[17]
• magistrala składa się z dwóch dwukierunkowych linii typu otwarty kolektor:
SDA (linia danych) i SCL (linia zegara)
• łatwa konfiguracja przez proste dołączanie i odłączanie układów
16
• transmisja synchroniczna, jednokierunkowa w danym momencie, z prędkością
do 3,4Mb/s w trybie master -slave
• transmisją steruje master generujący sygnał zegarowy SCL
• każdy układ slave ma swój unikatowy identyfikator, którym posługuje się ma-
ster inicjując komunikację
Funkcjonowanie omawianego interfejsu zostanie wyjaśnione na podstawie poniższego
diagramu.
Rysunek 3.5: Transfer danych poprzez interfejs I2C
Transfer danych odbywa się poprzez formowanie ich w ramki długości 8 bitów. Urzą-
dzenie występujące w roli master dla danej transmisji ma za zadanie ją zainicjować.
Temu celowi służy sekwencja start. Jej wygenerowanie polega na wymuszeniu zmiany
na lini SDA z wysokiego na niski, podczas gdy na lini SCL obserwujemy stan wysoki.
Na rysunku 3.5 zaznaczono wspomnianą sekwencję inicjującą. Warto zwrócić uwa-
gę, że przesył określonego ciągu bajtów musi zostać w podobny sposób zakończony
(sekwencja stop). Różnica polega na tym, że stan linii SDA zmienia się tym razem
z niskiego na wysoki.
Rysunek 3.5 wskazuje, że po zainicjowaniu transmisji następuje wysłanie ciągu da-
nych. Urządzenie nadrzędne wysyła wówczas adres docelowy urządzenia pełniącego
rolę slave. Następnie master czeka na potwierdzenie gotowości drugiej strony. Po-
twierdzenie to wskazywane jest sygnałem ACK. Realizacja odbioru potwierdzenia
sprowadza się do ustawienia przez urządzenie master stanu wysokiego na linii SDA
i wygenerowaniu dziewiątego impulsu zegarowego na linii SCL. Urządzenie podrzęd-
ne odbierając ten impuls wprowadza stan niski na linii SDA, tym samym potwier-
dzając gotowość do transmisji danych. Interfejs I2C zakłada wysyłanie potwierdzeń
po każdym przesłanym bajcie[17].
17
Załóżmy, że w układzie odbierającym dane zostało zgłoszone przerwanie o priory-
tecie wyższym niż transmisja. Wówczas urządzenie to wymusza stan niski na szynie
SCL. Nadawca zostaje w tym momencie wprowadzony w stan oczekiwania. Jest to
zilustrowane na omawianym diagramie.
Przepatrując się szczegółowo rysunkowi 3.5 można, że zauważyć stan linii SDA musi
zostać ustalony przed pojawienie się logicznej „jedynki” na linii SCL. Stan ten musi
pozostać stabilny przez określony czas po opadającym zboczu sygnału zegarowego.
Parametry czasowe dotyczące interfejsu I2C można odnaleźć w literaturze fachowej
oraz notach katalogowych[9].
Adres układu slave jest określony na siedmiu bitach. Ósmy bit nadawanej porcji da-
nych określa kierunek transmisji. W przypadku „0” na tej pozycji to master wysyła
dane do układu slave. W przypadku wystąpienia „1” mamy do czynienia z sytuacją
odwrotną.
Oczywiście, to krótkie opracowanie nie wyczerpuje tematu. Nie omówiono tu wielu
istotnych aspektów, takich jak sposób adresowania wielu układów podrzędnych czy
też arbitrażu dla przypadku kilku urządzeń master. Opis zawarty w tej części pracy
stanowi jedynie podstawy do właściwego zrozumienia kolejnych rozdziałów.
3.3.2 I2S
I2S (Integrated Interchip Sound) jest standardowym interfejsem szeregowym, służą-
cym do realizacji połączeń między cyfrowymi urządzeniami audio.
Główne cechy interfejsu I2S:
• magistrala składa się z trzech linii: SCK (sygnał zegarowy), WS (wybór słowa),
SD (linia danych); opcjonalnie czwarta linia to sygnał MCLK (master clock)
• dwukierunkowe operacje dzięki dwóm jednokierunkowym liniom danych
• wspiera wiele formatów danych audio (I2S format, Left Justified, Right Justi-
fied)
Jeden układ przyjmuje rolę nadrzędnego (master), drugi zaś pełni rolę slave. Możliwe
są rożne konfiguracje, co uwidoczniono na rysunku 4.3.
18
Rysunek 3.6: Podstawowe możliwości konfiguracji interfejsu I2S[10]
Układ master jak wynika z powyższego diagramu jest w stanie zarówno nadawać jak
i odbierać dane. Tak samo jest w przypadku urządzenia slave. Układ typu master
może ponadto jedynie nadzorować wymianę danych realizowaną przez dwa inne
układy.
Następny diagram pokazuje uproszczony diagram stanu linii interfejsu podczas trans-
misji danych.
Rysunek 3.7: Transfer danych poprzez interfejs I2S[10]
Zmiana stanu logicznego na linii SCK sygnalizuje moment próbkowania danych na
pozostałych dwóch liniach. Sygnał określony symbolem WS identyfikuje, czy na linii
danych mamy do czynienia z sygnałem kanału lewego czy prawego. Jego częstotli-
wość równa jest częstotliwości próbkowania. Ponadto zmiany stanu linii WS służą
jako impulsy synchronizacji początku nowego słowa. Każdy kanał ma zdolność trans-
misji 32 bitów. Dane na linii SD są przesyłane począwszy od najbardziej znaczącego
bitu (MSB).
Niewątpliwą zaletą I2S jest fakt, iż sygnały zegara oraz danych są od siebie odsepa-
rowane. Przekłada się to na odporność omawianego interfejsu na zakłócenia (tzw.
jitter).
19
Rozdział 4
Realizacja praktyczna tematu
4.1 Schemat działania
Całość projektu można rozdzielić na trzy zasadnicze części:
• Realizacja stosu TCP/IP
• Programowa dekompresja danych wejściowych
• Obsługa przetwornika cyfrowo-analogowego
Działanie aplikacji ma opierać się na prostym schemacie. Pierwszym etapem jest
obsługa danych wejściowych, które odbieramy poprzez Ethernet. Aby jednak ja-
kiekolwiek dane odebrać, urządzenie powinno posiadać adres fizyczny (MAC) oraz
sieciowy (IP). Kolejnym krokiem jest zainicjowanie połączenia TCP i zgłoszenie żą-
dania odbioru danego strumienia. Gdy zaczniemy już odbierać dane trzeba wyodręb-
nić te potrzebne (zawierające przekaz audio), a następnie przekazać je do dekodera
MP3. Zdekodowane dane muszą zostać dostarczone do przetwornika DAC. Aby było
to możliwe układ kodeka TLV320AIC23B musi zostać odpowiednio skonfigurowany.
Należy zauważyć, że operacje muszą być wykonywane w czasie rzeczywistym, tak
by do uszu słuchacza w sposób ciągły i niezakłócony docierał dźwięk.
Na następnej stronie zamieszczono przybliżony schemat blokowy układu testowego.
Na diagramie tym pominięte zostały elementy nieznaczące np. przyłączone diody
LED.
20
Rysunek 4.1: Schemat blokowy układu testowego (znaczenie użytych symboli wyjaśniono w roz-
dziale 3)
Na powyższym diagramie zaznaczono podstawowe interfejsy wykorzystywane w re-
alizacji projektu. Opis ich konfiguracji zamieszczono w następnych podtytułach bie-
żącego rozdziału.
4.2 Rozwiązania w zakresie obsługi strumienia wejściowego
Odebranie danych wejściowych jest w przypadku omawianego projektu zagadnie-
niem kluczowym. W przypadku braku tych danych, oczywistym jest, że program
działać nie będzie. Należy również uwzględnić ryzyko niepoprawnego odczytu infor-
macji. W przypadku każdej transmisji możliwe jest bowiem zagubienie, zduplikowa-
nie oraz opóźnienie jednostki danych.
Protokołem, który w swoich założeniach zawiera mechanizmy walki z powyższymi
problemami jest protokół TCP. Powszechnie stosuje się w przypadkach realizacji
nadajnika radia internetowego.
Warunkiem koniecznym odebrania transmisji danych w postaci strumienia TCP
jest zaimplementowanie obsługi tego protokołu, jak i protokołów warstw niższych.
Z tego powodu mówimy o stosie TCP/IP. Powszechnie używane komputery osobi-
ste wyposażone w system operacyjny posiadają gotowe odpowiednie mechanizmy.
W przypadku systemu mikronkontrolowego, należy o to zadbać samemu.
Pierwszym etapem jest przyłączenie kontrolera warstwy fizycznej i dodanie do pro-
jektu właściwego sterownika. Rozdział 3 podaje dane dotyczące zastosowanego ukła-
21
du. W programie będącym przedmiotem tej pracy wspomniany sterownik zawarty
jest w plikach ethmac.c oraz ethmac.h.
W plikach tych zdefiniowane są adresy odpowiednich rejestrów, ich wartości domyśl-
ne oraz funkcje kontroli modułu Ethernet. Najistotniejsze wartości konfiguracyjne
przedstawiono w listingu poniżej.
Definicja adresu MAC urządzenia
#define MYMAC 1 01
#define MYMAC 2 02
#define MYMAC 3 03
#define MYMAC 4 04
#define MYMAC 5 05
#define MYMAC 6 06
Alokowana pamięć RAM dla kontrolera Ethernet.
#define NUM RX FRAG 4 /∗ Num. o f RX Fragments 4∗1536= 6.0kB ∗/#define NUM TX FRAG 2 /∗ Num. o f TX Fragments 3∗1536= 4.6kB ∗/#define ETH FRAG SIZE 1536 /∗ Packet Fragment s i z e 1536 Bytes ∗/#define ETH MAX FLEN 1536 /∗ Max. Ethernet Frame Si ze ∗/#define RX DESC BASE 0x20080000
W trakcie realizacji projektu poważny problem wynikł z treści ostatniej linijki po-
wyższego listingu. Zazwyczaj dla kontrolera Ethernet przeznacza się obszar RAM-u
od adresu 0x20080000. Natomiast w wykorzystanym projekcie bazowym była to
wartość 0x2007C000, czyli początku bloku niższego. Sprawiło to, że program działał
wadliwie, przy czym sytuacja nie sugerowała tego typu błędu.
Procedura inicjalizacji kontrolera Ethernet przebiega w następujący sposób:
1. włączenie interfejsu
2. ustawienie w rejestrze PINSEL wyprowadzeń do kontrolera
3. zapis wartości do rejestrów sterujących
4. reset kontrolera warstwy fizycznej
5. ustawienie parametrów interfejsu - full/half duplex, 10/100Mbit
6. nadanie adresu MAC
7. inicjalizacja deskryptorów danych odbieranych i wysyłanych
8. włączenie przerwań - dla ukończonego odbioru (RX DONE)
22
9. włączenie trybów odbioru i wysyłu
Deklaracje funkcji zawartych w pliku ethmac.c
// I n i c j a l i z a c j a modułu
void Init EthMAC (void ) ;
//Odczytanie ramki w b i g endian
unsigned short ReadFrameBE EthMAC(void ) ;
//Zapis do ramki
void CopyToFrame EthMAC(void ∗Source , unsigned int S i z e ) ;
//Odczyt ramki
void CopyFromFrame EthMAC(void ∗Dest , unsigned short S i z e ) ;
//Funkcja pustego odczytu ramki − dane nie są n i g d z i e zapisywanevoid DummyReadFrame EthMAC(unsigned short S i z e ) ;
// Zg łos zen i e żądania wysłania ramki
void RequestSend (unsigned short FrameSize ) ;
//Okreś l en ie gotowośc i do wysłania danych
unsigned int Rdy4Tx(void ) ;
//Początek odczytu − o k r e ś l e n i e rozmiaru odebranej ramkiunsigned short StartReadingFrame (void ) ;
//Koniec odczytu ramki
void StopReadingFrame (void ) ;
//Funkcja o k r e ś l a j ą ca czy są nowe ramki
unsigned int CheckIfFrameReceived (void ) ;
Bazując na tak skonstruowanym sterowniku, zrealizowany został stos protokołów.
Na zakres jego funkcjonalności składają się:
• obsługa protokołów TCP/IPv4
• generowanie odpowiedzi na komunikaty ICMP (echo reply)
• wysyłanie odpowiedzi i zapytań ARP
• pozyskiwanie adresu IP z serwera DHCP
Funkcje realizujące te zadania umieszczone zostały w pliku tcpip.c. Plik nagłówkowy
tcip .h zawiera natomiast ważne stałe oraz makra.
W ramach tej części programu zdefiniowane są: adres IP, adres bramy, maska pod-
sieci oraz adres IP hosta zdalnego. Konstrukcja programu daje możliwość wyboru,
czy korzystamy z adresów przydzielanych automatycznie przez serwer DHCP, czy
nie. W drugim przypadku zostały zdefiniowane domyślne wartości:
#define MYIP 1 192
#define MYIP 2 168
23
#define MYIP 3 0
#define MYIP 4 11
#define SUBMASK 1 255
#define SUBMASK 2 255
#define SUBMASK 3 255
#define SUBMASK 4 0
#define GWIP 1 192
#define GWIP 2 168
#define GWIP 3 0
#define GWIP 4 1
Początkowo odbiór danych odbywał się poprzez polling. Oznacza to, że w pętli głów-
nej programu cyklicznie wywoływana była funkcja sprawdzająca czy pojawiły się
nowe dane. Jeżeli wynik był pozytywny to zależnie od adresu przeznaczenia i za-
wartości otrzymana ramka była przetwarzana. Ze względu na małą wydajność tej
metody, w trakcie prac nad projektem polling został zastąpiony znacznie wydajniej-
szą metodą opartą na przerwaniach.
W chwili obecnej przerwanie zgłaszane jest w momencie odebrania ramki Ethernet.
W procedurze obsługi przerwania podejmowane są dalsze decyzje dotyczące prze-
twarzania otrzymanych danych. W poniższym listingu zamieszczono treść procedury
obsługi przerwania.
void ENET IRQHandler (void ) {u i n t 3 2 t s t a t u s ;
unsigned char FrameDestination [ 6 ] ;
s t a t u s = LPC EMAC−>In tS ta tus ;
i f ( s t a t u s & INT RX DONE) {while ( CheckIfFrameReceived ( ) ) {
RecdFrameLength = StartReadingFrame ( ) ; // i l o s c danych
CopyFromFrame EthMAC(&FrameDestination , 6 ) ;
CopyFromFrame EthMAC(&RecdFrameMAC, 6 ) ;
i f ( ( FrameDestination [ 0 ] == 0xFF) && ( FrameDestination [ 1 ] == 0xFF)
&& ( FrameDestination [ 2 ] == 0xFF) && ( FrameDestination [ 3 ]
== 0xFF) && ( FrameDestination [ 4 ] == 0xFF)
&& ( FrameDestination [ 5 ] == 0xFF) ) {ProcessEthBroadcastFrame ( ) ;
} else {ProcessEthIAFrame ( ) ;
}StopReadingFrame ( ) ;
}}
24
LPC EMAC−>In tC lea r = s t a t u s ;
}
Zależnie od tego, czy mamy do czynienia z ramką typu broadcast czy kierowaną na
adres MAC urządzenia, wywoływana jest odpowiednia funkcja. W przypadku ramek
broadcast, zasadniczo w omawianym projekcie są to zapytania ARP. Czasami jednak
serwer DHCP zamiast adresować ramkę na adres MAC klienta wysyła odpowiedzi
na adres rozgłoszeniowy.
W następnym listingu przedstawiona została funkcja obsługi ramek broadcast.
void ProcessEthBroadcastFrame (void ) {
unsigned char ProtocolType ;
unsigned short TargetIP [ 2 ] ;
switch (ReadFrameBE EthMAC ( ) )
{case FRAME ARP:
{i f (ReadFrameBE EthMAC ( ) == HARDW ETH10) // Ethernet frame
i f (ReadFrameBE EthMAC ( ) == FRAME IP)
i f (ReadFrameBE EthMAC ( ) == IP HLEN PLEN)
i f (ReadFrameBE EthMAC ( ) == OP ARP REQUEST) {
CopyFromFrame EthMAC(&RecdFrameMAC, 6 ) ;
CopyFromFrame EthMAC(&RecdFrameIP , 4 ) ; // adres nadawcy
DummyReadFrame EthMAC ( 6 ) ; // MAC nadawcy n i e i s t o t n y
CopyFromFrame EthMAC(&TargetIP , 4 ) ;
i f ( !memcmp(&MyIP , &TargetIP , 4 ) ) // czy do nas?
PrepareARP ANSWER ( ) ;
}break ;
}case FRAME IP:
{i f ( ( ReadFrameBE EthMAC ( ) & 0xFF00) == IP VER IHL)
{RecdIPFrameLength = ReadFrameBE EthMAC ( ) ; // d lugosc z naglowka IP
ReadFrameBE EthMAC ( ) ;
i f ( ! ( ReadFrameBE EthMAC ( ) & (IP FLAG MOREFRAG | IP FRAGOFS MASK) ) )
{ProtocolType = ReadFrameBE EthMAC ( ) & 0xFF ; // Rozpoznanie pro toko lu
ReadFrameBE EthMAC ( ) ; // pomijamy sume kontro lna
CopyFromFrame EthMAC(&RecdFrameIP , 4 ) ; // source
CopyFromFrame EthMAC(&TargetIP , 4 ) ; // des t
// i f ( !memcmp(&MyIP, &TargetIP , 4))
switch ( ProtocolType ) {case PROT UDP:{
25
i f (ReadFrameBE EthMAC ( ) == 0x0043 && ReadFrameBE EthMAC ( ) == 0x0044 )
ProcessDHCPFrame ( ) ;
break ;
}}
}}
break ;}}}
Z racji tego, iż funkcja przetwarzania ramek unicast jest bardziej złożona, nie ma
potrzeby prezentować jej w treści w tej pracy. Opiera się jednak na tych samych
mechanizmach działania jak zawarta w powyższym listingu funkcja właściwa dla
ramek broadcast.
Ogólny schemat przetwarzania danych wejściowych prezentuje rysunek 4.2.
Rysunek 4.2: Przetwarzanie ramek Ethernet
Zależnie od protokołu, dane z przychodzącej ramki trafiają do odpowiedniej metody.
26
Najbardziej interesującym typem pakietu jaki możemy odebrać jest ten zawierający
dane strumienia. Jak zostało wcześniej zasygnalizowane informacje te są transporto-
wane w ramach połączenia TCP. Jak wynika, z rysunku 4.2 wywoływana jest w tym
przypadku funkcja TCP Service().
Metoda ta dokonuje analizy zawartości pakietu. Sprawdzane są ustawione flagi, nu-
mery sekwencyjne oraz numery potwierdzeń. W przypadku pakietów istotnych, są
one przekazywane dalej.
W tym momencie mówimy już o warstwie aplikacji modelu ISO/OSI. Za proces dal-
szego przetwarzania odpowiada funkcja shoutcast tcpapp zdefiniowana w pliku shoutcast.c.
Funkcja ta wyróżnia stany: SHOUTCAST CLOSE, SHOUTCAST CLOSED, SHOUTCAST OPENED,
SHOUTCAST HEADER, SHOUTCAST OPEN. W przypadku ostatniego nawiązywane jest od-
powiednie połączenie TCP i zgłaszane jest żądanie przyłączenia do danego strumie-
nia.
Przykładowo:
t x l e n = s p r i n t f ( ( char∗) tx ,
”GET / stream / ndrstream ndr1niedersachsen hi mp3 HTTP/1.0\ r \n”
”Host : 87 . 248 . 219 . 57\ r \n”
”User−Agent : Radio inte rnetowe \ r \n”
” Icy−MetaData : 0\ r \n”
” Connection : Keep−Al ive \ r \n”
”\ r \n” ) ;
Oznacza to, że aplikacja pod nazwą „Radio internetowe” zgłasza się do hosta pod
adresem 87.248.219.57 z żądaniem dotyczącym strumienia określonego w linijce za
słowem GET. Tak sformowany pakiet zostaje wysłany na właściwy adres IP. Następ-
nie czekamy na odebranie informacji zwrotnej. Na tym etapie mamy do czynienia
ze stanem SHOUTCAST HEADER. W przypadku odpowiedzi pozytywnej kod zwróco-
ny przez serwer będzie wynosił 200. Możliwe jest oczywiście uzyskanie odpowiedzi
negatywnej, przykładowo 400, 404, 500. Jeżeli jednak próba się udała program przy-
stępuje do dalszej analizy pakietu. Sprawdzane są parametry strumienia takie jak
bitrate oraz format kompresji danych audio. Jeżeli wszytko przebiega pomyślnie
stan ustalany jest na SHOUTCAST OPENED, a informacje trafiają do bufora. Dzieje się
to poprzez wywyołanie funkcji buffer put zdefiniowanej w pliku buffer .c.
Poniżej treść omawianej metody:
void b u f f e r p u t ( const unsigned char ∗ s , unsigned int s i z e ) {
27
unsigned int head ;
head = buf f e r w ;
while ( s i z e −−) {Buf fe r IncData [ head ] = ∗ s++;
i f (++head >= BUFFSIZE) {head = 0 ;
}}buf f e r w = head ;
return ;
}
Tablica Buffer IncData jest alokowana pod adresem 0x2007C000 co oznacza początek
banku AHB RAM1[2]. Zajmuje ona obszar 6056 bajtów. Plik źródłowy buffer .c. zawie-
ra również metodę odczytu danych, ze wspomnianego bufora. Poprzez jej wywołanie
dane trafiają do dekodera MP3, który stanowi kolejną część realizowanego projektu.
4.3 Programowa realizacja dekodera MP3
Podczas konstruowania podobnych projektów stosowane są dwa podejścia. W pierw-
szym z nich korzysta się z zewnętrznego sprzętowego dekodera plików muzycznych
rożnych formatów. W rozdziale 1 przedstawiono projekt firmy Watterott, który ko-
rzystał z układu VS1053. Element ten jest powszechnie dostępny. Można go zakupić
za około 65 zł. Wspiera dekodowanie plików MP3, AAC, WMA, FLAC, MIDI, Ogg
Vorbis. Ze względu na przystępna cenę oraz duże możliwości dekompresji to rozwią-
zanie jest bardzo interesujące. Ponadto układ ten posiada interfejsy SPI, I2S oraz
UART. Można więc bez problemu używać go w standardowych aplikacjach.
Jednakże tematem mojej pracy jest programowa realizacja radia internetowego. Sfor-
mułowanie „programowa” należy szczególnie odnieść do części odpowiadającej za
dekodowanie plików MP3. Takie podejście ma dużą wartość badawczą. Pozwala bo-
wiem zaznajomić się, z każdym elementem projektu. W momencie gdy stosujemy
sprzętowy dekoder dysponujemy wyłącznie informacjami o interfejsach bądź war-
tościach rejestrów. Zastosowanie programowego dekodera umożliwia prześledzenie
kodu oraz procesu dekompresji. Ponadto podejście to odróżnia realizowany projekt
od szeregu innych opisywanych w Internecie. Kolejną cechą zastosowanej koncepcji
jest fakt, iż pozwala ona wykorzystać w pełni możliwości mikrokontrolera, a tym
samym poznać jego ograniczenia.
W przypadku procesorów rodziny ARM ważne by implementacja biblioteki ope-
rowała na obliczeniach stałoprzecinkowych. Fakt ten jest implikowany założeniami
28
architektury. Wszelkie operacje zmiennoprzecinkowe są w przypadku procesorów
ARM symulowane za pomocą arytmetyki stałoprzecinkowej. Wysoce mało wydajne
byłoby operować na takich działaniach.
W pracy rozważano wykorzystanie jednego z dwóch dekoderów. Pierwszym jest roz-
wiązanie firmy Helix[1]. Biblioteka ta jest przystosowana zarówno dla operacji stało-
jak i zmiennoprzecinkowych. Podstawowymi cechami tego dekodera są:
• Optymalizacja dla platformy ARM
• Wysoka wydajność przy małym zużyciu energii
• Wsparcie dla MPEG1 layer 3 (48 KHz, 44.1 KHz, 32 KHz) MPEG2 layer 3 (24
KHz, 22.05 KHz, 16 KHz) oraz MPEG2.5 layer 3 (12 KHz, 11.025 KHz, 8 KHz)
• Obsługa CBR, VBR ((ang.) constant bit rate, CBR, (ang.) variable bit rate,
VBR )
• Wsparcie dla sygnału mono i wszystkich trybów stereo (normal stereo, joint
stereo, dual mono)
W tabeli 4.1 zostały zebrane dane dotyczące średniego użycia procesora oraz wyma-
gań dotyczących pamięci.
Tabela 4.1: Wymagania Helix MP3 Decoder
Typ układu mikroprocesorowego
Częst. próbko-
wania
ilość kanałów Bitrate ARM7TDMI ARM920T StrongARM1
48.0 KHz 2 320
Kbps
30 MHz 27 MHz 20MHz
44.1 KHz 2 128
Kbps
26 MHz 24 MHz 17MHz
Rozmiar alokowanej pamięci ROM 13446 B
Rozmiar alokowanej pamięci RAM 23816 B
Co prawda wartości podane powyżej nie dotyczą rodziny zastosowanego mikrokon-
trolera LPC1769. Pozwalają jednak wyobrazić sobie jakiej skali są to wartości. Dla
procesorów ARM7 oraz ARM9 w omawianej bibliotece zastosowano kod Asembler,
który pozwala na szybsze wykonywanie wielu operacji. Z uwagi na brak takiego
wsparcia dla rodziny Cortex, wartości użycia procesora mogą być nieco większe. Nie
29
jest to jednak problemem, gdyż dysponujemy procesorem taktowanym częstotliwo-
ścią 120 MHz.
Po zarejestrowaniu się na stronie producenta można bezpłatnie pobrać kod dekodera.
W pracy próbowano skorzystać z omawianej biblioteki. Niestety pomimo przeznacze-
nia odpowiedniej ilości pamięci na sekcję stosu, biblioteka nie została uruchomiona.
Alternatywą dla Helix MP3 Decoder jest biblioteka libmad. Jest ona powszechnie
wykorzystywana w wielu projektach. Można wymienić kilka z nich: AlsaPlayer, Co-
olPlayer, VideoLAN Client.
Najważniejsze cechy dekodera libmad[8]
• 24-bitowe wyjście PCM
• operacje wyłącznie stałoprzecinkowe
• spełnia normy ISO/IEC
• opublikowany na zasadach licencji GNU GPL
Niestety nie podano nigdzie średniego obciążenia procesora. Znane są natomiast wy-
magania pod względem ilości pamięci RAM. Dokument opublikowany przez NXP
Realizing an MP3 player with the LPC2148, using libmad and EFSL[20] podaje, że
potrzebne jest 33kB pamięci RAM, co przekracza ilość pamięci SRAM mikrokontro-
lera LPC1769. Warto jednak zaznaczyć, że przytoczony dokument określa rozmiar
pamięci potrzebny zarówno dla biblioteki libmad, jak i dla EFSL1. Rzeczywista ilość
niezbędnej pamięci jest więc mniejsza. Nadal jednak jest to wartość oscylująca na
granicy całkowitej wielkości pamięci SRAM.
W realizowanym projekcie posłużono się pewną modyfikacją dekodera libmad opubli-
kowaną na portalu mbed.org. Projekt madplayer[18] dedykowany dla mikrokontro-
lera LPC1768 pozwala na użycie pamięci AHB RAM na potrzeby biblioteki libmad.
Około 12kB zostaje alokowanych w bloku pamięci AHB dla USB bądź Ethernet. Ze
względu na temat niniejszej pracy wybrany został obszar pamięci dla interfejsu USB.
Ze względu na wyodrębnienie w tym obszarze miejsca dla buforów DMA dokonano
stosownego przesunięcia.
Biblioteka libmad udostępnia dwa rodzaje API – High-Level oraz Low-Level
W realizowanym projekcie zostało użyte zarówno API wysokiego jak i niskiego po-
ziomu. Rozpatrzmy najpierw sytuację, w której korzystamy z High-Level API. Inter-
fejs wysokiego poziomu wymaga zdefiniowania wywołań, z których będzie korzystała1Embedded Filesystems Library - dedykowana dla mikrokontrolerów biblioteka obsługująca systemy plików
30
procedura dekodująca. Każda z wywoływanych funkcji musi zwracać jedną z wartości
typu wyliczeniowego mad flow. Pozwala to na kontrolowanie procesu dekodowania.
Wspomniany typ wyliczeniowy składa się z czterech elementów.
• MAD FLOW CONTINUE - kontunuuj działanie dekodera
• MAD FLOW STOP - przerwij dekodowanie, wyjdź bez błędu
• MAD FLOW BREAK - zakończ dekodowanie z błędem
• MAD FLOW IGNORE - nie dekoduj bieżącej ramki, lecz kontynuuj
Pierwszym krokiem by rozpocząć korzystanie z biblioteki libmad jest jej inicjalizacja
poprzez wywołanie funkcji mad decoder init.
Przykładowo:
mad decoder in i t (&decoder , &playbuf , input func ,
header func , /∗ f i l t e r ∗/ 0 ,
output func , /∗ error ∗/ 0 ,
/∗ message ∗/ 0 ) ;
Parametry zaprezentowanej metody określają wywołania funkcji realizujących od-
czyt danych wejściowych, wyprowadzenie zdekodowanych próbek PCM, obsługę za-
wartości nagłówka. Możliwe jest również określenie funkcji odpowiedzialnej za ob-
sługę ewentualnie powstałych błędów czy też funkcji filtrującej dane audio.
W zasadzie działanie procesu dekodującego można wyrazić algorytmem opisanym
następującym pseudokodem.
i f ( n i e mam już danych )
wywołaj input func
i f ( input func zwraca , , n i e ma wi ę c e j danych ’ ’ )
wyjdź
dekoduj nagłówek i wywołaj header func
dekoduj dane mpeg audio
wywołaj metodę f i l t e r
wywołaj output func
loop
Ze względu na ograniczona ilość pamięci RAM, konieczne było zmodyfikowanie
wstępnego projektu. W przypadku wyprowadzenia danych z dekodera nie jest uży-
wane API wysokiego poziomu. Jego użycie wiązało się bowiem z utrzymywaniem
w pamięci tablicy próbek.
31
Była ona zdefiniowana jako:
mad f ixed t samples [ 2 ] [ 1 1 5 2 ] ;
Tym samym zajmowała w pamięci 9216 bajtów. Zmiany pozwoliły zaoszczędzić 6912
bajtów, które zostały przeznaczone na buforowanie danych strumienia TCP.
Zmodyfikowany został plik synth.c tak, by wyjściowe próbki trafiały bezpośrednio do
przetwornika DAC.
4.4 Konfiguracja przetwornika cyfrowo-analogowego
W omawianym projekcie jako przetwornik cyfrowo-analogowy układ kodeka audio
TLV320AIC23B. Jego specyfikacja podana została w rozdziale 3. Konfiguracja te-
go układu możliwa jest zarówno poprzez interfejs SPI, jak i I2C. W realizowanym
programie postanowiono posłużyć się interfejsem I2C.
Adres urządzenia zależny jest od stanu logicznego na wyprowadzeniu CS. Molziwy
jest jeden z dwóch adresów. W omawianym projekcie na wspomnianym wyprowadze-
niu zapewniono stan niski. Moduł posiada zatem adres wyrażony binarnie: 0011010.
Konfiguracja odbywa się poprzez wpisanie wartości do odpowiednich rejestrów ste-
rujących.
Poniższa tabela przedstawia wykaz rejestrów kodeka TLV320AIC23B wraz z ich
adresami.
Tabela 4.2: Rejestry sterujące układu TLV320AIC23B[13]
Adres Rejestr
0000000 Regulacja wzmocnienia dla kanału wejściowego lewego
0000001 Regulacja wzmocnienia dla kanału wejściowego prawego
0000010 Regulacja wzmocnienia dla kanału wyjściowego słuchawek lewego
0000011 Regulacja wzmocnienia dla kanału wyjściowego słuchawek prawego
0000100 Rejestr sterujący połączeń analogowych
0000101 Rejestr sterujący interfejsem cyfrowym
0000110 Sterowanie trybem oszczędności energii
0000111 Konfiguracja cyfrowego interfejsu audio
0001000 Rejestr sterujący częstotliwością próbkowania
0001001 Aktywacja interfejsu cyfrowego
0001111 Rejestr resetu
32
W programie umieszczono funkcję zapisu wartości do rejestrów układu kodeka:
void TLV320 REG write ( u i n t 8 t reg , unsigned short va l ) {
u i n t 8 t buf [ 2 ] ;
buf [ 0 ] = ( ( reg << 1) | ( ( va l >> 8) & 0x01 ) ) ;
buf [ 1 ] = ( va l & 0xFF ) ;
I2CWrite (0x1A , buf , 2 ) ;
}
Trzeba zauważyć, że adres w przypadku interfejsu I2C zapisywany jest na siedmiu
bitach. Stąd potrzeba przesunięcia o jedną pozycję wartości reg w powyższym kodzie.
Jednocześnie wartości rejestrów zapisywane są na 9 bitach.
By zapewnić prawidłowe funkcjonowanie urządzenia dokonano zapisu odpowiednich
wartości omawianych rejestrów. W następnym listingu pokazano funkcję inicjalizu-
jącą pracę kodeka.
u i n t 8 t TLV320 Init (void ) {
TLV320 REG write (TLV320 REG RESET, TLV320 RESET ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG POWER, 0 << 1 ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG ANALOG, TLV320 DAC EN ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG DIGITAL , TLV320 DEEMP DIS | TLV320 DAC UNMUTE) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG INTERFACE, TLV320 MSTR | TLV320 DATLEN 16
| TLV320 DATFORM I2S ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG SAMPLERATE, TLV320 SAMPLERATE USB 44 ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG LHP , TLV320 L R SIM | (TLV320 HP VOLUME << 0 ) ) ;
de lay (0 x400000 ) ;
TLV320 REG write (TLV320 REG ACTIVATE, TLV320 ACTIVATE ) ;
I n i t I 2 S ( ) ;
return ( 0 ) ;
}
Pierwszym krokiem, jest zresetowanie układu, a następnie ustawienie pierwszego bi-
tu w rejestrze POWER. Następnie dokonano włączenia modułu przetwornika cyfrowo-
analogowego. W rejestrze REG DIGITAL wyłączono również jego wyciszenie. Re-
jestr REG SAMPLERATE odpowiada za częstotliowść próbkowania z jaką pracuje
przetwornik. Standardową wartością jest w tym przypadku 44100Hz. Nie jest to je-
dyna możliwa wartość. Dostępne są również 8kHz, 32kHz, 48kHz, 88kHz oraz 96kHz.
33
Rejestr REG LHP odpowiada za kontrolę poziomu sygnału na wyjściu analogowym.
Wartość TLV320 L R SIM oznacza, że zmiany następują od razu dla dwóch kanałów
i nie ma potrzeby ustawiania ich osobno. Poziom głośności jest regulowany w zakre-
sie -73dB (wartość 0110000) do +6.0 dB (1111111) w 79 skokach.
Ostatni zapis następuje do rejestru REG ACTIVATE. Wpisanie w ten rejestr war-
tości „1” powoduje aktywację układu.
Następna linijka to zainicjowanie interfejsu I2S. Układ TLV320AIC23B używa go
bowiem do wymiany danych z mikrokontrolerem. Kluczowymi przy tym są wartości
wpisane do rejestru REG INTERFACE.
Rejestr ten określa formę dostarczania/wysyłania danych. W naszym przypadku jest
to standardowy format I2S. Dane przyjmowane są 16 bitowe. Ważnym jest ustawienie
układu w trybie MASTER.
Sytuacja ta została zilustrowana na rysunku 4.3.
Rysunek 4.3: Diagram konfiguracji I2S - nadajnik jest w trybie slave[2]
W zaprezentowanym modelu układ mikrokontrolera, choć jest nadajnikiem jest usta-
wiony w trybie podrzędnym (SLAVE). Dzięki temu nie trzeba zapewniać wyprowa-
dzenia sygnału zegara (MCLK) do urządzenia odbiornika. Sygnały zegarowy (CLK)
oraz zmiany kanału (WS) są dostarczane do mikrokontrolera. Jedyne co jednostka
nadajnika musi zapewnić to wyjście danych (SDA). Taka konfiguracja jest w zało-
żeniu bardzo prosta. Poniższy listing przedstawia jej programową realizację (przy
użyciu biblioteki lpc17xx i2s oraz lpc17xx pinsel). Jest konfiguracja, którą wykonano po
stronie nadajnika, czyli mikrokontrolera.
I2S MODEConf Type I2S ClkConf ig ;
I2S CFG Type I2S Con f i gSt ruc t ;
PINSEL CFG Type PinCfg ;
PinCfg . Funcnum = 1 ;
PinCfg . OpenDrain = 0 ;
PinCfg . Pinmode = 0 ;
PinCfg . Portnum = 0 ;
34
PinCfg . Pinnum = 7 ;
PINSEL ConfigPin(&PinCfg ) ;
PinCfg . Pinnum = 8 ;
PINSEL ConfigPin(&PinCfg ) ;
PinCfg . Pinnum = 9 ;
PINSEL ConfigPin(&PinCfg ) ;
// I n i c j a l i z a c j a I2S − CLOCK & POWERI 2 S I n i t ( LPC I2S ) ;
//Ustawienia audio
I 2S Con f i gSt ruc t . wordwidth = I2S WORDWIDTH 16 ;
I2S Con f i gSt ruc t . mono = I2S MONO ;
I2S Con f i gSt ruc t . stop = I2S STOP ENABLE ;
I2S Con f i gSt ruc t . r e s e t = I2S RESET ENABLE ;
I2S Con f i gSt ruc t . w s s e l = I2S SLAVE MODE ;
I2S Con f i gSt ruc t . mute = I2S MUTE DISABLE ;
I2S Conf ig ( LPC I2S , I2S TX MODE, &I2S Con f i gSt ruc t ) ;
//MCLK PCLK i t p .
I2S ClkConf ig . c l k s e l = I2S CLKSEL FRDCLK ;
I2S ClkConf ig . f p i n = I2S 4PIN DISABLE ;
I2S ClkConf ig . mcena = I2S MCLK DISABLE ;
I2S ModeConfig ( LPC I2S , &I2S ClkConf ig , I2S TX MODE ) ;
// Bi t ra t e
LPC I2S−>I2STXRATE = 0x00 ;
LPC I2S−>I2STXBITRATE = 0x00 ;
I2S SetBitRate ( LPC I2S , 0 , I2S TX MODE ) ;
Problemem przy konfiguracji okazała się być ostatnia linijka powyższego kodu. We-
dług rysunku 4.3 należy uzupełnić rejestr I2STXBITRATE. Niestety w dokumen-
tacji nie było wzmianki by uzupełnić go zerami. Tylko przy takim ustawieniu kon-
figuracja działa.
W celu zapewnienia sprawnego zaopatrywania przetwornika cyfrowo analogowego
w dane, zestawiony został kanał DMA typu pamięć-urządzenie peryferyjne. Sku-
teczne ustawienie tego kanał wymaga wpisania odpowiednich wartości w rejestry
sterujące. Jednym z nich jest rejestr kontroli kanału (DMACCControl. Jego konfigurację
prezentuje poniższy listing.
Rozmiar określany w dokumentacji przez burst size to ilość danych przesyłanych
jednorazowo. Szerokość transferu po stronie odbiornika jak i nadajnika określona
jest poprzez parametry source/destination width. Ważne przy tym jest właściwe
skonfigurowania DMA dla trybu big endian lub little endian. Od tego zależy w jakiej
kolejności dane dotrą do celu. Bity 26. i 27. określają czy ma zachodzić inkrementacja
adresu źródła oraz celu. Ponieważ jak powiedziano transfer odbywa się w z pamięci
35
do urządzenia, należy ustawić jedynie 26. bit. Wpisanie wartości (1 << 31) włącza
przerwania dla momentu ukończenia transferu.
Drugim istotnym rejestrem sterującym jest DMACCConfig. Ustawienie (5 « 6) określa,
że celem przeznaczenia jest pierwszy kanał intrefejsu I2S. Wartość 11. bitu określa
typ transferu (binarnie: 000 dla Memory to memory DMA, 001 Memory to peri-
pheral DMA, 010 Peripheral to memory DMA, 011 Source peripheral to destination
peripheral DMA). Wyzerowanie wartości bitów 14. oraz 15. oznaczałoby ustawienie
maskowania przerwań DMA.
CLKPWR ConfigPPWR(CLKPWR PCONP PCGPDMA, ENABLE) ;
LPC GPDMA−>DMACConfig = 0x01 ;
NVIC DisableIRQ (DMA IRQn) ;
NVIC SetPrior ity (DMA IRQn, ( (0 x01 << 3) | 0x01 ) ) ;
LPC GPDMACH0−>DMACCSrcAddr = ( u i n t 3 2 t ) &DMASrc Buffer [ 0 ] ;
LPC GPDMACH0−>DMACCDestAddr = ( u i n t 3 2 t ) &(LPC I2S−>I2STXFIFO ) ;
LPC GPDMACH0−>DMACCLLI = ( u i n t 3 2 t ) &LLI0 ;
LPC GPDMACH0−>DMACCControl = ( ( DMA Buffer size ∗ 2) )
| (0 << 12) // source bur s t s i z e = 1
| (0 << 15) // de s t i na t i on bur s t s i z e = 1
| (2 << 18) // source width (18 − 20) = 32| (2 << 21) // de s t i na t i on width (21 − 23) = 32| (0 << 24) // source AHB s e l e c t (24)
| (0 << 25) // de s t i na t i on AHB s e l e c t (25)
| (1 << 26) // source increment (26) = yes
| (0 << 27) // de s t i na t i on increment (27) = no
| (1 << 3 1 ) ; // termina l count i n t e r r up t = yes
LPC SC−>DMAREQSEL = (0 x1 << DMA I2S REQ0 ) ;
LPC GPDMACH0−>DMACCConfig = 1 // channel enab led (0)
| (0 << 1) // source p e r i ph e ra l (1 − 5) = none| (5 << 6) // de s t i na t i on pe r i ph e ra l
| (1 << 11) // f l ow con t ro l (11 − 13) = mem to per| (1 << 14) // (14) = mask out error i n t e r r up t
| (1 << 1 5 ) ; // (15) = mask out termina l count i n t e r r up t
// Enable i n t e r r up t f o r DMA
NVIC EnableIRQ (DMA IRQn) ;
I2S DMAStruct . DMAIndex = I2S DMA 1 ;
I2S DMAStruct . depth = 7 ;
I2S DMAConfig ( LPC I2S , &I2S DMAStruct , I2S TX MODE ) ;
Kanał DMA został skonfigurowany dla docelowego urządzenia peryferyjnego, czyli
w tym przypadku kanału I2S. Źródłem danych jest lista łączona. Zawiera ona cztery
elementy, każdy zdolny przechować 576 bajtów. Ilość elementów bufora oraz ich
36
rozmiar zostały ustalone doświadczalnie.
Element takiej listy zdefiniowany jest następująco:
LLI0 . source = ( u i n t 3 2 t ) &DMASrc Buffer [ 0 ] ;
LLI0 . d e s t i n a t i o n = ( u i n t 3 2 t ) &(LPC I2S−>I2STXFIFO ) ;
LLI0 . next = ( u i n t 3 2 t ) &LLI1 ;
LLI0 . c o n t r o l = (1 << 26) | (1 << 31) | (2 << 18) | (2 << 21) | DMA Buffer size / 2 ;
Element LLI0.control ma takie samo znaczenie jak omawiany wcześniej rejestr DMACCControl,
tyle że w odniesieniu do konkretnego elementu listy. Pole next wskazuje następny ele-
ment. Ostatnia część listy w tym polu zawiera adres elementu LLI0.
Funkcjonowanie DMA w przypadku omawianego projektu opiera się na przerwa-
niach. Pojedyncze zgłoszenie przerwania następuje po ukończeniu transferu każdego
z elementów listy.
Schematycznie działanie tego mechanizmu ilustruje rysunek 4.4
Rysunek 4.4: Przetwarzanie danych przez kontroler DMA
Dekoder MP3 formując dane wyjściowe czeka na wystąpienie przerwania od ukończe-
nia danego elementu listy i wypełnia go danymi. W następnym kroku przetwornik
otrzymuje kolejne dane, aż do ukończenia i zgłoszenia przerwania. Sytuacja taka
cyklicznie się powtarza. Istotnym czynnikiem było odpowiednie dobranie rozmiaru
buforów, tak by przerwania nie były zbyt częste, a dźwięk z przetwornika był dobrej
jakości.
37
4.5 Obsługa programu
Uruchomienie programu jest proste. Wystarczy zasilić urządzenie oraz podłączyć
kabel LAN. Oczywiście by móc usłyszeć dźwięk należy zaopatrzyć się w słuchaw-
ki bądź głośniki z wtykiem typu JACK 2,5mm. Poniżej zaprezentowano diagram
rozmieszczenia elementów zastosowanej płyty ewaluacyjnej.
Rysunek 4.5: Elementy płyty ewaluacyjnej
Pole z numerem 1 to miejsce zasilenia płyty. Do tego celu należy użyć zasilacza
7 – 12V AC lub 9 – 15V DC, posiadającego standardowy wtyk o średnicy bolca
2.1mm. Alternatywnie możliwe jest wykorzystanie złącza USB oznaczonego nume-
rem 2. Złącza zasilające dla logki +3,3V oraz +5V zostały wyprowadzone na płycie
ewaluacyjnej.
Fragment rysunku o numerze 12 to zestaw ośmiu przycisków. Switch SW7 został uży-
ty do regulacji poziomu sygnału wyjściowego w dół, natomiast SW6 w dół. Kolejny
przycisk SW6 służy do przełączenia miedzy dostępnymi stacjami. Obok każdego
przycisku na płycie umieszczono diody LED. Te oznaczone numerami od LED7 do
LED4 wskazują obecnie ustalony poziom głośności. Dioda LED0 sygnalizuje pracę
urządzenia.
38
Numerem 5 oznaczono miejsce podłączenia interfejsu JTAG. Program umożlwia
również komunikację za pośrednictwem złącza RS-232. W celach diagnostycznych
można posługiwać się wypisywaniem komunikatów poprzez UART.
Numerem 7 oznaczono wejścia oraz wyjścia układu kodeka audio. Do wyprowadze-
nia oznaczonego etykietą OUTPUT należy podłączyć urządzenie wyjściowe. Warto
również uwzględnić przy tym konfigurację zworki oznaczonej symbolem HP/LIN.
Pozwala ona na przełączenie między wyjściem liniowym, a słuchawkowym. W przy-
padku tego pierwszego regulacja głośności jest niemożliwa.
Miejsce zaznaczone na rysunku numerem 19 to miejsce osadzenia minimodułu z ukła-
dem mikrokontrolera oraz interfejsem RJ45. Użyty minimoduł widnieje na poniż-
szym rysunku.
Rysunek 4.6: Minimoduł
Uwaga
W przypadku każdego urządzenia elektronicznego konieczne jest zachowanie pew-
nych zasad bezpiecznego użytkowania. Przed dotknięciem układu mikrokontrolero-
wego należy dotknąć uziemionego elementu metalowego. Płyta ewaluacyjna musi
zostać położona na powierzchni nieprzewodzącej. Należy dopilnować by na płycie
nie znalazł się żaden element metalowy mogący spowodować zwarcie. Wszelkich
zmian w połączeniach należy dokonywać przed włączeniem zasilania.
39
Rozdział 5
Ograniczenia techniczne
współpracy zastosowanych
urządzeń
Rozdział ten w założonej koncepcji ma stanowić kompendium wiedzy na temat po-
pularnych i mniej spotykanych problemów występujących w podobnych projektach.
Konwencja tego rozdziału nakazuje sformułować problem, a następnie podać jego
rozwiązanie. Nadmienić trzeba, że wiele z omawianych tu kwestii zostało zasygna-
lizowanych w rozdziale 4. Bieżąca część pracy skupiając się jednak wyłącznie na
sytuacjach problematycznych, może stanowić poręczne źródło informacji.
• Nie jest możliwe poprawne debugowanie programu. Niekiedy próbować trzeba
dwukrotnie. Program często kończy się w HardFault.
Rozwiązanie: Warto przeanalizować po kolei:
1. Połączenia i ustawienia sprzętowe
2. Zapisy w pliku konfiguracyjnym dla OpenOCD.
3. Ustawienia GDB
Kolejność czynności w tym przypadku jest ważna. Nawiązując do punktu pierw-
szego należy upewnić czy wyprowadzenia JTAG zostały połączone prawidłowo.
Zazwyczaj jednak ten problem jest oczywisty, gdyż interfejs nie działa. W przy-
padku omawianego projektu należał usunąć zworkę łączącą reset JTAG-a z re-
setem MCU. Punkt drugi mówi o sprawdzeniu konfiguracji OpenOCD. Wersja,
40
która była używana podczas realizacji pracy to wersja 0.4.0. W przypadku mi-
krokontrolerów lpc176x zawiera ona niepoprawny wpis. Poprawną konfigurację
przedstawiono w podrozdziale 3.2.
Częstym błedem jest eksperymentowanie z ustawieniami w Eclipse. Ustawienia
te sa bardzo proste, pod warunkiem, że punkty 1. i 2. zostały zrealizowane
prawidłowo.
• Brak współpracy z układem kodeka audio TLV320AIC23B.
Rozwiązanie: Wydaje się naturalnym, że nadajnik powinien być urządzeniem
nadrzędnym w stosunku do odbiornika. W ty przypadku jest jednak możliwe
by odbiornik pełnił rolę MASTER. Układ kodeka używamy wówczas w trybie
kompatybilności z USB. Ułatwia to w znacznym stopniu wyznaczanie często-
tliwości próbkowania oraz obsługę transmisji. W projekcie napotkano jednak
na problem - jeden z rejestrów musi być wypełniony zerami, choć z lektury
podręcznika użytkowania mikrokontrolera można odnieść inne wrażenie.
41
Rozdział 6
Podsumowanie
6.1 Możliwości i ograniczenia programu
Aplikacja obsługuje strumień multimedialny audio skompresowany za pomocą stan-
dardu MP3. Parametry danych wejściowych obsługiwane przez program to bitrate
128Kb/s mono lub stereo, częstotliwość próbkowania 44100Hz. Obsługiwane stacje
są na stałe wpisane w program. Przełączenia dokonuje się za pomocą klawiatury. Za
jej pośrednictwem możliwa jest również regulacja głośności. W programie zapewnio-
no dwa sposoby komunikacji z programem. Pierwszym jest zapalenie/gaszenie diod
LED. Drugim, pozwalającym na przekazywanie bardziej złożonych komunikatów jest
połączenie terminalowe za pośrednictwem interfejsu UART.
Posiadana płyta ewaluacyjna nie posiada wyświetlacza. Tym samym w omawia-
nym projekcie brakuje możliwości graficznej reprezentacji informacji na bieżąco, bez
użycia zewnętrznego sprzętu (zewnętrznego terminalu). Dlatego też w programie
nie zapewniono na przykład obsługi informacji ID31 dołączonych do odtwarzanych
mediów.
Z racji znacznego wykorzystania dostępnej pamięci RAM, konieczne było zreduko-
wanie liczby kanałów wyjściowych do jednego. Dźwięk odbierany z urządzenia jest
więc dźwiękiem monofonicznym. Z tego samego powodu wspomniany projekt zapew-
nia obsługę tylko plików MP3. Dołączenie biblioteki dla plików WMA wymagałoby
znacznie większej ilości pamięci.
1ID3 przechowuje dodatkowe informacje o pliku audio takie jak: tytuł, artysta, album itp.
42
6.2 Kierunek rozwoju aplikacji
Ponieważ opracowywany projekt jest dla autora ciekawym zagadnieniem, prace nad
jego udoskonaleniem będą trwały. Oto trzy cele, które zostały wyznaczone:
• udoskonalenie realizacji stosu TCP/IPv4 (implementacja protokołu DNS)
• zapewnienie interfejsu WWW do zarządzania urządzeniem
• dołączenie wyświetlacza LCD i obsługa informacji o strumieniu
W uznaniu autora opracowywany projekt jest udany. Co prawda, nie jest wolny
od ograniczeń i pewnych niedoskonałości, ale zapewnia zamierzoną funkcjonalność.
W toku dalszych prac, projekt zostanie udoskonalony.
43
Bibliografia
[1] “Dokumentacja helix mp3 decoder,” https://datatype.helixcommunity.org/
Mp3dec.
[2] “Dokumentacja mikrokontrolera lpc1769,” http://ics.nxp.com/support/
documents/microcontrollers/pdf/user.manual.lpc17xx.pdf.
[3] “Nota aplikacyjna układu dp83848,” http://openocd.sourceforge.net/doc/pdf/
openocd.pdf.
[4] “Nota katalogowa mikrokontrolera lpc1769,” http://www.nxp.com/documents/
data˙sheet/LPC1769˙68˙67˙66˙65˙64˙63.pdf.
[5] “Opis programatora-debuggera jtag,” http://www.freddiechopin.info/.
[6] “Projekt radia internetowego firmy watterott,” http://www.watterott.net/
webradio/arm-webradio-v3.pdf/.
[7] “Projekt winarm,” http://gandalf.arubi.uni-kl.de/avr˙projects/arm˙projects/
#winarm.
[8] “Specyfikacja biblioteki libmad,” http://www.underbit.com/products/mad.
[9] “Specyfikacja interfejsu I2C,” http://www.nxp.com/documents/other/
39340011.pdf.
[10] “Specyfikacja interfejsu I2S,” http://www.nxp.com/acrobat˙download2/
various/I2SBUS.pdf.
[11] “Specyfikacja mikrokontrolera lm3s6950,” http://www.ti.com/lit/ds/symlink/
lm3s6950.pdf/.
[12] “Specyfikacja układu kodeka tlv320aic23,” http://www.datasheetcatalog.org/
datasheet/texasinstruments/tlv320aic23.pdf.
44
[13] “Specyfikacja układu kodeka tlv320aic23 w języku polskim,” http://www-old.
wemif.pwr.wroc.pl/dsp/plik/LabPs˙AC23˙v2.pdf.
[14] “Specyfikacja układu vs1053,” http://www.vlsi.fi/en/products/vs1053.html/.
[15] “Strona główna projektu code sourcery,” http://www.mentor.com/
embedded-software/sourcery-tools/sourcery-codebench/lite-edition.
[16] “Strona główna projektu gnuarm,” http://www.gnuarm.com/.
[17] J. Bogusz, Lokalne interfejsy szeregowe w systemach cyfrowych. BTC, 2004.
[18] A. Grun, “Madplayer,” http://mbed.org/users/Gruenfrosch/programs/
madplayer/.
[19] P. Hadam, Projektowanie systemów mikroprocesorowych. BTC, 2004.
[20] NXP, “Realizing an mp3 player with the lpc2148, using libmad and efsl,” http:
//www.nxp.com/documents/application˙note/AN10583.pdf.
[21] Propox, “Dokumentcja techniczna minimodułu mmlpc1769-1-2-1-1,” http://
www.propox.com/download/docs/MMlpc176x˙pl.pdf.
[22] ——, “Dokumentcja techniczna płyty ewaluacyjnej,” http://www.propox.com/
download/docs/EVBmmTm˙pl.pdf.
[23] N. Semiconductor, “Nota aplikacyjna układu dp83848,” http://www.national.
com/an/AN/AN-1507.pdf.
45
Spis rysunków
1.1 Projekt firmy Watterott[6] . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Schemat blokowy układów serii LPC17xx[2] . . . . . . . . . . . . . . 11
3.2 Schemat blokowy minimodułu[21] . . . . . . . . . . . . . . . . . . . . 12
3.3 Konfiguracja GDB w Eclipse Helios . . . . . . . . . . . . . . . . . . . 15
3.4 Zakładka ustawień z komendami do GDB . . . . . . . . . . . . . . . . 16
3.5 Transfer danych poprzez interfejs I2C . . . . . . . . . . . . . . . . . . 17
3.6 Podstawowe możliwości konfiguracji interfejsu I2S[10] . . . . . . . . . 19
3.7 Transfer danych poprzez interfejs I2S[10] . . . . . . . . . . . . . . . . 19
4.1 Schemat blokowy układu testowego (znaczenie użytych symboli wy-
jaśniono w rozdziale 3) . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Przetwarzanie ramek Ethernet . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Diagram konfiguracji I2S - nadajnik jest w trybie slave[2] . . . . . . . 34
4.4 Przetwarzanie danych przez kontroler DMA . . . . . . . . . . . . . . 37
4.5 Elementy płyty ewaluacyjnej . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Minimoduł . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
46
Spis tabel
3.1 Dane mikrokontrolera LPC1769[4] . . . . . . . . . . . . . . . . . . . . 10
3.2 Parametry DAC układu TL320AIC23B[12] . . . . . . . . . . . . . . . 14
4.1 Wymagania Helix MP3 Decoder . . . . . . . . . . . . . . . . . . . . . 29
4.2 Rejestry sterujące układu TLV320AIC23B[13] . . . . . . . . . . . . . 32
47
Załączniki
1. Załącznik nr 1: Płyta DVD zawierająca: pracę w wersji elektronicznej, kod
źródłowy aplikacji, skonfigurowane środowisko oraz dokumentację.
48
Top Related