logo_elektromys.eu

/ Rychlejší DAC na STM32 |

/ Motivace |

V řadě projektů s STM32 využívám vestavěný DAC. Jeho parametry nejsou nijak oslnivé a na "precizní" práci se nehodí. Ale pro některé pomocné úlohy jako třeba nastavování komparačních úrovní pro rychlé externí komparátory jsou přesné víc než dost. Dokonce úspěšně slouží jako generátory signálu pro buzení elektromagnetů v měřicích aplikacích. Dá se tedy říct, že DAC není úplně k zahození a možná by nebylo od věci vyvinout trochu úsilí a jeho parametry mírně zlepšit.

/ Appnote |

Nebudu ztrácet čas a rozkecávat se o DAC obecně, neboť to už udělali jiní a lépe. Taktéž nebudu zabředávat do specifik DAC na STM32F3, neboť to jsem již udělal v dřívějším příspěvku. Jediné co si vyzkoušíme bude návod z appnote AN4566 - Extending the DAC performance of STM32 microcontrollers. Když to zestručním tak se v ní tvrdí, že úzké hrdlo DA převodníku je výstupní buffer. Limituje minimální a maximální výstupní napětí (tedy okrádá vás o část rozsahu) a rychlost přeběhu. Samozřejmě použitím bufferu něco získáte. A to relativně nízkou výstupní impedanci (dle datasheetu je výstup při zachování dané přesnosti ochoten dodávat proud až 0.6mA, případně odebírat proud něco přes 0.1mA). Tím se ale zmiňovaná appnote nezabývá. Vysvětluje jak lze pomocí externího operáku citelně zvětšit rychlost přeběhu a spolu s tím se ještě zbavit omezování min. a max. výstupního napětí. Protože mám bláhový dojem, že by se mi to mohlo někdy hodit, rozhodl jsem se appnote vyzkoušet a při té příležitosti vás s výsledky seznámit. Na tomto místě bych zkušenějším uživatelům doporučil neplýtvat svým časem, prolétnou očima appnote a věnovat se něčemu zábavnějšímu. Nic převratného totiž předvádět nebudu.

/ Hardware |

Kvalitní zpracování tohoto tématu by si zasloužilo vyrobit pro obvod vlastní DPS a ideálně zvolit i čip ve větším pouzdře se samostatně vyvedeným VREF+. To mi ale přišlo jako příliš mnoho práce, takže celý test provedeme na Nucleo kitu a v nepájivém poli. A myslím že i přes to vše bude pozitivní výsledek dobře patrný. Test jsem provedl na Nucleo kitu STM32F303K8 protože jich mám prostě hodně. O něco zajímavější by to asi bylo na některé STM32F4 a úplně nejzajímavější asi na STM32H7, protože tam bychom mohli překročit 10Msps (tedy 10x víc než uvádí datasheet jako maximum). Přejděme ale k věci. Appnote nás nabádá abychom na výstupu DAC vypnuli buffer a s využitím vnitřního odporu a externího OZ sestavili v podstatě diferenciální zesilovač. Ten totiž umožní udržet výstup DAC z čipu na konstantním napětí a eliminuje tím nabíjení a vybíjení parazitních kapacit. Ty totiž spolu s výstupním odporem (až 15k) nebufferovaného DAC tvoří filtr, který imituje rychlost přeběhu. V této konfiguraci ho limitovat nebudou. Drobné úskalí je ale volba zpětnovazebního odporu. Pokud neznáme výstupní odpor DAC, nemůžeme ho přímo spočítat. Nabízí se tedy buď výstupní odpor změřit a nebo aplikaci vybavit trimrem a nastavit jeho hodnotu podle potřeby. Já sáhl po trimrech. Navíc jsem se rozhodl napájet OZ symetricky a vytvořit rovnou bipolární výstup (protože to v podstatě nevyžaduje žádnou úpravu schematu z appnote - až na změny hodnot odporů). Schema tedy vypadá následovně.

Schema zapojení. DAC je výstup z DA převodníku (PA5), VREF je referenční napětí pro DAC (na Nucleo kitu vlastně VDD).

Na malém čipu F303K je referenční napětí pro DAC/ADC (VREF) spojeno s VDDA a je v našem případě 3.3V. Signál DAC přivedeme z druhého kanálu DAC1 (DAC1_OUT2). Díky tomu nám zůstane první kanál (vybavený bufferem) volný abychom mohli porovnávat vnitřní a vnější buffer. Pokud se ztrácíte v tom který kanál DAC je jak vybaven, projděte si poznámku v předchozím dílu. Volba operačního zesilovače byla limitovaná domácí zásobou. Evergreeny jako LM358, LM324 nejsou dost rychlé. Jediný další kus co jsem doma našel je LMH6612. Jeho volba tedy není promyšleným krokem a na celou práci by jistě stačil "operák" o řád pomalejší. Naopak jeho použití přináší další nadbytečné komplikace. Jednou z nich může být nutnost vypořádat se s velkým vstupním proudem (typ. 6uA), který by zaváděl značný offset. Což jsem si pro účely demonstrace dovolil ignorovat. Zpětnovazební kondenzátor CFB jsem zapojil kvůli obavám z rozkmitání. Nakonec se ukázalo že byl OZ stabilní i bez něj. Výsledky naměřené bez něj budou mít tuto informaci v komentáři. Na Nucleo kitu využívám jako zdroj clocku 8MHz signál z ST-linku (spojený jumpr SB4). Clock vede na pin PF0 a pokud nerozpojíte jumper SB6 tak vede i na vnější konektor (pin D7) a může nepříjemně zarušit signál z DAC. Pro tyto účely jsem tedy SB4 rozpojil.

Foto zapojení aneb jak to nedělat

/ Software |

Na softwaru nebude nic převratného a protože o něj tu teď nejde, dovolím si zdrojový kód zveřejnit jen jako odkaz na konci článku. Program obdobný jako v již zmiňovaném předchozím díle. DAC1 pracuje v duálním 12bit režimu, tedy převádí oba kanály zároveň. K tomu potřebuje krmit 32bit daty o což se stará jeden DMA kanál. Okamžik převodu je řízen pomocí TIM7. Kanál 1 má zapnutý buffer a slouží pro srovnávání. Kanál 2 buffer vůbec nemá a jeho výstup ženeme do našeho zapojení. Protože naše zapojení invertuje, posílám do obou kanálů odpovídajícím způsobem "převrácená" data. Díky tomu můžeme sledovat "stejný" výstup. Srovnávací průběh má jen dvě hodnoty, maximum (4095) a minimum (0). Z takové skokové se funkce bude nejlépe odečítat rychlost přeběhu. Ve druhé ukázce pak průběh upravím na schodovitou funkci (17 schodů). Změnou parametrů TIM7 je možné ladit tempo převodů. Dle appnote lze dosáhnout maximálně 4.5Msps, víc sběrnice běžící na 36MHz nedovolí, což jak brzy uvidíte je pravda (v tom by byla zajímavější právě volba čipu F4 nebo H7). Pojďme se tedy podívat jak vypadá výstup.

Celkový pohled na výstupy při 100ksps s CFB=3pF.
Žlutý průběh je výstup našeho OZ. Modrý průběh je z kanálu1 vybaveného vnitřním bufferem. Červená stopa je výstup z nebufferovaného kanálu. Na průběhu je několik zajímavých jevů, které si zaslouží komentář v textu.

První co vás praští do očí je znatelné zpoždění (1.5us) modrého signálu. Vnitřní buffer jak vidno reaguje opožděně. Nejprve jsem se domníval, že dělám nějakou chybu při nahrávání dat do DAC. Zkusil jsem tedy buffer na kanálu 1 vypnout a zpoždění zmizelo. Je to tedy vlastnost bufferu. Další nepříjemností je hrb na žlutém průběhu. Jakmile se dá výstup 1.kanálu (s vnitřním bufferem) do pohybu, vzniká nám, nejspíše skrze parazitní kapacity, značný přeslech. Tajně doufám, že to je pouze chybou layoutu a že nějaký přeslech nevzniká i uvnitř čipu. Následující dva oscilogramy ukazují značný rozdíl rychlosti přeběhu. Vnitřní buffer zvládá přibližně 2V/us, výstup operačního zesilovače okolo 30V/us. Podotýkám že toto měření mělo zapojený CFB (3pF).

Detail vzestupných hran
Detail sestupných hran

Na dalších oscilogramech si můžete prohlédnout upravenou situaci. Vypnul jsem "rušivý" první kanál a odpojil kondenzátor CFB. Přeslech v podobě nepříjemného hrbu zmizel a doba přeběhu se ještě citelně zkrátila.

Detail vzestupné hrany. CFB odpojený, rušivý kanál s bufferem vypnutý.
Detail sestupné hrany. CFB odpojený, rušivý kanál s bufferem vypnutý.

Na závěr si dovolím ještě prezentovat výsledek s DAC běžícím na "plný" výkon. DAC generuje schodovitý průběh s taktem 4.5Msps. Na prvním oscilogramu s vypnutým 1.kanálem. Na druhém oscilogramu je 1.kanál pro srovnání zapnutý (a kazí žlutý průběh). Je vidět, že vnitřní buffer vůbec nestíhá. Vlnky patrné na červeném kanále vznikají zpožděnou reakcí OZ a trvají do té doby než OZ nastaví na svém výstupu odpovídající úroveň. Jejich přítomnost naznačuje že by bylo možné pracovat ještě rychleji.

Schodovitá funkce přes celý rozsah při 4.5Msps.
Schodovitá funkce přes celý rozsah při 4.5Msps. Srovnání interního (modrá) a externího bufferu (žlutá). Funkce se skládá ze 17ti schodů. Její frekvence 264.7kHz prozrazuje že DAC musí pracovat na 264.7*17 = 4.5Msps.

| Závěr /

Z ukázky je zřejmé, že DAC má slušný potenciál pro zlepšení. Zřejmé je ale i to, že to nebude bez práce. Přeji příjemné bastlení.

| Odkazy /

Home
| V1.00 19.5.2019 /
| By Michal Dudka (m.dudka@seznam.cz) /