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
Én fényérzékeny ellenállással mértem.
2k ellenállással sorbakötöttem egy fényérzékeny ellenállást, a közepe ment az ADC-re.
Ha jol értem akkor a SIMA led amit vettem azt forditva kötöm be akkor érzékeli a fényt és áramot ad le? lehet Noob kérdés ADC az az AVR ben van benne ugye? (most köveznek meg sokan).
ATTINY45-20PU van ADC de Attiny 2313 ban meg nincs:/// pont az utobbival fejlesztek  hurrá. A hozzászólás módosítva: Jan 23, 2013
Fogj egy multimétert, kösd rá a LED-re(feszmérés), majd fordítsd jobbra-balra, fény/árnyék felé.
Amit látsz(vagy épp nem látsz) a multiméteren, mindenre választ ad ami a LED-et illeti. AVR: pontosan, a t2313-ban nincs ADC, a t45-ben meg van. Elsőre szivacs, aláírom. Szerezz be egy ATMega8-at, most nagyon olcsón dobálják(itt az aprón is árul valaki ~3-500Ft-ért). Ha mindenképp t2313, a legegyszerűbb ha az analóg komparátort használod. Statikus mód: a komparátor egyik bemenetét egy potival beállítod, a másikra megy a LED. A komparátor kimenetén(ACSR regiszter ACO bit) azt látod, hogy a beállított értéknél nagyobb/kisebb fény éri a LED-et. Dinamikus mód: a komparátor egyik bemenetére kötsz egy kondit, a másik bemenetén ugyanúgy LED. Egy másik portlábbal felhúzod a kondis lábat, közben méred az időt, amíg a komparátor átbillen. Az eltelt időből kvázi-kiszámítható a LED feszültsége. Ezután kisütöd a lábat, és újrakezded. A hozzászólás módosítva: Jan 23, 2013
egyszerűbb ha az T45 öm méri a ledet és az ad Jelet a Attiny 2313 omnak.két AVR között lehet adatot küldeni? pl: T45 ön int valami = 2 és ezt át küldeni a T2313 ba?
HB-1025-MR-2C ez a fajta led kel ugye? Bővebben: Link
Nem értem miért vergődsz ennyit ezekkel az MCU-kal. Miért nem veszel olyan AVR-t ami a célnak megfelel. Bár a pontos célt sem írtad le csak, hogy "világosság" mérés. Mert amit akarsz az ennyi nem több.
Fotoellenállás lenne a te barátod. Amúgy javaslom ezt a cikket: Bővebben: Link
Hát, én egyre inkább azon a véleményen vagyok, hogy a célnak megfelelő DIP-es AVR az ATtiny13, az ATmega48, vagy az ATmega328P.
Gondolom nem véletlen, hogy az ATmega48 a legolcsóbb az összes IC közül. Az Atmel gondolom szűkíteni akarja a termékkészletét, ezekből gyárt rengeteget, ezért ezek az olcsók, a többit meg megpróbálja szépen lasssan az árpolitikájával kivezetni. Legalábbis nekem nagyon úgy tűnik.
Sziasztok!
Egy távirányítós autó építésén dolgozom, és egy USB-s gamepad-ból szeretném hozzá megépíteni a távirányítót. Örülnék viszont annak, ha nem kellene kibelezni a gamepadot, hanem az közvetlenül AVR-el (ATmega8 vagy 328) kommunikálna. Ez azért is lenne jó, mert ha később egy másik kontrollerrel szeretném vezérelni akkor nem kellene azt is szétszedni. Ehhez gondolom egy USB hostot kellene megvalósítani AVR-ben, amit neten hosszas keresgélés után sem találtam. Csinált már valaki hasonlót, esetleg van valami egyszerűbb megoldás? PC-n figyelve a gamepad folyamatosan ugyan azt a byte sorozatot küldi, benne a gombok, karok állását. Valamint csatlakozáskor egy nagy adag információt.
Kell egy AVR, ami hardveresen viszi az USB-t. Szoftveres USB host nincsen rájuk.
Ez gyakorlatban az AT90USB647 vagy AT90USB1287. Majd nézz itt körül: LUFA Van HID host projekt, azt kicsit át kell írnod és kész is vagy. A hozzászólás módosítva: Jan 24, 2013
Hali mindenkinek!
Van esetleg köztetek kecskeméti illetőségű segítőkész emberke, akinek van olyan programozója, amivel vissza lehet hozni egy félhalott ATMega16-t az élők világába? HVPP? Üdv Kiborg A hozzászólás módosítva: Jan 24, 2013
Hali!
Én is hasonló projekten dolgozom. Én egy régi analóg (GAME PORTOS) joy-t kötöttem egy Mega16 ADC-jére. Viszont az a problémám, hogy eléggé zajos a benne lévő 100kohmos poti. Kis elmozdulásra is nagy feszültségváltozás jön létre, ezért nem volt az igazi. Cseréltem 25k-s potira, javult, de nem az igazi. A rendes távirányítókban 5ks poti van. A célre nekem jobban megfelelt a joy, mert gamepadnál sokkal kisebb a poti mozdulása, nagyon érzékeny lesz. Szerintem legalábbis. Mivel oldod meg a rádiós átvitelt? Üdv Kiborg
Szia!
Egyenlőre nekem is így van megoldva, hogy kivezettem az analóg kar potijainak lábait, és ADC-vel dolgozom fel azok állását. A Gamepad-ben amit használok 5kOhm-os potik vannak, viszont tényleg nagyon érzékeny. Nem kell sokat mozdítani, hogy a végső állásban legyen. Az átvitelt egy 868Mhz-es RFM01 és RFM02 adó-vevő párral oldottam meg. Ez az első rádiós adatátvitelt igénylő projektem, így a biztosra menve vettem egy ilyen párt hestore-ból. 1-2 órát szenvedtem vele mire működésre bírtam, de az adatlapokon levő mintapélda jó kiindulásnak.
Elképzelhető, akkor amit mondasz.
Ráadásul a Tiny26 nem túl gyakori típus, inkább ipari felhasználásnál találkozni vele.
A lábkiosztása és a Timer is teljesen különbözik a többitől, ez az IC hobbicélra szívás.
http://www.engbedded.com/fusecalc
Konkrétan nem értem a dolgot, mert az első esetben kellene téged kitiltani, a másodikban pedig 4 MHz-n menne az IC. Ennek éppen a fordítottját írtad. Szerintem egyébként egy 50%-os PWM-mel az XTAL1 lábon életre kelthető lenne az IC. A hozzászólás módosítva: Jan 25, 2013
Az elsőt már többször égettem és midig jó volt , a második soha. Volt amikor az égető a másodikhoz tartozó hex-et nem olvasta be de egy rendszer-visszaállítás után beolvasta(igaz-még nem tudtam ellenőrizni a működést mert a kész áramkörben nem csinál semmit).
Az XTAL-ra 4MHz sem vezetett eredményre.
Sziasztok!
SPI-n keresztül kommunikálnék egy MCP3202 ADC ic-vel!ATmega8 használok belső 8Mhz órajellel! Az lenne a bajom hogy az spi-n sikerül lekérdezni az eredményt UART-on kiiratom de viszont 8-10 van amikor 2-3 lekérdezés után megáll (szerintem) a kommunikáció valami olyasmi lehet hogy nem érkezik meg a megfelelő számú bit és a while ciklusban míg várom át megy végtelenbe mert elszáll a kommunikáció! Egy külső reset vagy watchdog után szintén elküldi egy párszor és szintén megáll! Szerintetek bár nem hiszem hogy szoftveres baj lenne esetleg valaki találkozott-e spi kommunikáció során ilyen problémával! Köszönöm!
Sziasztok!
ATXmega128D3 boot szekciójában hozok létre egy ugrótáblát, amely tábla, függvények belépési pontjára mutató ugró utasításokat tartalmaz. A tábla pici assembly forrásban van definiálva jmp utasítások sorozataként. A problémám, hogy a fordító a "közeli" címekhez rjmp (2 bájt), míg a távoli címekhez jmp (4 bájt) utasítást fordít. Hogyan lehetne rákényszeríteni a fordítót, hogy minden esetben jmp utasítást használjon? - de az is jó lenne, ha az rjmp után berakna egy nop-ot, a lényeg, hogy 4 bájtot foglaljon egy ugrótábla elem, mint pl. a megszakítási vektortábla esetében. Köszönöm!
Sziasztok!
Szeretnek epiteni egy ermes idozito aramkort ami ugy mukodik hogy a penzvizsgalo szerkezetbe beledobok egy ermet es ad egy inpulzust ez elindit egy idozitot ami bevan allitva egy bizonyos idore. Eddig en is eljutottam de ugy kellene megoldani hogy az ido alatt amig az idozito szamol bedobok meg eggy ermet a beallitott X ido hozza adodjon a meg hatralevo idohoz . Probaltam az aramkort szimulacios programmal megtervezni de mindig volt benne valami hiba aminn elakadtam . Akinek volna valami hasznalhato otlete vagy mar epitett ilyesmit az segithetne nekem . Mikroprocesszoros megoldas lenne a legjobb szerintem csak kene hozza program is. Elore is koszonom a segitseget .
Csak a tisztánlátás végett, ugye AVR GCC -t használsz?
Amúgy ha innen nem lesz válasz, akkor javaslom túrd fel az avrfreaks.net -et. Ott laknak a hardcore AVR geekek .
Nagyon egyszerű megírni hozzá egy programot, és egy ilyen feladatot csak uC-rel lehet megoldani. Ajánlom az AVR-t olvass el pár cikket itt vagy könyvet valamit és 2 nap tanulás után magad is meg tudod írni. Ez a topik teljesen felesleges mivel bármilyen mikrovezérlős topikban elfért volna ezért záratom.
Üdv!
Igen, avr-gcc-t. A forrás, amelyen dolgozom c nyelvű, csak az ugrótábla szekciót tartalmazó kód assembly.
A fordításkori -relax elhagyása nem oldotta meg. Most az assembly kódban kísérletezem - .align nem segített, az .align 4 2 db nop-ot szúrt be egy helyett - az .if direktíva utáni kifejezésben pedig nem akarja elfogadni az és-t (&): jmp fn_1 jmp fn_2 .if (. & 2 == 2) nop .endif jmp fn_3 de most látom, hogy ez 0, 4, 8 címek esetén nem lenne jó.  Valahogy tudnom kellene az előzőleg lepakolt utasítás címét és akkor már lehetne számolni vagy esetleg bekérni az operandust és megnézni, hogy rjmp-e... Minden ötletet szívesen fogadok, köszönöm.
Sziasztok!
SPI-n keresztül kommunikálnék egy MCP3202 ADC ic-vel!ATmega8 használok belső 8Mhz órajellel! Az lenne a bajom hogy az spi-n sikerül lekérdezni az eredményt UART-on kiiratom de viszont 8-10 van amikor 2-3 lekérdezés után megáll (szerintem) a kommunikáció valami olyasmi lehet hogy nem érkezik meg a megfelelő számú bit és a while ciklusban míg várom át megy végtelenbe mert elszáll a kommunikáció! Egy külső reset vagy watchdog után szintén elküldi egy párszor és szintén megáll! Szerintetek bár nem hiszem hogy szoftveres baj lenne esetleg valaki találkozott-e spi kommunikáció során ilyen problémával! Köszönöm!
Én stack túlcsordulásra tippelek.
Nem lehet hogy a -w fordítási opcióval kellene kísérletezni (-w Relative jumps are allowed to wrap for program ROM up to 4k words in size [ignored]) ? Az .if meg szerintem itt azért nem működik, mert a fordító még nem tudja hogy milyen címre kerül az utasítás, azt majd a linker fogja eldönteni.
Igaz, a fordító valóban nem tudja még a pontos címet (majd a linker fogja tudni a linker script alapján vagy -Wl,--section-start= kapcsolókból), de minden szekció esetén használ egy location countert, amely nulláról indul és minden kompilált item esetén annak hosszával növekszik az értéke. Ebből következik, hogy az általam említett .if (. & 2 == 2) kifejezést ki tudja értékelni és jó eredményre is jut, csak a linker az object fájlban elhelyezett infókat felülbírálja. Ettől függetlenül az előző kifejezés, mint írtam is, nem lenne megoldás a problémára, mert minden második esetben hibás eredményt produkálna.
Viszont próbáltam, hogy címkét helyezek az utasítások elé és az aktuális location counter (. jel) és a címke közötti "távolságot" mérem és ez alapján helyezem el a töltelék nop-okat, de ez sem segített, pedig ennek, véleményem szerint, jónak kellene lennie: lfn1: jmp fn_1 .if (. - lfn1 < 4) nop .endif lfn2: jmp fn_2 .if (. - lfn2 < 4) nop .endif és így tovább (mindezt persze makróba lenne érdemes tenni), de a fenti megoldás esetén sem pakolta be a nop-okat az rjmp utasítások mögé, pedig az lfn_x labelek definiálásakor felveszik az aktuális location counter értékét, azaz a kivonásnak jó eredményt kell adnia... A linker persze itt is felülbírált/optimalizált. Node, a sok szöveg végén jöjjön az egyszerű megoldás. A linker optimization fül alatt bekapcsolva maradt az -mrelax kapcsoló. Ezt kikapcsolva már long jmp-ket fordított. Sajnos ott is, ahol fordíthatott volna rjmp-t, mert így nőtt a kód mérete. Idő hiányában most nem próbálgatom tovább, de izgat a probléma, mert pl. látom, hogy a libc forrásában lévő vektortábla esetén is hasonló (. - tábla_eleje > valami) makróval dönti el, hogy __bad_interrupt szimbólumra legyen-e kicserélve a megadott szimbólum, de nekem nem jött össze. Bocs, ha hosszú volt... >
Az assembly kodban hasznalj rjmp-t es a cimeket .org -al add meg. En igy csinaltam sajat kivetel- es megszakitaskezelot a 32bites AVR-re. Ime egy reszlet:
A hozzászólás módosítva: Jan 26, 2013
Köszönöm! Az org kézenfekvő, nekem mégsem jutott eszembe...
Ki is próbáltam. A __jumptable elejéhez relatívan képeztem az org-nak megadott új location counter értékeket: __jumptable: jmp fn_1 .org __jumptable + 1 * 4 jmp fn_2 .org __jumptable + 2 * 4 . . de mintha ott sem lettek volna, simán pakolta egymás után az rjmp utasításokat. Majd abszolút címként adtam meg az értékeket: __jumptable: .org 0x21F00 jmp fn_1 .org 0x21F04 jmp fn_2 .org 0x21F08 . . így pedig nem fordult le. Kifogásolta, hogy a .jumps szekció nem része a .text-nek, pedig a linker scriptben az alábbi módon vettem fel: .jumps : { __jumps_start = . ; *(.jumps) KEEP (*(.jumps)) __jumps_end = . ; } > text Majd kipróbáltam és beraktam a .fini szekciók után. Ekkor lefordult, de nem a megfelelő címre. (Némi magyarázat: Ez a jumptable a boot szekció végén helyezkedik el, elég messze a boot kódjától. A boot 0x20000-ben kezdődik, míg a jumptable 0x21F00 címen. Ezt az ugrótáblát az applikációs részben futó progi használja a boot részben található függvények meghívására: eeprom kezelés, self-programming, crc16 rutinok.) |
Bejelentkezés
Hirdetés |
