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
Ez a Topi-féle programozó JTAG programozó? Lehet, hogy hülye kérdés, de számomra nem egyértelmű.
Mert ha JTAG, akkor tetszik a dolog.  De látom, hogy fenntvan HEstore-n 4100-ért... ennyit nekem megér, és még a tyúk, vagy a tojás problémával sem kell foglalkoznom. Nah meg akkor be is tudok tankolni AVR-ekből is. Idézet: „Ez a Topi-féle programozó JTAG programozó?” A cikk neve: USB-s ISP programozó. Akkor számomra egyértelmű, hogy nem JTAG, hanem ISP. Sir-Nyeteg: Programozás közben a kimenetet rövidrezárva maximum a bufferek mehetnek tönkre. Mivel a kimenet le van választva a procitól. Volt már olyan, hogy írt nekem valaki hogy melegszik a processzor rettentően és hogy biztos szar a kapcsolás. Ott üvöltözött, már fenyegetőzött, hogy direkt rossz kapcsolást tettem fel, és neki ha kár keletkezik a gépébe beperel. Végén kiderült, hogy egy ón gombóc ment a kristály lábai alá és rövidrezárta az oszcillátort. Egy szó mint száz, a táp rövidrezárásakor a számítógép USB-je előbb kapcsol le, mint gond keletkezne, a kimenetek rövidrezárásakor előbb a puffer IC adja meg magát. Persze előfordulhat, hogy emiatt a puffer IC rövidzárat alkot a proci felé. Első körben, mindenféle képpen cserélném a puffer IC-t.
Ahha.
Én meghajlok tudásod előtt, de nem értem. ISP-->In Circuit Serial Programing JTAG-->Joint Test Action Group, nah ez nem mond sokat, de messze elhatárolom kategóriájában az ISP-től, mint fogalom. Eddig az volt a világképem, hogya a JTAG programozó=debugolni képes programozó. Szóval ez hogy is van? ISP programozó==>nem tud debugolni programozó?  Ha igen, akkor tudtok javasolni valami alapból USB-s, debugolni képes programozót? Esetleg, amit kiborg említett programozó Bővebben: Link egy USB-->soros port átalakítóval hobbi szinten 100%-osan megfelelhet nekem?
Ezt a pergésmentesítős témát jobban át kell még néznem. (Meg be is kéne ugranom a lomexbe pár marék kondiért)
Viszont itt van ez a megszakítás kezelő kód:
Most már szerintem jól kezelem le másik INT láb "lekérdezését", de továbbra is csak az egyik irányba számol. Mi lehet a gond? Tiny2313-ról van szó továbbra is.
Lehet hogy jó lenne az egy megszakítással lekezelt enkóder is, de szerintem ott a felfutó és lefutó éleket is figyelni kell.
Habár nem gondoltam át teljesen, de egy próbát megér. MOD.: Habár közbe átgondoltam... mégse, visszavonom amit mondtam. Program kódot így szúrj be: (code=c) kód (/code) természetesen szögletes zárójel
Egy ha nem 8 bites binális számot jelenítessz meg akkor egyszerűbb a debug-olás...
Led ki-be kapcsolásával kezdeném keresni a hibát valahogy így:
Lehetőleg az INT0-át kapcsold ki, csak elfelejtettem módosítani.
MOD.: ezt is módosítani kell, PORTB-t elírtam PORTD-re.
Szia!
Köszi az ötletet, ám nem igazán értem hogy mire gondolsz. Nekem úgy tűnik hogy az a baj, hogy az egyik INT-hez tartozó kódom valamiért sosem fut le, illetve - lehet hogy a rossz pergésmentesítés miatt - a másik láb lekérdezése ütközik gondba. Ejj, de jó lenne egy debugger! Egyébként szerintem is elég egy INT-tel lekezelni, ezt a két INT-eset csak végső elkeseredésemben csináltam (amúgy a rendes kódbeillesztést hogy csinálod?)
Az enkódered közös pontja +5 volton van, és a kimenetek ellenállással testra vannak kötve igaz?
kódbeszúrás: Bővebben: Link MOD.: egyik adatlapba 8ms pattogást láttam, tehát lehetne így is csinálni
Forditva van kötve, a közös pont van a test felé és a kimenetek felhúzva ellenállásal a tápra.
Gondoltam rá én is hogy ezt a pattogást sw-ből oldom meg. Esetemben ez is jó amit te mutattál, de talán nem célszerű blokkoltatni. Na, ezt majd kipróbálom. Most alig látok a fáradságtól. Köszi a tippeket, jó éjszakát!
a pergés / pattogásmentesítésre a következőt találtam ki:
INT kezelő rutinban tiltom a külső megszakításokat, majd inítok egy timer-t (t > t(pergés) ) ami pedig majd engedélyezni fogja azokat amikor lejárt. Nyilván ezt már mindenki kitalálta előttem
Puffer IC adta meg magát :yes:
Köszönöm! Most már van tartalék is. Amikor AVR stúdióban Szoftveresen csatlakoztatom az AVR-ISP programozót (kis AVR feliratú IC-gomb-ra klikk) akkor előjön egy ablak, ami megkérdezi hogy akarom-e upgradelni a szoftvert. Mi történne, ha az OK-ra klikkelnék? Kikapcsolható ez a kérdés?
Gyári kód van leklónozva, de az update lehetősége nincs benne.
Szóval ha az OK-ra kattintasz, annyi történik, hogy kiírja nem tudta update-elni.
Helló!
Nem akarok közbeszólni, mivel csak mostanság tanulmányozom az avr-eket. Viszont azt figyeltem meg, hogy a GIMSK regiszter úgy van beállítva hogy az INT0 interrupt is engedélyezve van, és az MCUCR regiszter pedig úgy hogy mind két INT felfutóélre van állítva. Nem lehet hogy úgy egyszerűbb volna egy rotary encodert lekezelni, hogy ha két megszakítást alkalmazunk akkor az egyik a felfutóélt a másik pedig a lefutást vizsgálja? ( ha jól emlékszem akkor erre keresitek a megoldást) Persze ez csak egy kevéssé hozzáértő hozzászólás, ötleteket próbálok adni illetve ihletet, nyugodtan kilehet javítani ha hülyeséget írok. Üdv
még egy megfigyelés: ha jól értelmeztem az interruptokat akkor a PD2 lábat nem kell megvizsgálni az interruptban, mivel maga a megszakítás a lábon történő változásra következik be!
ha egyre gondolunk, akkor: nem egészen.
a PD2-re az enkóder másik lába van kötve. Ezt azért kell megvizsgálni hogy tudjuk hogy melyik irányba van csavarva. Ez itt elég jól leírja.
ahha! így már értem a vizsgálat lényegét!
Meg lehet oldani egy AVR-nél, (pl atmega8), hogy ne lehessen kiolvasni, vagy pl írni, vagy csak én tudjam írni, pl valami jelszóval? Esetleg van egyszer-írható AVR?
Nézegettem, de annyira még nem tudok angolul, hogy a fuse bitek röviditéseit megértsem, vagy a többi menüpontot értelmezni tudjam. Köszi!
Van védelem AVR -re, ha a fuse biteket beállítod. Elég sok kombináció létezik. Mindenképpen elkéne olvasnod az adatlap Memory Programming/Fuse Bits bekezdését. Azért jó ha szem elött tartod, hogy magadat is ki fogod belölle zárni. Tehát a késöbbi program frissítés lehetetlen lesz, ha csak nem írsz valami okos bootlodert. Ami megfelelő ellenörzési protokol után frissíti a flash-t. Bár ha teljesen kiforrot végleges kódod van, akkor nem gond a frissítés hiánya.
A FuseBitek beallitasa:
Csak kiolvasas vagy kiolvasas + ellenorzes ellen veded. Biztosra mesz: 1, lock mind. 2, Disable Reset Bővebben: Bővebben: Link
Köszönöm!
A frissítés csak hardveres változtatással lesz célszerű a jövőben, és mivel smd alkatrészeket használok, így felesleges a frissítésre törekedni, azaz megfelelne az egyszer írható verzió is. Köszönöm! Nagyon jó a leírás!
Nem ertem ezt a levedes dolgot. Miert nem tudom beirni a lock biteket?
A fuse bitek irasaval nincs gond, tehat soft es programozo hiba kizarva, es megis:#378987
-Termeszetesen lezarja, csak visszaellenorizni mar nem tudja (es ott dob errort) - ez mondjuk termeszetes, csak nekem elsore nem volt az
Üdvözletem.
Lenne pár kérdésem, kezdjük ott hogy szeretnék egy gitárhangolót csinálni, amit találtam is ezen a honlapon pár lappal hátrébb, a mellékelt fájlban ott a c forráskód. már obj-be fordításkor hibák voltak benne: avr-gcc -g -Os -mmcu=attiny2313 -c Dokumentumok/gtuner.c In file included from Dokumentumok/gtuner.c:44: /usr/lib/gcc/avr/4.3.0/../../../../avr/include/util/delay.h:85:3: warning: #warning "F_CPU not defined for Dokumentumok/gtuner.c:50:1: warning: "F_CPU" redefined /usr/lib/gcc/avr/4.3.0/../../../../avr/include/util/delay.h:86:1: warning: this is the location of the previous definition A másik kérdés hogy a Center_Count-nál megadott értékek csak szerintem nem jók vagy más szerint se Kicsit jobban kifejtem: a hangot néztem mert ugye azt mindenki tudja hogy az a hang az 440 Hz, a többi hangot nem tudom. kiszámolva hogy 8kk/64/220 ~568,18 ami nem 440 Hz. tehát vagy én értelmezem rosszul ezt a programot vagy rosszul lett kiszámolva. Válaszokat előre is köszönöm
Most kezdtem AVR rel meg a C nyelvvel is foglalkozni.
Kezdeteknek az AVR STUDIO 4 -et gondoltam. Sajnos midjárt a kezdeteknél elakadtam azt nem értem hogy a mellékelt C programnak miért a mellékelt ASM az eredménye,vagy mit rontottam el ,hova tünt a "a" meg a "c" változó.A fordításra meg a újraépítésre is kattintgattam de sehogyan sem sikerült őket is bevenni a buliba.
Ehhez latni kellene a util/delay.h-t, de szerintem a #define F_CPU sort az #include
A frekvenciakkal meg semmi baj. A
Semmit nem rontottál el. A kód optimalizálás kavar be neked. Mivel az a és c változó értékeit semmire nem használja a programod így a fordító szépen kioptimalizálta őket, hogy anyival is gyorsabban fusson a kód. Ha pontosan azt szeretnéd, hogy leforduljon, mint amit begépeltél, akkor vedd le az optimalizálás szintjét :O0 -ra. A Projekt beállításainál
Köszönöm a választ, jó hogy ezt tisztáztuk mielőtt valamit módosítanék benne.
Viszont még egy kérdés, mivel nem 8 MHz kvarcot rakok bele hanem 9.8304MHz-est, ezért F_CPU megváltoztatom a számot, kérdés hogy máshol is kell e valamilyen beavatkozást eszközölnőm e miatt.
Vegigneztem a kodot es szerintem eleg csak az F_CPU define-t atirni a megfelelo ertekre. Viszont kivancsi vagyok, hogy tenyleg az volt-e a baj, hogy a #define F_CPU sor rossz helyen volt.
Idézet: „Ha pontosan azt szeretnéd, hogy leforduljon, mint amit begépeltél, akkor vedd le az optimalizálás szintjét :O0 -ra” Pontosan. Viszont, ha megis szeretned elvezni az optimalizalas elonyeit, de valamiert fontos, hogy egy valtozoval kapcsolatos muveleteket pontosan ugy forditson, ahogy leirtad, akkor a valtozot 'volatile' kell deklaralni: pl: int w; for(w = 0; w < 1000; ++w); sorok feltehetoleg az optimalizalas sullyesztojeben vegzik, de ha az irod, hogy: volatile int w; akkor a fenti for sort szepen beforditja, ahogy kell. |
Bejelentkezés
Hirdetés |
