Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
Ha elolvasod a kézikönyvet, akkor abból láthatod, hogy a PWM mindig eggyel indul (akkor is ha nullára állítod az OCRx regisztert). Az első ciklusban pedig törli azt (tehát egy tűimpulzust kapsz 0 esetén).
A helyes megoldás, hogy ha 0%-os kitöltési tényezőt akarsz, akkor kikapcsolod a PWM pint. Itt egy példa:
A hozzászólás módosítva: Júl 8, 2015
Szia, pedig én azt láttam, hogy folyamatosak voltak az impulzusok (villogott a led), nem csak egy volt, hanem végig amíg 0 volt az OCR0A és OCR0B. Amit kiszámoltam, hogy kb fél % volt a kitöltés az durván megfelel a ciklus 255-öd részének tehát mint ha végig 1 lett volna az OCR0A vagy OCR0B.
Bocsánat, hogy csak úgy belevaú, de tapasztalataim szerint sok esetben nem jó a Phase Correct PWM, mert ilyenkor a rákötött FET vagy az AVR belső tranzisztora nem kapcsolóüzemben, hanem áteresztő üzemben működik, így elég szépen tud melegedni, tehát jó kis hűtés kell a FET-re, de Fast PWM-ben pedig néhány amperig semmi szükség hűtésre. A kérdés az, hogy csak LED-hez vagy nagyobb teljesítményhez használjuk-e fel?
Van szükség arra, hogy 0% kitöltési tényező mellett egy impulzus se jelenjen meg? Én is találkoztam a hibával mg régen ATmega8-ban (azóta nem találkoztam), de nekem nem számított. Egy LED-nél látványos de én például fűtésre használtam.
A másik ötletem, hogy ne gy nullázd az OCR0A, OCR0B-t hogy OCR0A = 0x00 és OCR0B = 0x00. Hátha!
Mindegy, hogy melyik számrendszerben adsz értéket egy regiszternek, a nulla az mindig nulla.
Ha lépteted a progit (avr Studioban) látni kellene azt az helyet, amikor a port szintje változik. Nemrégen nekem is volt ilyen gondom, és direkt a portra tettem egy Stop pöttyöt és igy találtam meg, hogy miért változik a szint, ha elvben nem kellene.
Megvan a megoldás!
Így kell kiszámolni a kitöltési tényezőt: D=(OCRx+1)/(TOP+1) * 100% Így ha OCRx=0 a kitöltési tényező 0,39%, ha TOP=0xFF. De ha OCRx=255, akkor D=100. Ergó invertáló módba kell tenni Fast PWM-en, így 255-nél 0% lesz a kitöltési tényező, 0-nál pedig 100-0,39 % lesz.
Sziasztok! Amtega328 Timer2-re van forrasztva egy óra kvarc, ezidáig meglepően pontos volt. Bővítettem a programot ADC feszültség méréssel, hardverileg pedig bekerült a Lithium ion cella elé egy töltőáramkör. Ezen kívül lényegi változás nem történt a programban sem. Most úgy működik, hogy ha nem alszik az AVR, és figyelemmel követem a másodpercek múlását, akkor minden oké. Viszont ha elmegy alvóba, akkor gyorsabban számol, néha 1mp alatt ugrik 4-et is, pedig csak mp-ként ébred fel az AVR, növeli a mp változót, és megy aludni. A kvarccal kellene párhuzamosan kondenzátor (ha igen, mekkora értékű kb?) , esetleg a tápfeszültség rosszalkodhat (LIR2032-m van) ? Egyéb tipp esetleg? Köszönöm szépen.
Nem hiszem, hogy ez a gond, de a kvarc két lába és a test közé 1-1 22pF-os kondenzátort kell bekötni. Ez benne van?
Nincs bent most a kondi, mert rezeg a kvarc, inkább az lehet a baj, hogy vagy túl sokat rezeg, vagy összeszed valami zajt, vagy a timer interruptja túl sokszor hívódik meg. A zajt nem tartom valószínűleg, mert egy alvó módú AVR mindentől távol elég jól szeparált. Lehet a kondi hiánya lesz a ludas, mert egy másik órámban az áramkör zajait szedte össze a bemenet, és mindig gyorsabban számolt, itt viszont csak akkor számol gyorsabban, ha alvó állapotban van az AVR, ilyenkor pedig szinte semmi a zavarkibocsájtás... Esetleg amikor elmegyek alvóba, kikapcsolok minden perifériát, meg lecsökkentem a fényerőt fokozatosan 0-ra, ez zavarna be, aztán alvó módban már semmi gond nem történik. Köszi a javaslatot, innen már csak a harcmezőn fogok tudni továbbmenni, de már meg van az irány, hogy mit kell tesztelni. Remélem kondi nélkül is menni fog, mert nagyon kevés a hely
 . Köszi!
Persze, hogy folyamatosak voltak az impulzusok. A számláló két érték között számol (0 és egy tetszés szerint megadható között, ez határozza meg a PWM frekvenciát) majd amikor elérte a felső értéket visszaáll a kezdeti értékre és 1-be állítja a kimenetet (ez a fast pwm-re vonatkozott, a phase correct pwm picit más). A lényeg, hogy az érték ellenőrzés közvetlenül a következő értékre lépés előtt történik (ezért egyben van egy léptetésig a kimenet), ha nem így csinálna, akkor meg a 100%-os kitöltési tényező nem menne. Próbáld ki a kódot, amit adtam.
Idézet: „The extreme values for the OCR0A Register represents special cases when generating a PWM waveform output in the fast PWM mode. If the OCR0A is set equal to BOTTOM, the output will be a narrow spike for each MAX+1 timer clock cycle. Setting the OCR0A equal to MAX will result in a constantly high or low output (depending on the polarity of the output set by the COM0A1:0 bits.)”
A 22pF kicsit sok a 32.768kHz-es órakristályhoz. A kézikönyv 8-18pF-ot ajánl. (A 22pF-t inkább a 16MHz-es kristályhoz szokták használni). Én 18pF-t használtam egy projektben és a elég volt a szkóp pár pF-es kapacitása, hogy elszálljon a kristály (a 16MHz 22pF-nél nem volt ilyen gond).
Órakvarchoz - tudtommal - nem kell kondi, egyébként a kisebb frekihez dukálna a nagyobb és nem fordítva. Pl. 16MHz-es kristályhoz jó a 12pF, 1MHz-es mellé 27pF az ideális...
22pF a maximum javasolt.
Az alacsony órajelű kristály oszcillátor más paraméterekkel dolgozik mint a 400kHz feletti. Ideális pedig nincs, mivel maguk a kristályok is különböznek (még ha ugyanaz is a frekvenciájuk). A helyes az lenne, ha a kristály saját kapacitását is ellenőriznénk az adatlapon, nem pedig hasraütésszerűen választanánk kondit.
A kvarcoknak van egy úgynevezett load capacity paraméterük (órakvarcoknál 12,5pF a tipikus értéke, de nem minden esetben ennyi, az adatlapján kell megnézni). Ezt figyelembe véve kell kiszámolni a két rákötött kondi értékét az itt található képlet alapján. Mondjuk azt hogy egy másodperc alatt négyet számolna be, azt nem tartom valószínűnek hogy ez okozná, én is elsősorban a tápfeszproblémára, esetleg hibásan megírt programra tippelnék. Mondjuk egy próbát megér a kondik berakása. A kapacitások változtásával a kvarc frekvenciája is változni fog néhányszor 10ppm-el, ha az órát pontosítani szeretnénk lehet akár trimmerkondival is játszani.
Idézet: „Hogyan módosíthatnám DDRx, PORTx, PINx-et egy betű átírásával?”
Ahol pedig hivatkozni akarsz a DDRx-re ott az M_DDR-t használod.
Üdv!
Ezt a projektet akarom megvalósítani, de a baj az, hogy amikor AVR-8-OMat -tal be akarom tallózni az AVRdude.exe-t, nem találom sehol. WinAVR fel van telepítve, ha simán megnyitom intézőben a gyökérkönyvtárát, és rákeresek benne a kívánt .exe fájlra, akkor sincs meg. Már kétszer újratelepítettem WinAVR-t, de nincs meg az .exe. Valakinek valami tipp? Innen van a telepítő WinAVR-hez. Hozzáteszem, Atmel Studio (6.2 konkrétan) fordítója működik a WinAVR-rel. A hozzászólás módosítva: Júl 10, 2015
Az avrdude az egy külön program, winavr-hez nem sok köze van.
Windowsnál a winavr tartalmazza az AVRdude-ot is.
Gondolom win8 vagy valami jópofa víruskereső.
Mingw32.zip-et próbáld ki.Nem ismerem az aurdino-t,de az nem telepíti ?
Sziasztok!
Van egy táblázatom az AVR programjában (volatile uint16_t tablazat[212]={23456,21344,12334,stb}  , amit soros kommunikációval szeretnék módosítani, felülírni. Sajnos a string kezelésben nem vagyok túl jártas. Azt szeretném elérni, hogy az AVR a beérkező adatokat úgy fűzze össze, hogy vesszőnként szétválasztva új sorba rendez minden egyes számot, így tudnék hivatkozni az első és utolsó sorára is. Ráadásul a kész táblázatnak uint16_t formátumban kellene lennie. Tud valaki segíteni ebben, esetleg pár tippet/tanácsot adni?
A bemeno adatok ASCII karakter vagy hex? ASCII eseteben van string fuggveny, amivel megkeresheted a vesszoket (strchr) es ezutan at kell alakitani a bejovo karaktereket binaris szamma.
|
Bejelentkezés
Hirdetés |
