Při pokusech s audio výstupem na malých MCU existuje několik možností, jak zrealizovat D/A převodník. Velmi často používaný je PWM kanál, který spolu s dolní propustí dává poměrně poslouchatelné výsledky a je velmi levný. Pro kvalitnější výstup lze použít externí D/A převodník. Nabízí se zde sice nejeden převodník s paralelním vstupem, ale zabere příliš mnoho pinů (pro více než 8 bitů). Na relativně výkonných jednočipech AVR naštěstí lze provozovat i klasické audio D/A převodníky se sériovou I2S sběrnicí. Nejznámější typy, ketré nevyžadují MCLK jsou TDA1543 (I2S sběrnice) nebo kvalitnější TDA1545 (dle datasheetu "sběrnice kompatibilní s většinou japonských audio formátů: časový multiplex, TTL, dvojkový doplněk"). Oba lze získat i ze starých CD mechanik nebo přehrávačů. Existuje sice řada dalších typů, ale to jsou téměř výhradně "oversampling" převodníky, kde je potřeba nepřetržitě generovat MCLK (master clock), a hlavně odesílat data synchronně s ním na nějakém zlomku MCLK taktu. To je podle mého názoru zcela mimo možnosti AVR i jiných MCU, kde I2S sběrnice není řešena HW cestou. Naproti tomu dva výše uvedené typy se nechají krmit daty prakticky v libovolných intervalech. Je to skoro jako pracovat s běžným SPI D/A převodníkem. V kombinaci s vyrovnávací pamětí (FIFO) lze pomocí těchto převodníků získat kvalitní audio výstup při relativně malém vytížení AVRka.
TDA1543 je 16-ti bitový stereo D/A převodník. Výstupy jsou proudové, takže je třeba doplnit ještě převodník proud-napětí s dolní propustí. Maximální vzorkovací kmitočet je 192kHz, kmitočet hodin sběrnice I2S je až 9.2MHz (fungoval i na 10MHz). Převodník je napájen jediným napětím 5V (měl by jet i na 3V3), odběr je poměrně vysoký - asi 50mA.
|
Formát I2S sběrnice je naznačen v grafu. Jak je vidět, 16-ti bitový vzorek ve formátu dvojkového doplňku je odesílán od nejvýznamnějšího bitu (MSB first), data jsou čteny při vzestupné hraně hodin. Signál WS slouží k synchronizaci a multiplexování kanálů. Jeho hodnota se musí změnit vždy PŘED odesláním posledního bitu vzorku, což nepříjemně komplikuje emulaci. Na stejný kanál D/A nelze odeslat více vzorků po sobě.
TDA1545 je velice podobný předchozímu, ale mnohem kvalitnější (alespoň dle datasheetu :-). Může pracovat jen na 5V napájení a jeho odběr by měl být jen 6mA pro fullscale na obou výstupech. Má nižší zkreslení a nižší šum. Vzorkovací kmitočet může být až 384kHz, kmitočet hodin až 18.4MHz.
|
Vstupní formát zřejmě nemá žádný název. Dle datasheetu "kompatibilní s většinou japonských audio formátů: časový multiplex, TTL, dvojkový doplněk". Z grafu je vidět, že jde vlastně o identický formát, jako I2S, pouze WS signál pro multiplex kanálů je zpozděn o 1 clock - snáze se to realizuje.
Samotná emulace I2S je celkem k ničemu, pokud MCU musí audio data teprve od někud získat nebo
dokonce sám generovat. To zabere poměrně hodně strojového času. Často mnohonásobně víc,
než jedna vzorkovací perioda. V průměru sice audio signál musí být generován dostatečně rychle pro přehrávání na daném
vzorkovacím kmitočtu, ale
některé operace krátkodobě brání odesílání vzorků do D/A, což se podepíše na kvalitě výstupu.
Proto je třeba nějakým způsobem přenechat odesílání vzorků na přerušení procesoru, které může téměř libovolně a
hlavně pravidelně přerušovat vlastní generování signálu v hlavní programové smyčce. Je zřejmé,
že přerušení nemůže odeslat do D/A vzorek, který se právě počítá, případně ještě ani nezačal počítat.
Proto je třeba vytvořit vyrovnávací paměť, do které se v hlavní smyčce ukládají vypočítané vzorky maximální možnou rychlostí
a na druhé straně procesor přes přerušení tyto vzorky v pravidelných intervalech zase vyčítá a posílá do D/A převodníku.
Tímto jednoduchým postupem je zajištěno, že i když rychlost generování signálu kolísá, na D/A převodník data přicházejí pravidelně. Tedy
pokud se vyrovnávací paměť zcela nevyprázdní. Pak dojde k podtečení a opětovnému přehrání obsahu paměťi.
Popsaný druh paměti se jmenuje FIFO (First In First Out - první dovnitř, první ven). Častěji se označuje jendoduše jako buffer nebo marketingově třeba u discmanů jako "Antishock".
Konkrétně u přenosných CD přehrávačů je snaha vytvořit co největší FIFO nejen pro případ otřesů, kdy se audio poměrně dlouho přehrává jen z FIFO, ale
také kvůli spotřebě. Do FIFO se načte maximum a CD se může zastavit (především u MP3).
|
Zjednodušeně řečeno je audio FIFO "černou skříňka", do které jednou stranou ukládáme data v náhodných intervalech (pokud je v ní místo) a druhou stranou v pravidelných intervalech vybíráme. Toto platí pro případ D/A, ale samozřejmě to může fungovat i opačně. Třeba z A/D převodníku dostáváme pravidleně data a na výstupu FIFO je zpracováváme jak právě zbývá MCU čas. Zároveň je také zřejmé, že FIFO působí jako zpožďovací linka. Velikost zpoždění je přímo uměrná velikosti FIFO a nepřímo úměrna datovému toku skrz FIFO. To samozřejmě platí pro případ, že stav FIFO je více méně neměnný a téměř maximální. Obvykle toto proměnlivé zpoždění nepředstavuje problém.
|
FIFO buffery se sice vyrábí i jako samostatné obvody, ale pro tyto účely jsou nevhodné. Daleko častější jsou FIFO buffery vytvořené v RAM. Jde o velmi jednoduchý princip - vyhradí se potřebný úsek RAM a vytvoří se 2 pointery. Jeden pro zápis a druhý pro čtení dat. Takto vytvořené FIFO pracuje jako kruhový buffer. Jakmile kterýkoliv z pointerů přesáhne horní hranici vyhrazené paměti, resetuje se zase na její začátek. Banální, ale důležitou operací je zjištění volného prostoru ve FIFO. To lze provést prostým odečtením pointerů. V případě, že jejich pozice je taková, že vyjde záporné číslo, přičte se k němu velikost FIFO.
|
Jak jsem už naznačil v úvodu, AVR jsou dostatečně
výkonné, aby na vzorkovacím kmitočtu 22050Hz pseudo DMA výstup na tyto D/A zabíral jen asi 13% při taktu 16MHz.
Jako MCU jsem pro tuto ukázku zvolil můj oblíbený ATmega32. Nechtěl jsem zapojení nijak zvlášť komplikovat, takže audio není v žádné externí paměti, ale
přijímá se přes virtuální COM port realizovaný pomocí FT232. Navíc je zde doplněno LCD, ale není nutné ho připojovat. Zobrazuje mono/stereo a vzorkovací kmitočet. Navíc je zde rotační enkodér pro změnu vzorkovací frekvence.
V dolní části schématu jsou dvě varianty D/A převodníků. Jednak TDA1543 a pak TDA1545. Operační zesilovače mohou být napájeny klidně z +5V proti zemi - mělo by to být dostatečné.
|
K emulaci I2S jsem použil SPI interface taktovaný na maximálních 8MHz, takže odeslání jednoho bytu trvá jen 16 cyklů. Odesílá se vždy jeden stereo
vozrek najednou. Vlastní rutinu jsem vyřešil jako pseudo DMA. Je volaná timerem
2 nastaveným na vzorkovací kmitočet. Vzorky jsou odebírány z vyrovnávací paměti
nastavené na maximum co se vejde (1900B). Podtečení FIFO není nijak kontrolováno - při zastavení toku dat do FIFO se opakuje poslední úsek stále dokola.
Všechny operace jsem se snažil dostat do doby, kdy by MCU pouze čekal na odeslání jednotlivých bytů, takže je tato rutinka poměrně rychlá.
Navíc místo push/pop jsem použil in/out do nevyužitých registrů (mírné zrychlení). Přes preprocesor si lze vybrat variantu pro TDA1545 nebo TDA1543 a
variantu mono/stereo. V případě mono je vždy 1 vzorek odeslán na oba kanály a
ušetří se tak polovina paměti pro FIFO. Pak je zde ještě varianta, která
umožňuje přepínat mono/stereo za běhu programu pomocí proměnné I2Schannels. To
samozřejmě zabere pár cyklů navíc, ale je to ještě únosné.
Popsaná rutina je sice časově náročná, ale zdaleka ne nejkritičtější.
Tou je rutina pro příjem dat z USARTu. Datový tok PCM WAV, který
toto zapojení přehrává, je už poměrně vysoký, takže přenosová rychlost je
nastavena naplno - 2Mbit/s. To znamená příjem bytu každých 80 cyklů procesoru a
to už je docela extrém. Dostatečně rychlé zpracování se mi nepodařilo vyřešit v
hlavní programové smyčce, takže je řešeno přes RXC přerušení. Takže i příjem dat
je v tomto případě v podstatě pseudo DMA. USART je naštěstí na
přijímací straně vybaven hardwarovým FIFO na 2B dat, takže lze obsluhu přerušení pozdržet ostatními operacemi.
I tak ale musím v obsluze přerušení číst
2 byty najednou. Příjem dat z PC je pochopitelně bržděn HW řízením toku na
potřebnou úroveň. Signál CTS, který obvodu FT232 oznámí plné FIFO v MCU, je
ovládán v hlavní programové smyčce podle stavu FIFO. Jakmile ve FIFO zbývá
jen 32B volného místa, je vyslán signál k zastavení toku dat. FT232 může po tomto signálu poslat ještě 4B,
ale především programová smyčka může být blokována dalšími operacemi, takže proto 32B rezerva.
Povolení toku dat (CTS - Clear To Send) je obnoveno až při 48 volných bytech.
Aby toho nebylo málo, doplnil jsem ještě LCD pro zobrazování vzorkovacího kmitočtu a mono/stereo.
LCD dost dobře nelze ovládat kalsicky, protože obnovení 20 znaků zabre najednou 1ms, takže i toto je vyřešeno obnovením přes pseudo DMA.
Jakmile začnou přicházet data, MCU začne počítat byty. Až je příjmuto prvních 64B, pokusí se hlavní programová smyčka načíst z RIFF konzervy
PCM WAVu frame "fmt " a v něm identifikovat, zda jde skutečně o PCM WAV, nastavit vzorkovací kmitočet a počet kanálů. Vzorkovací kmitočet lze měnit i ručně
rotačním enkodérem v rozsahu 8kHz až 48kHz. 1s po dokončení přehrávání
by měl vypršet timeout a MCU reinicializuje přehrávání.
Zdroje a bin.
|
Jednoduchý ovládací prográmek můžete stáhnout
zde. V ini souboru
je třeba nastavit číslo portu, kde je připojený FT232 převodník. V ovladačích
virtuálního COM portu je ještě vhodné nastavit latency na 2ms (nebo 1ms na strojích od 1GHz - na pomalejších dojde spíš ke zpomalení toku dat).
Otevřít by měl jít libovolný soubor, ale bezpečně přehrát lze jen 16bit PCM WAVy
8-48kHz. Pokud je nějaká zrada v HW zapojení, měl by vypršet timeout, takže program snad nevytuhne
(to by se při HW řízení toku mohlo snadno stát).
Celkem milé překvapení pro mě bylo, když jsem zjistil, že i na postarším
P3 600MHz přenos jede tak rychle, že nedojde k žádným podtečením FIFO až do kvality výstupu
47500Hz 16bit stereo. Stačí ovšem pohnout myší a už je slyšet podtečení FIFO v podobě lupnutí.
Na rychlejších strojích jede přenos nadoraz - 48kHz 16bit stereo a XP si poradí
i s další zátěží bez podtečení FIFO. Tomuto formátu odpovídá datový tok
192kB/sec což je 96% z teoreticky maximálních 200kB/sec (2MBd, 10bit rámce) a to je docela slušný výsledek :-).
Protože jsem se nedávno konečně dokopal dělat něco na AVR i v C,
rozhodl jsem se, že tohle by mohl být dobrý testovací prográmek, kde si ověřím,
jak moc neefektivní AVRGCC je.
Jedná se o prakticky identický program, jako je minulý příklad v assembleru, pouze je napsán v C a
místo LCD používá výstup na libovolný terminál. Odstranil jsem rovněž enkodér (nemám žádný po ruce). Protože můj prastarý
ATmega32 už jsem někde využil, použil jsem tentokrát ATmega644-20. Je stále v DIL40, má dvakrát větší RAM a snese vyšší takt.
Prográmek by měl být schopen přehrát libovolný PCM wave se vzorkováním do 44.1kHz (8/16 bit, mono/stereo). Stream je
přenášen opět přes FT232 nebo nějakou obdobu na taktu 2Mbd (bez parity, jeden stop bit) libovolným terminálem s podporou
CTS řízení toku (odchozí data). Použít lze i výše uvedený prográmek, což je vlastně také terminál, ale nebude samozřejmě vidět textový výstup.
|
Formát je rozpoznán automaticky z RIFF konzervy a pokud není podporován, měla by být vypsána chyba a zbytek toku bude ignorován. Problém s identifikací by mohl nastat u WAV souborů, kde je "data" subchunk v souboru za hranící 0x0078. To je sice vzácná situace, ale stát se to může. Někdy jsou totiž v souboru i tagy a občas bohužel i na začátku. Program je vybaven i timeoutem, takže pokud terminál déle než cca 750ms neodešle data, bude přehrávání ukončeno. Prográmek jsem tentokrát navíc vybavil počitadlem bytů, takže po příjmu posledního bytu vlastních audio dat ("data" subchunk RIFF konzervy) je audio FIFO naplněn nulami. Tím by se mělo přehrávání nehlučně ukončit a zbytek streamu (obvykle "LIST" subchunk), bude ignorován.
|
Dle očekávání je sice GCC v porovnání s assemblerem (mým assemblerem :-) citelně pomalejší, ale ne zase nějak nepřekonatelně. Zpravidla se
překladači dalo rozumným přeskládáním kódu a změnou zápisu pomoct alespoň k trochu rozumnému výstupu. Pochopitelně samotná
I2S rutina musela zůstat v assembleru jednak kvůli přesnému časování a pak samozřejmě i kvůli efektivitě. Vzhledem k tomu, že
I2S výstup přerušuje příjem dat, tak každý cyklus navíc zvyšuje šanci, že dvou bytový USART FIFO, kterým je AVR na příjimací straně vybaveno, přeteče.
Překvapivě to tentokrát šlo i bez příjmu dat v přerušení. Sice opět musím zkoušet vyčíst druhý byte zkrácenou cestou, ale nepostřehl jsem, že
by to přeteklo, takže to asi bude OK.
Projekt ke stažení: zdrojáky a překlad pro TDA1543,
zdrojáky a překlad pro TDA1545.
Když jsem před pár lety prvně použil Keil C51, tak jsem se ho naučil používat celkem rychle (můj první vyšší jazyk pro jednočipy).
Rozhodně jsem nenarazil na obtíže s optimalizacemi a spol. Stačilo správně používat "volatile".
Předpokládal jsem, že s GCC to nebude nijak výrazně složitější, ale bohužel je.
Z toho důvodu jsem se rozhodl shrnout pár poznatků z práce na tomto mini projektu. Pro toho, kdo s GCC už pracuje jistě žádné
překvapení, ale začátečníkům, jako jsem já, by se to mohlo hodit.
Předně jsem s tímto triviálním programem narazil u assembleru. Sice jsem samozřejmě věděl,
že GNU-as je s AvrAsm32/2 a jeho obdobami nekompatibilní, ale měl jsem za to, že většinu problémů vyřeším pomocí pár maker.
To bylo ode mne skutečne hodně naivní. :-)
Téměř neřešitelným problémem se ukálala být zejména assemblerovská makra. Kdo se už někdy
vrtal v mých novějších zdrojácích pro AVR ví, že používám desítky maker pro práci s vícebytovými proměnnými, kde se udává pouze první
registr ze skupiny a zbytek už řeší makro. Dost to zpřehledňuje kód. Např.:
... .def R16H=R17 .def R16B3=R18 .def R19H=R20 .def R19B3=R21 ... .macro addt add @0,@1 adc @0H,@1H adc @0B3,@1B3 .endm addt R16,R19
Bude automaticky rozvinuto do:
add R16,R19 adc R17,R20 adc R18,R21
Bohužel chtít něco takto jednoduchého po GNU-as se ukázalo jako téměř neřešitelný problém. Už jsem to skoro chtěl vzdát, ale naštěstí jsem byl na fóru odkázán na nějaký *.h soubor z LibC, kde bylo toto řešeno iterační metodou. No ... málem jsem z té překomplikované hrůzy spadl ze židle, ale pak mi došlo, že to asi jinak nepůjde, takže problém jsem vyřešil takto:
.macro addt ra,rb
.findreg_ra=-1
.findreg_rb=-1
.findreg_cnt=0
.irp regn,R0,R1,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11 \
R12,R13,R14,R15,R16,R17,R18,R19,R20,R21 \
R22,R23,R24,R25,R26,R27,R28,R29,R30,R31
.ifc \regn,\ra
.findreg_ra=.findreg_cnt
.endif
.ifc \regn,\rb
.findreg_rb=.findreg_cnt
.endif
.findreg_cnt=.findreg_cnt+1
.endr
add (.findreg_ra),(.findreg_rb)
adc (.findreg_ra)+1,(.findreg_rb)+1
adc (.findreg_ra)+2,(.findreg_rb)+2
.endm
Vypadá to hrozně a o rychlosti překladu při delším zdrojáku raději nepřemýšlím, ale alespoň to funguje.
Smysl onoho kódu je iterační cestou přes ".irp" direktivu identifikovat pořadové číslo registru. AVR verze překladače naštěstí akceptuje
nejen názvy registrů, ale i jejich pořadová čísla, takže dále už to bylo snadné (jednoduché řesení R16+n bohužel použít nelze).
Pochopitelně to bylo potřeba provést se všemi makry, takže jsem k převodu mých starých maker napsal prográmek, který třeba časem zveřejním.
Převedená makra jsou součástí projektu, takže pokud má někdo zájem, lze použít, ale netestoval jsem rozhodně všechny.
Pokud jde o assembler tak už se vyskytly jen kosmetické problémy, jako že low(), high() a spol. nejsou definovány, že adresy skoků se
udávají v bytech místo ve wordech, že místo PC se používá ".", ale s tím háčkem, že ukazuje o jeden word vpřed oproti PC v AvrAsm32/2 atd.
[rejp] Na to jak se všichni všude můžou přetrhnout sdělováním, jak je GNU-as mocný, výkonný a nepřekonatelný nástroj jsem narazil na věci, co prostě jednouše neudělám trochu moc brzo. Na to já mám holt talent. :-D [/rejp]
V C-čkové části programu jsem narazil především na typické obtíže s optimalizacemi. Např. jsem si naivně myslel, že když použiji následující kód:
volatile uint8_t *rd; cli(); rd=FIFOrd; sei(); // calc free space int16_t n=rd-FIFOwr; if(n<0) n+=FIFOsize;
tak i po optimalizaci dostanu něco jako:
lds R22,FIFOwr lds R23,FIFOwr+1 ... cli lds R24,FIFOrd lds R25,FIFOrd+1 sei sub R24,R22 sbc R25,R23 brcc .+4 subi R24,lo8(-FIFOsize) subi R25,hi8(-FIFOsize)
Jo, to byla zase naivita. :-) Optimalizátor s klidným svědomím vygeneroval zhruba toto:
lds R22,FIFOwr lds R23,FIFOwr+1 ... lds R24,FIFOrd lds R25,FIFOrd+1 sub R24,R22 sbc R25,R23 sbrs R25,7 rjmp .+4 subi R24,lo8(-FIFOsize) subi R25,hi8(-FIFOsize) ... cli sei
Ano, tam je mi to zablokované přerušení skutečně hodně platné. Vyřešil jsem teprve až po "konzultaci" s "atomic.h":
volatile uint8_t *rd;
asm volatile("cli" ::: "memory");
rd=FIFOrd;
asm volatile("sei" ::: "memory");
// calc free space
int16_t n=rd-FIFOwr;
if(n<0)
n+=FIFOsize;
Parametr "memory" zjevně překladač nutí provést kód přesně tak,
jak je - zakazuje mu "vyoptimalizovat" načtení sdílené proměnné "FIFOrd" někam jinam. Sice jsem měl za to, že to platí jen uvnitř jednoho asm() bloku,
ale asi to funguje i takto. Alternativně (a možna i přednostně) lze
použít makro ATOMIC_BLOCK() z "atomic.h". Vypadá to pak trochu čitelněji a zřejmě je to pak i multiplatformní.
Další poznatek ohledně optimalizátoru byl, že je VELMI špatný nápad používat globální proměnnou uvnitř nějakého algoritmu.
Překladač má pak tendenci do ní stále ukládat mezivýsledky, přesto že není typu "volatile". Z toho důvodu se vyplatí vytvořit si na začátku
algoritmu lokální kopii, která s trochou štěstí zůstane v registrech a na konci ji zase přiřadit
zpět do globální proměnné. Tohle dost zefektivnilo kód prakticky všude. Sice to vypadá trochu neelegantně, ale
než předávat hafo parametrů sem a tam, tak už raději tohle.
Dále jsem byl trochu na nervy z toho, že linker používal stále absolutní skoky a volání, ale bylo mi na fórech porazeno, že k tomu
slouží parametr "-Wl,--relax" a skutečne to funguje (nečekaně).
Kde to šlo, tam to linker zkrátil na relativní a hned bylo kódu výrazně méně.
| Poslední aktualizace: 11.2.2012 |  |
 |