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: office@ics.p.lodz.pl

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