Fórum témák
» Több friss téma |
Itt találsz egyszerű példa rá, miért kell a do/while.
Bővebben: Link
A do - while(0) ciklusok értelme elsősorban hibakezelés.
A fenti goto utasítást a programozók zsigerből utálják, ezért a következő kód alakul ki:
A hozzászólás módosítva: Máj 31, 2017
Újból megőrít a DMA-s USART.
Beraktam egy időzítő interruptjába az adatok küdését pontosan 4 csomagot. Szkópon nézem indítás után egyszer elküldi az adatot utána pedig többet nem pedig a függvény meghívódik.
Már egyszerűen nem tudom miért nem küldi folyamatosan.
A HAL_UART_Transmit_DMA függvény nem blokkolja a CPU-t. Azaz még el sem küldte az adatokat, viszont te már törölted is őket.
A HAL függvények teljesen korrektül kezelik a flag-eket. Neked nem kellene és nem is szabadna módosítgatni. Minden HAL függvénynek van visszatérő értéke (pl. HAL_OK ) azt kérdezd le inkább.
Nos. Megtaláltam mi volt. Az a baj hogy ha sem az adatlap sem semmi nem említi hogy DMA mellé kötelező engedélyezni a periféria interrupját is ami jelen esetben az USART.
Beraktam azt az 1 sort és már ment is. Bár nem értem ha valaki cube-al generál cuccost akkor miért nem engedélyezi automatikusan azt is ha Normal módban úgysem működik nélküle. Circular modeban megy de Normal mode-ban kell a global interrupt.
Szép napot Uraim!
Kevés sgítség kellene! Nem értem! Ez a map() fügvény miért ad nekem mindig 0-át vissza?
Az eredmények: point_new.X = 2059 point_new.Y = 2907 Map_new.X = 0 Map_new.Y = 0 point_new.X = 2027 point_new.Y = 2942 Map_new.X = 0 Map_new.Y = 0 point_new.X = 1712 point_new.Y = 2666 Map_new.X = 0 Map_new.Y = 0 point_new.X = 1711 point_new.Y = 2672 Map_new.X = 0 Map_new.Y = 0 point_new.X = 722 point_new.Y = 1555 Map_new.X = 0 Map_new.Y = 0 point_new.X = 1075 point_new.Y = 1561 Map_new.X = 0 Map_new.Y = 0 point_new.X = 1090 point_new.Y = 1564 Map_new.X = 0 Map_new.Y = 0
Ha jól látom, rosszul végzed el az osztási műveletet uint16-on. Osztasz (istop-istart)-tal, ami olyan 3570. Ha (value-istart) értéke nem nagyobb ettől a 3570-től, akkor mindig nullát fogsz kapni. Rossz helyen van a zárójelezés, mert először osztasz, csak ezután szorzod a kapott értéket (ostop-ostart)-tal.
Vagy lebegőpontosra rakod át a számítást, ami időben kicsit tovább tart, vagy átszervezed a számítást, és mondjuk az osztandót megszorzod egy konstanssal, int32-n elvégzed a számítást, és utána osztod ugyanazzal a konstanssal. Vagy már az alábbi is segíthet, ha először a két számot összeszorzod, és csak utána osztasz. uint16_t mapt = ostart + (ostop - ostart) * (value - istart) / (istop - istart); A hozzászólás módosítva: Jún 9, 2017
Köszönöm a segítséget!
Akkor ott rontottam el, hogy az eredeti double-ket lecseréltem uint-re. És nem gondoltam át a hatását. A zárójelezés áthelyezés javaslatod, elfogadható eredményt hozott.
Üdvözlet.
Méregetem az STM32 F030 ADC -t és sajnos nem értem miért de 5-7% os hibával mér. 1.24V 5mV-os zajjal mér 1700-at de kb 1545-t kellene mérnie. A tápja 3,286V 10mV zaj mert megy egy PWM kimenet. 100nF az adc bemeneten 2x100nF +10µF a tápon LD1117-33 a stab. A mérést 16-os mozgóátlaggal simítom szóval ez nem véletlen méérési hiba hanem valami iszonyat offset hiba. Másik panelem 1545-helyett 1486-ot mér. AZ is rengeteg. Találkozott már valaki ilyennel?
Ellenőrizd mennyin járatod az ADC-t. Lehet rossz órajel beállításokat használsz. Milyen sample rate-t használsz egyébként? A belső refet általában nem lehet akármekkora gyakorisággal mérni.
A hozzászólás módosítva: Jún 13, 2017
Standard 14Mhz-en megy amit alapban felajánl beállításnak.
1.5 ciklus mintavétel így 1uS gy minta.
Na ott a probléma. Nem mintavételezheted olyan gyakran.
Belső refet nem mértem eddig sohat, a kalibráció hiánya okozhat ekkora eltérést?
Nem. Egyszerűen nem szabad túl rövid ciklusidővel mintavételezni. Gyanítom, hogy olyan kicsi áramot tud leadni, hogy nem megfelelően töltődnek a mintavételező kondik.
Itt a vonatkozó katalógusrész: A hozzászólás módosítva: Jún 13, 2017
Azért raktam 100nF kondit a bemenetére hogy még véletlenül se forduljon elő hogy nem tud precíz mintát venni. Abból indultam ki , hogy a Radc és a Cadc bemenő R_C páros indőállandója jóval kissebb mint a mintaváteli idő de most hogy nézem az adatlapban maximum 1k-8pF ami legrosszabb esetben tényleg elég durva. Megpróbálom hosszabb mintavétellel, de nekem akkor is furcsa mert ebben az esetben mindig csak egyirányú lenne az offset.
Átállítottam 55.5 ciklusra, kb semmi változás.
Én le szoktam választani az analóg tápot a digitálisról egy ferritgyöngy/kondi párossal (ezt kapják a műv erősitűk stb is). Majd az IC közelében kap egy 1µF +100nF párost még. Természetesen az analóg föld is külön van a digitálistól.
Nem. Mondjuk én az F103-as sorozatot használom.
Csak a biztonság kedvéért kérdezem. Bekapcsoltad a fesz. referenciát az ADC_CCR regiszterben? A hozzászólás módosítva: Jún 13, 2017
A program elején írjam 1-be az ADC_CR_ADCAL-t?
ADC->CCR |= ADC_CCR_VREFEN; vagy vmi ilyesmi lesz.
A hozzászólás módosítva: Jún 13, 2017
Nem értem az összefüggést.
Nálam a referencia a VDDA táp minek kellene nekem a ref fesz?
Most engem zavartál össze. 1,24V-ot írsz és belső referenciát a hozzászólásaidban. Na most 1,2V-os a belső referencia, ami nem függ a VDDA tápfesztől.
Nem írtam hogy a belső referenciát használnám. A mérendő bemenetre írtam, hogy 1,24V és arra ad vissza 5% hibát. Lehetne a bemenet 2V-is nem az lényeg. A proci belső referenciájához hozzá sem nyúltam. A 3,3V lenne a 4095 érték.
Idézet: „Belső refet nem mértem eddig sohat, a kalibráció hiánya okozhat ekkora eltérést?” Na ez zavart akkor meg. Illetve a fesz is stimmelt a belső refre.
Szokásos lépések F103-nál (gondolom F30-nál is hasonló lesz).
Periféria órajelek bekapcsolása (ADC, GPIO, esetleg DMA). ADC konfiguráció. DMA konfiguráció. ADC kalibráció reset. -> vár míg kész ADC kalibráció. -> vár míg kész DMA engedélyezés. ADC engedélyezés. |
Bejelentkezés
Hirdetés |
