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
Amit csinal a fordito:
checksum += (array[i] << 8); eseten: 1. array[i] -t konvertalja unsigned char-rol int-re 0x80 -> 0x0080 2. felshifteli 8 bittel 0x0080 -> 0x8000 3. az osszeadas elott konvertalja 32 bitesre, de mivel 0x8000 int tipusu, ami elojeles, igy a konverzional kiterjeszti az elojel bitet: 0x8000 -> 0xffff8000 4. ezt adja hozza checksum-hoz. Ezt meg kellett volna latnom  Idézet: „Azért még most is zavar, hogy az első verzió mért ment és miért nem ment...” A verziok kozott az a kulonbseg, hogy az adat mas, amibol a checksum-ot szamolja. A hozzászólás módosítva: Szept 13, 2014
Na ez az, gyakorlatilag fogalmad sincs róla, hogy mi történik. Hiába ismered a működését, akkor is képes meglepni.
Éppen ezért jutottam el odáig, hogy mindig kiírom kasztolással, hogy ezt a típust akarom és nem bízom a fordítóra. Ez kb. olyan mint a műveleti precedenciák, arról sincs fogalmam se, hogy most éppen a || vagy && precedenciája alacsonyabb, de nem is érdekel. Kiírom zárójelekkel, hogy ezt akarom, a fordító meg tőlem úgy precedenciázik, ahogy akar. Mellesleg a C a kiszámítható nyelvek közé tartozik. A C++-ról ugyanez már nem mondható el, a konstruktoroktól az operátor túlterhelésem át a destruktor meghívásáig gyakorlatilag lövésed sem lesz, hogy mi miért történik és milyen sorrendben hívódik meg. Egyik C++-os állásinterjún felraktak egy kérdést, hogy mit ír ki a program, amihez elvárták volna, hogy fejből tudjam, hogy a sok konstruktor / destruktor izé milyen sorrendben hívódik meg. Megoldás helyett azt javasoltam, hogy talán ki kellene rúgni azokat az embereket, akik ilyen kódot írnak. Nem hívtak vissza második körre.  A hozzászólás módosítva: Szept 13, 2014
Idézet: Ezt ugye nem ugy ertetted, ahogy hangzik? En mar 1992-ben C forditot irtam Z80-ra, ugyhogy eleg sok fogalmam van rola, hogy mi tortenik. Ettol fuggetlenul ezt az esetet beneztem. Figyelmetlen voltam, nem gondoltam teljesen vegig. De altalaban nem nyugszom, amig meg nem ertem, hogy mi a helyzet. Nem elegszem meg azzal, hogy "igy most jo". Jelen esetben nem en irtam a kodot, nem merultem el benne nagyon melyen, hogy pontosan mi tortenik. Ezt a hibat en is besz@ptam volna siman, de sajat kornyezetemben hamar rajovok, hogy mi a gond. Mivel csodak nincsenek, es tudom, hogy mik a szabalyok, ha levezetem ugy, ahogy az elozo postomban megtettem, akkor maris latom, hogy mi a gond. De nem vezettem le, mert kicsit megzavart az, hogy az ICMP header-t nem szamolta rosszul. Inkabb gyanakodtam valami egyeb hibara (globalis ciklusvaltozo...), mint erre. Nem akarok magyarazkodni, csak arra szeretnek ravilagitani, hogy mas az, amikor elnezel egy ilyen ketszeres implicit cast-olast es megint mas, amikor nem ertesz hozza eleget. De ebbol is tanultam.„Na ez az, gyakorlatilag fogalmad sincs róla, hogy mi történik.” Idézet: De, ha nem tudod, hogy mik az elojelekre vonatkozo szabalyok, es pl. egy signed char tipust cast-olsz unsigned long-ra, akkor lehet, hogy arra szamitasz, hogy 0x80-bol 0x00000080 lesz, pedig 0xffffff80 lesz belole.„Éppen ezért jutottam el odáig, hogy mindig kiírom kasztolással, hogy ezt a típust akarom és nem bízom a fordítóra.” Mindennek oka van, a programozas egy egzakt tudomany. C++ -hoz nem tudok hozzaszolni, fenyevekre van a mikrokontrolleres programozastol, sosem erdekelt. Szamomra az egyetlen hasznos dolog belole a // Idézet: „C++ -hoz nem tudok hozzaszolni, fenyevekre van a mikrokontrolleres programozastol, sosem erdekelt.” Arduino? (Arduino nyelv nincs, az C++) Maradjunk annyiban, hogy hobbi szinten AVR alatt többen használják a C++-t, mint a C-t. Idézet: Egeszsegukre „Maradjunk annyiban, hogy hobbi szinten AVR alatt többen használják a C++-t, mint a C-t.” 20 eve a Basic stamp-et hasznaltak, mos ez a slager.
Én is rászoktam, nem azért mert olyan jó, hanem mert praktikus.
Csomó lib van fenn a neten, csak letöltöd és használod. A programozási idő tizedére csökken, vele együtt a végrehajtási sebesség is, a kód mérete meg tízszeresére nő, de nem baj, a 32k sokmindenre elég, meg a 16 MHz is. Értelemszerűen kész termékbe Arduino-t nem rakok.
Sziasztok!
Segítséget szeretnék kérni tőletek, mégpedig azért, mert most szeretnék elkezdeni avr-el foglalkozni, elsősorban ATTiny-val, de fenntartom a lehetőséget a többi verzióra is. Melyik programozót ajánljátok? Úgyértem ár/érték arányt tekintve melyik a legjobb? Találtam Ebayen már néhányszász Ft-tól, egészen 5-6ezer Ft-ig bezárólag sokfélét, és kissé tanácstalan vagyok. Előre is köszi a segítséget! Üdv.: Dávid
Kezdőként használhatatlan vackot nem érdemes megvenni.
Én AVRISP-MK-II-t vettem, nem volt vele bajom. Miután kiválasztod, hogy mit akarsz konkrétan, érdemes még kérdezni egyet itt a fórumon. Az AVRISP-MK-II középkategória, tudsz 20.000-ért is venni. Bár manapság ellustultam és Arduino UNO-val programozok (az avrisp-mk-ii jobb, de macerás). A hozzászólás módosítva: Szept 16, 2014
Én is a Dragon mellett teszem le a voksot. Nálam igen jol bejött.
Ha van LPT és nem akarsz túl sokat költeni,én ezzel kezdtem anno,most is jól működik:programozó,szoftver.
Képes tápfeszt kiadni. Átírtam az ArduinoISP programot és az A0,A1 lábakat 1-be rakom.
Innen lábanként 40 mA kinyerhető és a rövidzár sem teszi tönkre a rendszert. Ahol lehet, úgy dolgozom, hogy ez a 40 mA a táp. Az AVR ISP MkII-höz 3x2-es tüskesor kell, míg ArduinoISP esetén simán összekötöd a szükséges lábakat, bármiféle tüskesor nélkül. Miután felprogramoztam az eszközt, az Arduino-t szimulátorként is használhatom, csak a programot cserélem le. Ugyanazzal az eszközzel tesztelek és programozok.
Sziasztok!
Készítettem próbapanelon egy órát 7szegmenses kijelzőkkel, ATtiny45, mcp23017 portbővítő és egy pcf8563 rtc-vel. Az a gond, hogy 23 óra után 21 jön, majd 29-ig nő és 10-re vált. Innentől megint jó éjfélig. Két gombal tudom állítani az időt, itt az óra és a perc is rosszul vált értéket éjfélkor. (24 és 60 helyett természetesen 0-t ítok az rtc-be). Próbáltam másik ilyen rtc-vel is, ugyan így működik. Ez a kód olvassa ki az időt illetve állítja be:
Nem tudom, hogy a kód melyik része okozza, esetleg az óra ic sajátossága lenne. Aki meglátja a hibát a programban vagy tapasztalt hasonlót, kérem segítsen. Előre is köszönöm! Iván
Egyszerűen arról van szó, hogy 23 után, ami 2 számjegyes, nulla jön, ami egy számjegyes, viszont az első számjeggyel nem csinálsz semmit, az változatlan marad. Tehát 23, 20, 21... 29 így fogja kiírni neked, aztán megint 2 számjegyes jön (10) és ezzel helyreáll a rend. Éjfélkor kezdődik elölről
Ez alapján már gondolom ki tudod javítnai.
Jobban megfigyeltem az éjféli váltást és észrevettem, hogy 23:59 után megint 23:59 jön, majd 21:51. A második 23 óra 10 perckor a perc, illetve reggel 10-kor az óra is helyre áll. Tehát éjfélkor, de csak ekkor az óra és a perc is elromlik. Az rtc amúgy binárisan kódolt decimálisként tárolja az időt, ezt alakítom vissza a 6. és 11. sorban. Én csak kiolvasom és kiírom a számokat, a növelésük az rtc feladata, így most sem értem miért hibázik ilyenkor.
Valamilyen ellenőrző algoritmussal lehetne korrigálni a hibát, de az rtc lényege az lenne, hogy megmondja a pontos időt.
Sziasztok!
Elkezdtem AVR-ekkel foglalkozni és az ATtiny45-20PU processzor amit kaptam szerintem hibás. A probléma az, hogy amikor az egyik lábat kimenetre állítom, és felhúzom magas szintre,LED-et rákötök és gyakkorlatilag villog, ahelyett hogy folyamatosan világítana. Míg egy másik ATtin45 -re töltve a programot helyesen működik. A pogram:
Másik programra is ugyan olyan sebességgel villog a led. A _delay_ms(100); nak semmi hatása, míg a másik AVR-nél úgy működik ahogy a nagykönyvben meg van írva
A kérdés, hogy ez így kuka? Vagy van esetleg megoldás erre? Válaszokat előre is köszönöm!
A konfigurációs bitek is azonos módon vannak beállítva? Csak azért, mert pl. egy WDT miatti állandó resetelés miatt pont így viselkedhet.
Sokat konnyitene a debuggolason, ha az RTC-bol kiolvasott BCD erteket iratnad a kijelzore hexa szamkent. Akkor rogton latnad, hogy az RTC rontja el, vagy valami a konverzio korul nem jo. Bar utobbi ranezesre jo.
Nem ismerem ezt az RTC-t, de nem lehetne egyszerre kiolvasni a percet es az orat? Ezm indenkeppen tanacsos, mert amikor eppen valt a perc es az ora is, akkor elofordulhat, hogy meg a valtas elotti orat olvasod ki, es melle a valtas utani percet.
Sajnos ezt most nem fogom tudni megmondani, ugyanis sikerült kitiltanom magam. Jövőhéten újraélesztem, ha tudom és megnézem.
Kipróbáltam egy mega8-al (Fleury féle i2c könyvtárral), uarton írtam ki és jól működött. Ugyanazt a konverziót használtam, így annak jónak kell lennie. Megprbáltam a while elején kiüríteni a buffert, de nem változtatott rajta. (A tiny45-n Doctek USI_TWI könyvtárát használom)
A hozzászólás módosítva: Szept 23, 2014
De pont az lenne a cel, hogy azon a processzoron debuggold, ahol nem mukodik, nem? Meg akarod tudni, hogy hol a hiba. Hát lepesrol lepesre kell keresni. RTC, i2c kezeles, konverzio, breakup() fuggveny. A breakup-ot konnyen tudod tesztelni, mert egyszeruen meghivod konstanssal. Abbol latod, hogy jol mukodik-e. A konverzio szerintem jo. Az i2c-hez nem tudok hozzaszolni, soha nem hasznaltam masok driver-eit, ezt sem ismerem. De nem hinnem, hogy a 23-mat jol olvassa ki, de utana a 0-t nem. Persze minden lehet. De azt mindenkeppen javaslom, hogy az orat es a percet egyszerre olvasd ki. Ezt javasolja az adatlap is.
Egy gombsort olvasok be ellenállásosztóval egy ADC-n keresztül. Milyen gyakran érdemes a konverziót végezni, hogy ne akassza meg indokolatlanul gyakran a program futását, de azért lehetőleg ne vesszenek el gombnyomások?
En olyan 20-50ms korul szoktam. 100ms mar elveszithet rovid megnyomasokat. 20ms-nel surubben nincs ertelme.
Szia!
Nem pont a kérdésedre válaszolok, mert az elég erőforrás igényes, hanem egy alternatív megoldást vázolnék. (lásd mellékelt rajz) Megoldható, hogy egy logikai FET gate-jére megy az ellenállás osztó pontja, ahova az ADC-re is csatlakozik. Alap esetben GND-n van ez a pont az osztó alsó ellenállása miatt. A gombok megnyomásakor megemelkedik a potenciál, aminek hatására kinyit a FET és valamelyik lábat lehúzza L-re, aminél előtte be volt kapcsolva a felhúzó ellenállás. A valamelyik láb lehet az INT0, INT1, vagy olyan amelyiken értelmezett a PIN CHANGE INT. Ez a módszer különösen akkor jó, ha a uC sleep-ben használod, mert ilyenkor gombnyomásra "felébred" és akkor le lehet kérdezni, melyik gombot nyomták meg. Arra kell figyelni, hogy az ellenállásokat úgy kell megválasztani, hogy a FET minden gomb lenyomására kinyisson
Miert eroforrasigenyes az, hogy 20ms-onkent beolvasod az A/D utoljara mert erteket, es elinditod ujra? Ez kb. 10 utasitas.
Sziasztok!
Csak azt szeretném tudni hogy az ATTINY2313 és a 2313A között van-e különbség. Nem írni akarok rá programot,csak egy hex filét égetnék bele stk500-al,a rajzon sima van, a fiókban meg A-s. Köszi
Sziasztok!
Tudnátok nekem segíteni abban, hogy megépítettem ezt a kapcsolást Bővebben: Link beégettem az Attiny2313-ba az oldalon levő hexet de nagyon lassan működik reagál a változásokra. Valószínű, hogy a fusebitek nincsenek jól beállítva, vagy az órajel, azt írják, hogy belső 8MHz-en megy a progi. Elvileg ez az alapbeállítás a 2313-nak ha jól tudom. Nem tudtam kihámozni, hogy a low meg high fuse biteket mire állítsam ha így nem tökéletes. Előre is köszönöm ha valaki segít!!
Köszi! Úgy jó szerinted, hogy timerrel mérem a 20 ms-t (amúgy is van ilyen időzítésű timerem szervo miatt), és amikor eléri, csinál egy megszakítást, a megszakításban elindítom a konverziót és amikor elkészült az is csinál egy megszakítást, amiben megnézem a kapott értéket és beteszem egy változóba, amit majd a főprogram értékel ki?
|
Bejelentkezés
Hirdetés |
