Názory k článku Architektura mikrořadičů s jádry ARM Cortex-M3
-
klusacek (neregistrovaný)
Jen pro uplnost: Chapu to dobre ze M3 pro mod preruseni nema dedikovane registry takze sice se do prerusovaci rutiny dostanu za takt ale nez pak ulozim registry a nactu do nich promenne tak stejne tak nejaky ten takt ztranim?
Jeste mi neni jasne jak je zajistena prerusitelnost LDM a STM. To ma procesor ve stavovem slove jeste nejake bity ze kterych pak po navratu (a obnoveni stavu) zjisti kde ma pokracovat?
Nebo se to dela jako s nasobenim ze se rozpracovana instrukce zahodi a pote spusti znovu? To by ale znamenalo ze treba STM nesmim pouzit pro zapis dat do periferie, protoze by to opakovani mohla spatne pochopit.
-
Pavel Píša (neregistrovaný)
U LDM a STM si myslím/jsem si téměř jistý, že se provede znova. Určitě to není jako na m68k10+/CPU32, kde se ve stavovém slovu ukládá bitmapa rozpracovaných registrů. LDM a STM se nesmí použít pro přístup k periferiím, kterým zopakování vadí. Zároveň mnoho ARMů již od ARM920TDMI obsahuje errata, kdy LDM bez zapnuté cache za určitých specifických okolností může selhat. Je zajímavé, že problém se myslím táhne až ke Cortexům-A.
Co se týče přerušení, tak Cortex-M provede uložení stavu na zásobník příslušný přerušovanému/původnímu režimu běhu (viz minulá diskuze o nemožnosti implementace stránkování i kdyby byla MMU). Dedikované shadow registry nemá. Do link registru se uloží speciální návratová adresa, samá F a na konci info o přerušeném režimu. Zároveň na zásobník se ukládají i ty registry, které jsou podle Thub-2/EABI clobbered/clobberable. Výsledkem je příjemné zjednodušení, že obsluhu přerušení lze psát jako běžnou C funkci. Normální pokus o návrat, přiřazení speciální hodnoty 0xffffff.. do PC vede k spuštění sekvence operací vedoucích k nastolení stavu CPU před přerušením. Málem by člověk řekl, že na drese 0xffffff.. je kousek ROMky, který tu sekvenci LDM s vyzvednutím stavu provede, ale přímo takto to nebude, je potřeba dekódovat tu stavovou část. Ale určitě je "mikrokód"/stav dekodéru isntrukcí, který operaci zápisu speciální hodnoty do PC na LDM převede,
Co se týče rychlosti, tak jsem prezentace jak je to extrémně rychlé někde viděl, je možné, že do taktu se začne přerušení řešit, ale ukládání bude trvat celkem dlouho a pokud zrovna cache (u M7 myslím může být) nebo akcelerátor (cache) na úrovni Flash nebo řadiče externí paměti nemá potřebnou polužku VIM tabulky a kód zapamatovaný z minule, tak to zase hezkou řádku cyklů přidá. Mimochodem, cachování na úrovni řadiče SDRAM se mi na NXP LPC docela líbí. Tím, že je to až na hranici čipu, tak i vnitřní periferie a DMA vidí obsah paměti přes cache, využijí burst načítání a nemusí se řešit koherence, ale je to jen 16x16 byte a dobré pouze pro malé čipy. Na velkých je naopak při více jádrech nebo opravdu rychlých koprocesorů nutné dostat cache (alespoň L1) přímo k jádrům, aby se snížila zátěž sběrnic.
-
Pavel Píša (neregistrovaný)
Silicon Errata to MC9328MXS
Modules: ARM920T AHB Wrapper
Failure: LDM instruction fails to load non-cached data from memory.Errata k Ti embedded chipu
ARM Core
Cortex-M3 / Cortex-M3 with ETM (AT420/AT425)
Errata Notice
382859: Secondary interruption may corrupt ICI continued Thumb-1 LDM with base-in-list.Chip Errata for the i.MX 6Dual/6Quad
IMX6DQCE Rev. 5, 06/2015 ERR003730 ARM: 743623—Bad interaction between a minimum of seven PLDs and one Non-Cacheable LDM can lead to a deadlockJsem si téměř jistý, že jsem podobné problémy viděl v Erratech i když jsme vyvíjeli systém s iMX53 a dalšími. Obecně LDM z periferií a před tím, než je zapnutá cache tak i z hlavní paměti může mít za určitých podmínek problémy. Přímo jsem žádné naše problémy na tento mapovat nedokázal, ale je to věc souběhů často s takovými pravděpodobnostmi, že je to problém odchytit. Určitě použití LDM do periferií bych nedoporučoval.
-
klusacek (neregistrovaný)
Diky za odkaz. To je tedy prekvapeni. Celkove jsem zatim ARM povazoval za celkem cisty a spolehlive navrzeny procesor. Zajimalo by me jestli za to muze nekdo z vyvojaru ARMu, ze to spatne vymyslel, nebo jestli je to zpusobeno temi pridanymi periferiemi od FreeScale.
Jinak jsem si ted znovu osvezil ARM7TDMI technical reference a ARM v5 architecture reference manual a tam o LDM/STM do periferii normalne mluvi, jen se nesmi nacitat pres hranici 1KB, coz nejak souvisi s velikosti stranek pameti (kdyby jedna stranky byla cacheable a druha ne tak neni specifikovano poradi). Ale tak vetsina periferii stejne neni namapovana, takze to nevadi.
-
Petr (neregistrovaný)
LDM/STM (a IT) ma stavove bity v EPSR, po navratu z preruseni se pokracuje tam, kde se prestalo
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/ch02s03s02.html
-
Petr M (neregistrovaný)
"Atmel vyniká i v implementaci periferních zařízení, které jsou pro mikrořadiče většinou nezbytné."
Jo, periferie mají vymyšlený hezky. PDC, event systém,... Jenom je tam vždycky nějaký "detail", kterým to totálně podělají. Za ty roky jsem se stal nedobrovolným sběratelem jejich přešlapů...
To pak člověk čte v dokumentaci takový perly, jako "TWI interface on port E is not connected to pins. Do not use it."
Nebo navrhne power management podle app notes a kouká, že se to probouzí místo 4,5us celých 487ms, protože někdo připojil čítač pro start up delay na jiný hodinový signál a tesťáci si toho náhodou nevšimli... Dva měsíce trvalo, než mě to uvěřili.
A ta ostuda s JTAGSEL u AT91SAM926x.
Nebo padání chip selectu na SPI u SAM7 při použití PDC.
Nebo ... Mám toho tady za ty roky asi pětistránkový seznam a neměl jsem v rukách procesor od Atmelu, který by dělal přesně to, co bylo popsáno v dokumentaci a dodržel při tom (často nekompletní) elektrický specfikace a časování.
Takže Atmel mám na gray listu. Pokud na něm zákazník explicitně trvá, dostane ho. Ale pokud je to novinka, připočítávám si k projektu čas, zbývající do 36 měsíců na trhu pro ladění BSP a dvě kola HW (1. kolo na přepojení nefungujících periferek, 2. kolo ladění analogu, oscilátorů a napájení). S tím, že je upozorněn na riziko toho, co nedávno nastalo s XMEGA A rev. J...
-
Petr M (neregistrovaný)
Standardní Atmelovina. Změnili specifikaci produktu a nedali to na web. FAE o ničem nevěděl a byl velmi překvapený, když zjistil, že revize J existuje a navrhl jako řešení kupovat starou revizi. Obchodníci se nám vysmáli, že stará se už nevyrábí a neprodává.
Musel jsem se vrátit ke starýmu projektu a dva měsíce ladit a testovat, protože např. A/D převodník úplně umrtvili (změna frekvencí, vyhození jednoho ze dvou kalibračních registrů, vyletěl offset a podstatně horší linearita).
Mimo to rozsekali ještě další periferky, jako brownout apod.
Čímž se XMEGY dostaly z gray listu na black list.
-
klusacek (neregistrovaný)
Mam s Atmelem velmi podobne zkusenosti. Pouzivam SAM7 a nekolik let mi trvalo nez jsem naprogramoval vsechny mozne workaroundy aby se dal vubec pouzivat.
Napriklad ten jejich ADC -- nejenze je spatne vymysleny a inicializovat ho tak aby pak bezel synchronne s CPU clockem a nemel vzhledem k nemu jitter je netrivialni, ale kdyz to clovek napise v assembleru a diky tomu do registru zapisuje prilis rychle po sobe a je vybran kanal 1 tak to pak na zacatku blbe zapina multiplexer a v dusledku toho nakonec misto <ch1> <ch2> <ch1> <ch2> vam DMA nacpe do pameti <?> <ch1> <ch2> <ch1> <ch2>, takze se hodnoty o 1 posunou coz je velmi prijemne napriklad pokud ch1 je napeti a ch2 proud. Staci dat na vhodne misto 2 NOPy a nedela to.
A mimochodem taky mi to neverili. Jsou to tak trochu amateri.
Pak jeste nekolik designovych nesmyslu: Treba zrovna to DMA (jimi zvane PDC) neni uplne spatne ale mohlo byt udelano lepe, kdyby ty prerusovaci bity po dojeti bufferu byly pro vsechny periferie na stejnem miste relativne k PDC registrum. Takhle kdyz napisu genericke rutiny pro DMA bufffer chaining tak jim nestaci jeden argument a totiz adresa te periferie -- jeste potrebuji adresu interrupt pending registru a dokonce i offset tech bitu protoze to ti blbci pro kazdou periferii udelali jinde.
Pak vubec to jejich mapovani periferii -- kazda potrebuje max 256 bytu (stacilo by jim dokonce 128), ale oni ji vyhradi 16KB. Jenze ARM7TDMI umi PC-relative adresovani jen +-4KB (a pointer-relative tez, pokud se misto PC pouzije jiny registr). Takze kdyby mezi registry periferii udelali rozestupy 256 bytu tak je vsechny nacpaly na adresy pobliz FFFFFF00, kam dosahnu z kodu ktery zacina na 0, kde mam vetsinou scheduler a obsluhu preruseni. Tak jak to udelali oni dosahnu jen na jednu periferii a pro ostatni si musim nejdriv naplnit registr adresou a pak ho pouzit (coz zbytecne snizuje hustotu kodu -- kdyz to dela gcc tak az 4*, kdyz to delam rucne v assembleru tak zhruba 2* ale ten program pak vypada celkem krypticky). Problem by to zmirnilo i v kodu dal od adresy 0, protoze by mi stacil jeden bazovy registr pro periferie a ne pro kazdou periferii novy.
Pak taky jsem zjistil ze seriova linka kdyz se dostane do stavu framing error tak aby se z nej dostala zaruzene ven tak potrebuje aby zdroj dat prestal na chvili (aspon 1 znak) vysilat. Coz trochu cloveku zkazi radost kdyz si udela chaining DMA, ktere pak dokaze krmit/prijimat nepretrzite.
Muzete prosim rozvest to shazovani CS u SPI? Je to to co pisou v errata, nebo me pripadne ceka jeste nejake prekvapeni?
-
Petr M (neregistrovaný)
Zrovna s IRQ jsem u SAM7 problém neměl, tam používali SYSC, který měl nasekaný horních 16k a AIC byl v něm. Mohlo si to zavolat obslužnou rutinu samo. Zbytek si řešil ovladač periferky... Když bylo potřeba něco extra fast, šlo to mapovat na FIQ s vlastním vektorem.
A ty status bity PDC, rozstřílený do všech směrů, mě taky se..u. Ale na SAM7 a SAM9 byly aspoň stejný periferky a u všech PDC, na SAM3 je to tak půl na půl (u jednoho UARTu je, u druhýho ne), takže třeba univerzální driver UARTu díky těm (o)pičákům taky padnul.
Klasická Atmelí situace: Myšlenka potrojných registrů SET, RESET, STATUS je zajímavá, atomická práce s bity je třeba při povolování a zakazování IRQ skvělá. Ale proč, kua, nemůžu atomicky zapsat normální hodnotu z registru? A proč, kua, jednou mají SET-RES-STAT a jindy STAT-RES-SET? To taky univezální funkce pro atomický zápis hodnoty řeší jenom v případě, že místo jedné adresy dostane dvě... Takže místo funkce s dvojicí parametrů máme funkci se třema parametrama a nebo dvě funkce se dvěma parametrama, která dělá
DisableInterrupt();
*SetReg = Value;
*ResetReg = ~Value;
EnableInterrupt();kde SetReg a ResetReg jsou hned vede sebe. Být jejich pořadí stejný, tak postinkrement / postdekrement na 2. řádku krásně eliminuje třetí parametr funkce a s ním spojenou režii... :(
Chyby SPI už zveřejnili. Tehdy jsem dělal ovladač SPI FLASH. Říkal jsem si, že
- udělám struktru pro řízení (délka, operace, směr, adresa), která se zapíše do brouka jako první před půl PDC
- druhá půlka PDC pak hned pošle zapisovaný data nebo odchytí čtený data
- dostanu IRQ, jak budou data zapsaný
Realita? Odeslal se příkaz, vypnul se CS, čímž paměť zapomněla adresu, pak se zapnul CS a začalo to lifrovat data...
Wokaroudy:
- memcpy do společnýho bufferu - zatíží CPU
- používat CS jako GPIO - větší riziko chyby, horší synchronizace
- nepoužívat PDCJo, a sériovka - co se asi dá říct hezkýho o autorech UARTu, který když člověk nakonfiguruje jako PARITY NONE má permaněntně aktivní flag PARITY ERROR? Jinak skvělý vychytávky, dokonce i timeout v bitech si hlídá, mezery mezi znaky automaticky vkládá, za který by je člověk jinak i pochválil. Cool featury, ale základní věci neunkční...
A další vtip je, že RESET pin na SAMovi je po resetu jako výstup a pokud si ho člověk nehlídá, tak se zakousnutý procák restartuje až přerušení napájení. Konfigurace watchdogu je write once, takže funguje jako poslední záchrana na maximálním čase, pokud vůbec, a musí se to řešit externě... Asi kouřili dobrej matroš.
Někdy mám skoro chuť slavnýho SAMa spláchnout do záchodu, koupit si FPGA ProASIC od Actelu (s přípravou pro ARM jádro) a napsat si ty periferky ve VHDL sám. Možná by to bylo i rychlejší, ač jsem to roky nedělal. Jenom ta následná cena hardware... :(
-
klusacek (neregistrovaný)
Ja SYSC moc nepouzivam. Jednak nepouzivam ten jejich prioritni radic pro IRQ a druhak je tam spousta periferii ktere sdileji jedno IRQ, prestoze pocet pouzitych IRQ od ostatnich periferii (nezahrnutych pod SYSC) je neco kolem 16 z 32 moznych, takze by se jim to tam klidne veslo.
Pak jsou tam dalsi divnosti, napriklad zahrnuti seriove linky a systemoveho casovace pod SYSC v dusledku cehoz tyto 2 periferie sdili IRQ. To povazuju za vrchol demence. Nastesti ten casovac je vyresen tak blbe ze me vubec nenapadlo ho pouzivat, radsi jsem obetoval jeden TC casovac (proto potrebuju v scheduleru cist i mimo SYSC oblast a tam uz relativnim adresovanim nedosahnu).
S tim SET-RES-STAT mate uplnou pravdu. Vypada to ze to vymyslelo vic teamu a kazdy prisel s nejakym napadem a nebyl tam nikdo kdo by na to nahlizel jako na celek -- proste ty kusy slepili dohromady a zacali to prodavat.
Kdyby to bylo jak rikate tak by se dokonce dala vyuzit instrukce STMIA --- teda vlastne nedala, z nejakeho duvodu ktery jsem uz zapomel se tyhle instrukce nemaji pouzivat k pristupu k periferiim, takze by se musel jeste odstranit ten duvod proc to nejde.S tim SPI, jestli to chapu dobre, chcete rict ze nefunguje CSAAT (chip select active after transfer) bit kdyz se pouziva DMA. To je popsano v erratech a planuju ridit to pres PIO.
Ze watchdog po nastaveni nejde vypnout (krome uspani) povazuji za dobre chovani, protoze pokud by se stalo, bud chybou programu nebo pozasahu castici kosmickeho zareni ze to zacne totalne blbnout tak vim ze neni cesty aby program mohl watchdog deaktivovat -- co je horsi ze jim spravne nefunguje interval.
Normalne chcete watchdog do ktereho kdyz zapisete prilis brzy tak je to take spatne a dojde k resetu (pro pripad ze se vam program zacykli tak ze bude porad posilat watchdogu potvrzeni). To tam maji ale nefunguje to jak ma.
Ten nRST mi nevadi --- je to popsano v manualu. Vetsinou externi reset nepotrebuju a jednou jsem ho dokonce pouzil jako vstup pro tlacitko (da se nastavit aby to byl vstup ktery nezpusobi reset), kdyz jsem spotreboval vsechny ostatni nozicky.
Obcas mam taky chut udelat si ty periferie sam FPGAckem ale krome vysoke ceny by to nejspis melo i vyssi spotrebu a navic by program pak byl nekde vedle, takze by byl snadno ukradnutelny. Vyhoda SAM7S je i v tom ze po naprogramovani se da zamknout takze nedovoli precist flash dokud se nejdriv tato cela nesmaze.
-
Petr M (neregistrovaný)
Jo, to sdílení PIT, RTT, RSTC, DBGU, MPU,... pod jedno IRQ mě taky nas...
Mimochodem, RTT je velice zajímavá část SAM7X. Když jsem to viděl, nabyl jsem dojmu, že mají pod barákem místo garáží pěstírnu trávy.
RTT = real time timer. Je určený k počítání reálnýho času. Při pohledu na white paper člověk zajásá, že nepotřebuje externí RTC.
Jeden by řekl, že reálný čas si zasluhuje nějakou přesnost, přece pokud chci ujet o sekundu za týden, je to odchylka 1/604800 = 1,65ppm
Ne tak Atmel. Ten nabyl přesvědčení, že stačí připojit natvrdo jako zdroj hodin signál SCLK.
Při pohledu na blokový schéma a PMC je SCLK výstup z RC oscilátoru.
Charakteristika RC: "RC Oscillator ranges between 22 KHz and 42 KHz"
A jak se to dá doladit? V registru CKGR_MCFR je 16b číslo, který dává počet taktů krystalu na 16 period RC oscilátoru. Z toho je potřeba vypočítat nastavení 16b děličky v RTT...
Otázka je, jak na veřejnosti mluvit o autorech tohoto řešení a neurazit žádný zvíře, část těla nebo osobu s vývojovou vadou centrální nevové soustavy.
-
Petr M (neregistrovaný)
Na SAM7S nevím, z téhle rodiny jsem rozcházel UART jenom na SAM7X. Ale kolega nadával na to samý u 9261. Ale bylo to na regulérním UARTu, DBGU je dost očesaný a nalepený na debug z jádra.
Je to jedno hradlo navíc, dá se to obejít v SW, ale je to podmínka navíc, kdy se musí tesotvat podle jednoho registu, jestli je parita zapnutá a podle toho maskovat interrupt status během zpracování přerušení. Úspora, kterou vymyslel někdo hodně genitální.
-
klusacek (neregistrovaný)
Ja to mam makovany neustale, jelikoz prijimam data pres DMA -- na konci bufferu jen kontroluju jestli se v poslednim bloku nevyskytla chyba a vracim tyhle bity jako error code. Ale diky tomu DMA se stejne neda presne rict ktery znak je blbe takze je lepsi vyhodit cely buffer.
Takze je nakonec lepsi paritu vypnout, definovat nejake packety a na konec jim dat CRC.
Nastesti to nechybuje moc casto (kdyz jsem to meril tak to delalo 1 chyba na zhruba 1GB prenesenych dat), takze pro pripadnou `terminalovou' komunikaci, kde by packety byly nevhodne (moc slozite), to nechavam nezabezpecene.
-
Petr StehlíkZlatý podporovatelKlusacku, mám pocit, že jsem na ten posun kanálů multiplexeru narazil u Arduina, tj. ATMEGY. Myslel jsem si, že jsem se zbláznil, když jsem to viděl. Je to možné? Mám o tom rozepsaný článek, do errat jsem se teda nedíval. A to to mám naprogramováno v C a ještě přes Arduino API, takže mi nějaká přílišná rychlost nehrozí.
-
klusacek (neregistrovaný)
Ano to je mozne ;)
Mam takovy pocit ze pouzivaji stejnou nebo podobnou macrocell takze jestli to jednou nekdo udelal spatne tak to od te doby rozkopirovali do mnoha zarizeni.
Ale jak rikam, u me stacilo to zpomalit. Atmel na tu chybu neprisel vubec, kdyz mi pak poslali program jako ze jim vse funguje tak byl napsany tak ze kazda I/O operace volala Cckovou funkci ktera ten zapis/cteni provedla, a overhead bl/mov pc,lr stacil na to aby se to uz chovalo dobre.
Mate to posunte presne o 1 kanal a pouze kdyz je v multiplexeru navoleno ze chcete i kanal 0?
-
Petr StehlíkZlatý podporovatel
Přiznám se, že nevím - je to pár měsíců, co jsem to ladil. Každopádně čtu z A0 až po A4 sekvenčně a předtím ještě ten multiplexer přepínám tak, abych četl napájecí napětí. A někdy, jen někdy, se mi posunou ty naměřené hodnoty o jeden kanál - ale chovalo se to náhodně, takže mě to maximálně mátlo.
Jo a ještě přepínám referenční napětí mezi jednotlivými odečty, což se možná nesmí, anebo se pak musí chvíli počkat, až si to "sedne", nevím. Neměl jsem čas to podrobně studovat.
Nakonec jsem napsal vlastní čtení (v C), první zahazuju a ještě po přepnutí multiplexeru čekám desítky milisekund. Měl jsem pocit, že bez toho čekání to pořád zlobilo.
Jsem velmi zvědavý na vaše řešení, kdy říkáte, že jste to nakonec celé vyladil tak, že ani nemusíte zahazovat čtení. A pokud víte, jak se správně chovat po přepnutí referenčního napětí, tak jsem jedno ucho :)
-
klusacek (neregistrovaný)
Referencni napeti jde pres DA prevodnik na komparator, mozna tam je nejaky RC filtr na chipu a pomaleji to reaguje tak by se treba melo cekat ale spis to bude primo. Rozhodne by to ale nezpusobilo problem s prehazenim kanalu, jen snizenou presnost prevodu.
Ale z toho co pisete mam pocit ze prevod startujete a data vycitate rucne (mozna to na AVRku ani jinak nejde?) --- to je ten prevodnik vzene nepouzitelnej protoze nevite kdy presne bude samplovat a vnese vam do signalu jitter error. Takze na mereni napeti na baterii to staci, ale jestli chcete takhle samplovat nejaky signal tak odectete prevodniku par bitu prenosti v zavislosti na tom jak se v tom signalu vyskytuji vyssi frekvence.
Myslim ze v erratech je nejaka poznamka o tom ze za nejakych okolnosti co jsem uz zapomel je hodnota v tech CH(x) registrech blbe (resp. zapise se to tusim ze do CH(0) misto do CH(x)) a doporucuji tedy na to nespolehat a nechat si posilat preruseni po kazdem prevodu a cist rovnou ten registr AD prevodniku, ktery obsahuje zrovna prevedeny kanal.
Ja resil neco jineho, chtel jsem aby to korektne fungovalo pres DMA a vedel jsem kdy presne to sampluje. Muzu tak ted delat neco jako `vzorkovaci osciloskop' pro periodicke signaly -- ten vstup celkem dobre funguje az do 3 MHz.
Tady je to co jsem tenkrat poslal Atmelu at z toho udelaji poznamku v erratech:
195.113.26.193/~klusacek/atmel/images.tar.bz2
195.113.26.193/~klusacek/atmel/SAM7S_adc_bug.utf8Ani nevim jestli ji nakonec udelali, uz jsem se dlouho na nova errata nedival.
-
Petr StehlíkZlatý podporovatel
spouštím a čtu přímo, takto:
unsigned int mujAnalogRead(byte port, byte reference)
{
ADMUX = (reference << 6) | (port & 0x07);
delay(5);
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
// return ADCW; // zahodit
ADCSRA |= _BV(ADSC); // Start conversion
while (bit_is_set(ADCSRA,ADSC)); // measuring
return ADCW;
}A to ještě i ten výsledek této funkce kolikrát zahazuju a volám ji znovu, až tak tomu nevěřím, že to bude dodávat reálné výsledky.
Přerušení po každém měření mi přijde jako overkill, vždyť je to normálně převedeno raz-dva. Signály sampluju stejnosměrné stabilní, ale stejně se mi ta naměřená hodnota podezřele mění - něco mi tam vnáší šum nebo ruch nebo nevím co.
-
klusacek (neregistrovaný)
Asi to AVRko bude mit prece jen jiny interface k prevodniku. Jmena tech registru mi nic nerikaji. Taky na SAM7S musit predtim nakonfigurovat casovani ADCcka -- na coz vetsinou padne jeden TC-counter pak se musi ADC zapnout (coz se udela automaticky prvnim prevodem, ale musi se nakonfigurovat jak dlouho to ma cekat nez se napeti ustali a bude se moct zacit merit).
O kolik se to meni? Jestli posledni 2 bity z 10ti tak je to OK. Taky kdyztak ukazte jak to mate zapojene, treba vam tam sumi zdroj referencniho napeti nebo se na nej prenasi
pulzy z toho jak pracuje digitalni cast.Jaky ma zdroj signalu vnitrni odpor?
Zkousel jste jen tak pro zajimavost dotknout se na vstupu osciloskopem?
-
Petr StehlíkZlatý podporovatel
Mění se poslední jeden bit většinou, někdy i dva. Referenční napětí beru to vnitřní co má ATMEGA v sobě (1,1 V). Osciloskop jsem si koupil minulý týden, ještě jsem neměl čas ho použít. Vnitřní odpor zdroje z hlediska ATMEGY je možná ten dolní rezistor z napěťové děličky, kterou mám na vstupu, takže 8k2. Je to možná dost, ale zase jsem se snažil mít co největší odpor směrem zvenku, proto tak vysoké hodnoty v děličce. Podle toho, co jsem vyčetl, je to do 10k "v pohodě".
To mi připomíná, že jsem nedávno narazil na informaci, že ATMEGA má jeden speciální SLEEP mód, ve které usne většina digitálních vnitřností kontroléru po dobu analogové konverze, aby ji právě nerušila svým šumem. To bych někdy taky chtěl vyzkoušet, i když by mi to zas narušilo USB komunikaci, takže leda v nějakém speciálním případě. Minimálně zjistit, jestli by to uklidnilo ten neposedný poslední bit hodnoty.
Má smysl analogové vstupy filtrovat kondenzátory o nF hodnotách? Asi by mi napověděl nejvíc ten osciloskop. Snad bude čas koncem října...
-
klusacek (neregistrovaný)
Jestli se meni posledni bit tak je to uplne normalni i pro high end prevodniky. Posledni 2 bity, mozna i vic bych tak ocekaval u te ATmegy protoze urcite nema oddelenou digitalni a analogovou zem (kdyz se preklopi nejake hradlo uvnitr digitalni casti tak to zpusobi proudovy pulz na napajecim napeti a jelikoz GND drat ma nejaky odpor tak na nem vznikne ubytek napeti cimz se GND toho obvodu posune oproti GND co mate na tom delici a obvod pak jakoby nameri falesny vstup).
Vnitrni odpor delice napeti je odpor ktery odpovida paralelni kombinaci toho horniho a dolniho odporu (pokud na vstupu delice je zdroj napeti se zanedbatelnym odporem), takze to bude min nez 8k2 ve vasem pripade. Ale jestli je to hodne nebo malo zalezi na tom jak dlouho je otevreny vzorkovaci tranzistor a jestli se z nej stihne nabit vzorkovaci kondenzator na +- 1/2 LSB presne. To ale zjistite v datasheetu. Na SAM7S se ta doba da nastavit a divil bych se kdyby to tady tak nebylo. Mam pocit ze jste ten prevodnik uplne nenakonfiguroval -- odkud si bere CLK signal? To neni jen tak, funguje to jen pro nektere frekvence a jelikoz CPU muzete taktovat na velmi ruznych frekvencich tak je tam delicka abyste pomoci ni dal ADCku hodiny v tom rozsahu kdy funguje. Pro SAM7S jsou ty registry popsany, dokonce tam udavaji vzorec (imho nepresny, aspon podle toho jak jsem to zmeril, ale aspon neco) na to jaky maximalni odpor pri jake rychlosti muze mit zdroj signalu.
Ano, pro zlepseni je dobre digitalni cast uspat, pokud nepotrebujete aby po dobu prevodu pracovala.
Taky byste mohl udelat N vzorku a zprumerovat je -- pokud jsou ty chyby nahodne (nekorelovane) tak se zmensi sqrt(N)-krat. Coz treba pro N=16 je jeste unosne -- dostanete 2 bity navic (nebrat uplne doslova, skoro vzdy tam je nejaka korelace).
Zalezi jaky kondenzator tam vrazite -- jestli tam date v ramci setreni mista keramicky tak to muzete spis zhorsit diky jeho nelinearite a mikrofonim efektu.
Vnitrni odpor toho delice se spolu s tim kondenzatorem chova jako dolni propust s cut-off frekvenci 1/(2*pi*R*C) -- ale pokud se vam vstupni napeti moc nemeni tak to smysl nema -- spis si ohlidejte jestli vam po napajeni neleze ruseni do analogove casti (pro rychle vyzkouseni treba muzete zkusit analog napajet oddelene z baterii (radeji pripojovat az po zapnuti digitalni casti -- sice to ma ochrany, ale prece jen...)).
Jeste otazka -- ma ten vas prevodni 8 bitu nebo 10 bitu?
-
Petr StehlíkZlatý podporovatel
Tak to máme 6k6. Díky za uklidnění stran toho posledního bitu (z 10) - já to pořád porovnávám se svým levným digitálním multimetrem, který prostě ukazuje třeba 1,000 V a hodnota mu nijak nekolísá, pořád je tam 1,000. Asi v sobě nemá ATMEGA :-)
Informace o CLK teď nejsem sto dodat, musím dělat jiné věci než hledat, a až se k tomu vrátím, tak tato diskuse bude už mrtvá a archivovaná. Proto bych vás rád požádal o e-mailový či jiný kontakt zaslaný na můj e-mail, který by tu měl být znám díky tomu, že jsem přihlášen pod svým účtem, který mám vyplněný. Anebo je to v profilu autora článků, anebo kdekoliv jinde na webu jsem dohledatelný. Rád bych to s vámi ještě někdy dořešil poctivě, tj. z mé strany podložené konkrétními údaji, případně schématem atd. Máte zjevně vzácné zkušenosti, které bych si rád poslechl/přečetl.
N vzorků už používám, Atmel to oficiálně doporučuje jako způsob, jak vymáčknout z převodníku bity navíc. Ale i tam mi pořád ten poslední (jedenáctý či dvanáctý) bit cvičí - asi ho musím pak už zaokrouhlit, abych dokázal fungovat jako multimetr a ukazovat 1,000 V.
Jinak zatím používám výchozí konfiguraci Arduina, která to ADC nějak nastaví, ale abych nekecal, tak bych to musel dohledat a to teď právě bohužel nemůžu. Každopádně jsem tento svůj případ drze přihlásil na OpenAlt jako přednášku, tak vyberou-li mě, bude potřeba to urychleně vyřešit :-)
-
Petr StehlíkZlatý podporovatel
To jsem ale ani v nejmenším netušil. To je chytré, zvlášť ten násobek 20 ms. Měl bych to u sebe taky tak implementovat.
-
Petr M (neregistrovaný)
Hlavně, v jednočipeh jsou z 99% vestavěny SAR převodníky, u multimetrů integrační převodníky s kompenzací (a ruchlostí 3-5 samplů/s).
Integrační převodník jde udělat i na jednočipu bez ADC, s přesností klidně i 16-32b (podle dostupných časovačů). Protože je to převodník integrační, šum se tak nějak "rozptýlí". U voltmetru, pokud to je o změření hodnoty a ne zvlnění napájení s FTT, bych šel taky cestou integrace. Hlavně u Atmela.
Posledně jsem to dělal na MSP430 podle http://www.ti.com/lit/an/slaa061/slaa061.pdf a je to bez problémů.
P.S: Vnitřní odpor pro napájení ADC se určuje dle okolností s pomocí Nortonovy nebo Theveninovy věty... ;)
-
Petr StehlíkZlatý podporovatel
mail nepřišel - pokud se nepotkáme na LinuxDays, tak prosím o nový mail.
-
Petr M (neregistrovaný)
A/D převodník jsem na těch potvorách zkoušel použít jenom jako on-board diagnostiku. Na aplikační věci jsem neměl odvahu. I tak člověk nevěděl, který kanál zrovna čte... a hlavně platí, že první čtení se zahazuje. Raděj zahazuju prvních pět hodnot, kdyby změnili revizi čipu...
Ostatně, u Atmelu je tragický všecno, co smrdí analogařinou. Nefunkčním oscilátorem (první AVRka) počínaje, spotřebou broxnout obvodu 130uA (XMEGA) pokračujíce (externí resetovací obvod s vystačí s 0,5uA) a zmršenýma ADC konče.
Tím se dost liší od Microchipu. Ten má excelentní analog (například operáky jako MCP60x), ale jak dojde na číslicovku, tak by jeden brečel.
-
klusacek (neregistrovaný)
Tak me se to nakonec podarilo rozchodit. I ten prvni vzorek je dobry, kdyz se spravne nastavi citac pro startup time. Jen je na nem spatne, ze se nevyskytuje ve stejnem rozestupu jako ostatni vzorky, protoze zase zapomeli ze by bylo dobre aby startup citac pracoval v nasobcich toho co pak bude vzorkovaci perioda. Takze ho taky zahazuju.
Spis mi chybi ze to nema analogovou zem, ale to bych chtel uz asi moc.
-
Pavel TišnovskýZlatý podporovatelJa jsem mel podobne zkusenosti s nekterymi cipy AMCC. Nebyly spatne (spis naopak), ale nejlepsi bylo zacit cist erraty a teprve pote specku :) A ze tech errat nekdy nasekali. Proste snaha dostat produkt ven za kazdou cenu a co nejrychleji...
-
Petr M (neregistrovaný)
Pokud najdu na webu "máme chyby na čpu, netaktuj periferku pod 4MHz", tak vím, s čím počítat a zařídím se podle toho. Mluvím o trochu jiné situaci.
Napsali do dokumentace odběr ve sleepu 2uA. Zákazník měl požadavky na životnost CR2032 a díky tomuhle mu to bestii vnutili. V půlce projektu přišly vzorky jejich fungl novýho brouka, zapojím to, nakonfiguruju podle dokumetace, zapojím měřák a čumím jak žaba z křa. 125uA, datasheet 2uA, příslušná kapitola v erratě prázdná, FAE o ničem neví, Atmel HQ hlásí že splnili přesně to, co je v datasheetu...
Až po dvou měsících od nahlášení a měsíci a půl od dodání testovacího programu, schématu zapojení tesotvacího přípravku, desetistránkovýho návodu, co a jak, obrázků z osciloskopu, fotek, statistiiky na 20ks včetně vyčtených souřadnic na wafferu a kdo vi čeho dalšího, zavolala nějaká vývojářka od Atmelu. S omluvou, že to zapomněli otestovat. Profesionálové každám coulem.
-
Pavel TišnovskýZlatý podporovatel
Taky děkuji a musím se přiznat, že mě až (samozřejmě příjemně) překvapilo, jak se zde i pod minulým článkem vede kultivovaná diskuze :-)
-
robo (neregistrovaný)
Toto je najlepsi serial za posledne 2 roky aky som tu cital. A diskusia je rovnako kvalitna a poucna ako clanok.
Chcel by som sa spytat co si myslite o tomto: https://store.ti.com/cc2650stk.aspx
Maju tam to svoje MCU CC2650 je to Cortex-M3, ma to 10 senzorov a k firmware davaju zdrojaky a stoji to 29USD. Na vyuku a studium mi to pripada uplne idealne. -
Petr M (neregistrovaný)
Kit samotný neznám, procesor taky ne, takže jenom obecně moje zkušenosti s TI.
Byl to v bývalé práci náš preferovaný dodavatel, protože:
- Technická podpora je nadstandardní. Stačilo se FAE zmínit, že je s něčím problém, do dvou dnů měl řešení.
- Když chtěl člověk bližší informace k jejich broukovi, tak v 70-80% u analogařiny s odpovědí došel i kit, aby si to člověk mohl oměřit a osahat.
- Dokumentace je nadstandardní.
- Vzorky zdarma, vždycky se daly sehnat do týdne.
- Rozumná cena i kvalita.
- Dá se koupit všude.A mimo to se tam daly najít i věci, co na jednom čipu zvládly řešení, na který u konkurence padlo pět brouků. Takže směle do toho.
-
Yenya (neregistrovaný)
Děkuji za sérii článků, je to zajímavé. Už delší dobu bych si chtěl vyzkoušet něco s nějakým malým ARMem - věci které teď bastlím třeba na ATtiny25 nebo 861a. Ale zatím mám problém, jak se v tomto novém světě zorientovat, výrobců je moc, modelů ještě víc. Potřebuju tedy poradit, jak začít, jaký model zvolit, atd:
- napájení v rozsahu minimálně 2.7-5 V
- ručně pájitelné pouzdro (ne QFN, BGA nebo něco podobného)
- ADC
- rozumně dostupné v jednotkách kusů aspoň na Farnellu, lépe i v místních obchodech (GES, GME)
- ne moc velké (pro většinu věcí je 64 pinů overkill)
- ne moc drahé (ATmega328p stojí přes eBay okolo padesáti korun, tak řekněme do stovky v místním kamenném obchodě?)No a potom - jak se to programuje? Předpokládám, že nainstaluju/přeložím arm-gcc a binutils, a co potom? Je k tomu něco jako avr-libc, což zajistí základní nástroje typu definice I/O portů, rozložení paměti, funkce pro atomické operace (zákaz přerušení a podobně), ...? Jak se program dostane do MCU - je tam něco jako avrdude? A jaký HW programátor potřebuju?
Díky,
-Yenya
-
atarist (neregistrovaný)
Možná zkus položit tu stejnou otázku pod tím novějším článkem, takhle zpět se moc lidí asi nedívá (když to není na front page roota :-). Ale abych odpověděl:
existuje několik už hotových destiček, možná je nejlepší začít tam než vymýšlet hned na začátek vlastní zapojení. Osobně bych začal s Arduino Due, což tedy není do stovky, ale trošku víc. V ceně však dostaneš USB interface, IDEčko (pro C) apod. Jak píšeš, knihovny jsou, docela podobné řekl bych, programátor záleží na čipu, ale většinou je to Flash a díky nábojové pumpě to klidně chce jen 5V nebo 3,3V, žádné šílenosti. -
bitsmith (neregistrovaný)
Sam som zacinal s STM32F4 Discovery, SPL a em::blocks, momentalne pracujem s STM32F0 Discovery, pricom kod je takmer bez zmien.
Co sa tyka em::blocks, moja volba bola vysledkom viacerych pokusov s Eclipse, OpenOCD a GDB a dalsie (code::blocks a ine), bolo to v case ked OpenOCD este poriadne nevedel ladit tuto platformu. Prednostou em::blocks je napr. moznost printf() cez debugger a smerovanie prijektu na embedded vyvoj. Nevyhodou je nutnost prevadzkovat Windows.
-
Petr M (neregistrovaný)
Takhle pro začítek bych šel asi do STM32, vývojový kit je za pusu... Z výrobců asi ST (řada STM32), NXP (řada LPC), TI (řada LM původně od Luminary Micro).
S 5V nevím nevím, ale ruční pájitelnost dobrá (TQFP, TSSOP).
Na GES, GM a podobný už jsem rezignoval, co jinde stálo kilo, oni měli za pět. Žádnej obvod mladší cca 5 let jsem u nich neviděl, oni potřebují vydělávat. Není poptávka, není v nabídce. Není v nabídce, bastlíř ho nepoužije a nezveřejní konstrukci. Takže se nevytvoří poptávka. A když to poptá nějaká firma, dají MOQ třeba 1200ks, aby se jim to "vyplatilo"... :Q Takže menší série TME, RS, Farnell.
Programování, no na STM mám programátor STLink na Discovery, Atmely mají USB bootloader (stačí USB-B konektor a tři odpory) a SAM-BA (pro widle :(), jinak to OpenOCD s FT2232 jistí (a je to i s UARTem pro konzolu). Programování větších potvor s externí RAM a FLASH je trochu divočejší.
Knihovny a tak, no, rozepisovat to nebudu, když to udělali jiní. http://mcu.cz/search.php?q=Za%C4%8D%C3%ADn%C3%A1me+s+STM32&r=0&s=Hledat&in=&ex=&ep=&be=&t=news&adv=0
ČLÁNKY DO MAILU