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
Akkor nem hiszem, hogy a programmal van a gond. Inkább a konfigurációt kell átnézni.
Pl honnan tudod, hogy a DDR regiszterállítás megtörténik abban a bizonyos init(); függvényben? Mármint az MCU-ban
Csak sejtem, illetve, ha magába az init függvénybe, a DDR regiszterállítás után írom be azt, hogy PORTB=0xF0; akkor a ledek kivillannak. Úgyhogy helyesbítek, nem sejtem, hanem tudom. Az init() függvény lefut.
És mi van most ezzel az optimalizációs dologgal? Nem igazán értettem...
Miért nem jó neked a "-Os" ?
azért, mert bizonyos dolgokhoz nem jó az optimalizálás, vezérléshez, öszetetteb dolgokhoz. Ez még a kisebb baj lenne
de nagy programoknál optimalizálva is ez a hiba jön elő, 4-5 száz soros programoknál.
Lehet triviálisat kérdezek, de a függvényeket ugye rendesen deklarálod, pl. egy header fájlban?
A main() függvényed végére tegyél egy return 0-t, ha már egyszer van visszatérési értéke... Végezetül a linker opciókkal "játszottál" (mármint elállítottál valamit)? még annyit, hogy már fent van a legújabb WinAVR 20090314
a linker az nem igazán tudom micsoda, részleteznéd kérlek?
a többit úgy teszem/tettem, és a return itt lemaradt, de az eredet nagy programban nem.
A linker egy a fordítóprogrammal együttműködő program. Amikor megírtad a kódod akkor és azt lefordítod gép kód keletkezik, ez az *.o (object fájl). Ezeket az objektumokat fűzi össze a linker amiből létrejön maga a futtatható program.
ittenvan
esetleg ami fontos lehet, JTAG-el programozom.
Nem látom az órajel beállítását:
Ezt tedd bele a
Most benne van, de semmi hatás, ugyan az, mint eddig. én arra gondoltam, égetésnél lehet még a hiba.
paraméterek ahogy égetek: JTAG Biztik (ezekhez én nem nyúltam, alap beállítás): M103C pipa JTAGEN pipa SPIEN pipa BOOTSZ --> Boot Flash size = 4096 words start adress=0$F000 BODLEVEL --> Brown-out detection level at VCC=2,7V amit nem írtam, az értelemszeűen nincs kipipálva. Csatolom az új makefile-t
Kipróbálnál egy egyszerű LED villogtatást simán a main-ből?
Ja beugrott valami, nekem anno M128-nál gondom volt a mega103 kompatibilis mód miatt.
Ahogy látom Te abban vagy, de m128-ra fordítasz. Ez jelenthet még problémát. Az M103C mellől vedd ki a pipát, M128-ként használd. ui. lehet kompatibilis módban máskép kezeli az ugrásokat
Roppant érdekes az eredmény.
ezzel a kóddal helyettesítettem a main függvény taralmát:
akármit csinálok, csak az első for ciklus hajtódik végre, a második sose, kivéve persze, ha megint optimalizálom a fordítást. tudom, az időzítés elég bugyuta, és rövid, de skóppal mértem ki, hogy tényleg nincs jel csak a 0x40-es lábon (próbáltam más számmal is, akkor meg az világított).
Bocsi, ezt most olvastam. Így már tökéletesen működik, hogy kivettem azt a pipát. Köszi a segítséget, és a fáradtságot, hogy ilyen későn válaszolgattál nekem
 
Semmi probléma, bár kezdhettünk volna a fusebitekkel
Én szóltam h konfig hiba lesz 
énis gondoltam rá, de aztán elvetettem, azt gondoltam, alap beállítás biztosan jó. tévedtem, nagyot.
Adatátvitelt szeretnék megvalósítani hangkártyán keresztül. (A sebesség nem lényeges).
Azért hangkártyán mert ez a laptopomon az egyetlen normális benemet. (USB-t inkább nem programoznék, ágyúval verébre esete lenne). Az alapötlet az, hogy egy sima jackdugóval csatlakozom a hangkártyára. Az AVR pedig binárisa 1-0 sorban szépen elküldi. A kódolás programzás stb...stb... nem probléma egyik oldalon sem viszont, ha jól sejtem nem lehet csak úgy az egyik lábra (+5V) meg a földre rákötni szerencsétlen jackdugót. Valahol találtam már hasonlót ahol frekvenciát lehetett mérni, de nem most találom, hogy mekkora fesz és áramerősség mehet rá a jack-ra.
Én Schmitt-trigger-ben gondolkodnék, bár várj még, hátha más ötlet is jön.
Azt most nem tudom, hogy ez sebességben mit tud, de ha nem számít, akkor szóba jöhet.
Az 1-eket és a 0-kat mindenképpen le kéne kódolni valami impulzusokra, ugyanis a hangcsatornák általában nem DC-csatoltak. Gondolj bele, sok egyforma bit átvitele mit okozna, a vevő oldalon nem tudnád kitalálni, hogy azok most nullák-e vagy egyek. Szerintem nagyjából valami olyasmit kellene csinálnod, mint amit annak idején a kazettás magnókra történő mentéskor és visszatöltéskor csináltak a számítógépek, pl. a C64 vagy a Spectrum.
Üdv!
AVR belső oszcillátora mennyire stabil? (CKOPT bepipálva) Csináltam egy stoppert, később egy órát is majd akarok. Azt vettem észre, hogy a belső oszcillátor nem pontos. De ez kiküszöbölhető azzal, hogy pl a timert nem 50000-ig számláltatom, hanem mondjuk 50500-ig, és így az 1 mp tényleg 1 mp lesz  De ez egy járható út, vagy inkább külső kvarcot kéne használni? Az pontosabb és stabilabb? Vagy a belső is tökéletes lesz, ha egyszer belövöm a timer-t?Köszi!
A belső a hőmérséklet- és tápfeszültségfüggése miatt nem igazán alkalmas óraalapnak, ahhoz mindenképpen érdemes lenne külső kvarcot alkalmazni.
PIC-es tapasztalataim alapján azt kell mondjam, hogy a legpontosabb órákat a direkt óra célra tervezett, 32768Hz-es kvarcokkal sikerült csinálni (az egyik ilyen órám most áprilisban lesz egy éve, hogy folyamatosan jár - 3db AA elemről - és azóta még nem siet 2 percet). Persze ez a freki a program működéséhez lehet, hogy túl lassú lenne, ezt én PIC-nél úgy kerültem ki, hogy az óraalap (timer) ment a kvarcról, a CPU pedig a belső oszcillátorról. Azt hiszem, ilyen jellegű működést az AVR-eknél is elő lehet idézni.
Azert nezd meg hogy melyik megoldassal rovidebb a kod ( ha ez szamit).
Bocs a pontosvesszoert, avr-gcc nem szolt miatta, igy ott maradt..
Hmm...., ezt nem teljesen értem.
Na mind1 kipróbálom. Azt olvastam, hogy 0,7V-ot lehet maximum rákötni. Csinálok egy fesz-osztót, ha jól gondolom akkor egy 1K és egy 10K-s elég lesz az 5V-ra ekkor lesz 0,5V az 1-es a 0 meg 0 V. Bár az igaz, hogy nem tudom mit csinál mondjuk 1mp 1-es jelre. Akkor a wav file-ban is majd 1mp-ig valami magas jelet kapok?
Szilva kolléga jelezte, hogy a hangkártyák nem szeretik az egyenáramú komponenseket (AC csatolt).
Tölts le egy hangkártyás szkóp programot, és mérd meg a hangkártya bemeneti időállandóját. Pl logikai 1 szintet kötsz a bemenetre, és megnézed mennyi ideig marad kiértékelhető a logikai magas szint. Ezek után értelemszerűen úgy írod a programot, hogy ennél hosszabb ne lehessen egy logikai magas szint. Több 1-es átviteléhez, pedig impulzust kell használnod. Szerintem a legjobb lenne modulálni a digitális jelet és úgy átvinni. Idézet: „Hmm...., ezt nem teljesen értem.” Pedig egyszerű. Kell valamilyen moduláció, hogy a jel akkor is változzon, amikor csupa 1 vagy 0 jön egymás után. Fázismoduláció, frekvencia-moduláció vagy amplitúdó-moduláció. Mellesleg egy USB-soros átalakító egyszerűbb és hatékonyabb volna.
Sikerült életet lehelnem az asm i2c kommunikációba. Az egyetlen ami nem megy az a folyamatos olvasás eepromból, amikor nem kell újra címezni, csak olvasni. A gond, hogy én 125us-onként szerettem volna egy byte-ot beolvasni. Nekem 0-kat hoz így be. Ennyi idő alatt "elfelejti" az állapotát az eeprom? Próbált már valaki ilyet?
Ha stoppal lezárom és újra kiadom a konfig byte-ot és olvasom akkor megy. Ez a "CURRENT ADDRESS READ". Így is spórolok 3 byte-ot de még egyet spórolnék a "SEQUENTIAL READ" funkcióval.
Egy másik kérdés. Van arra lehetőség az AVR Studióban, hogy a szimuláció során átugorjon szubrutinokat? Azért kérdezem mert az i2c olvasást nem szimulálja, így ha az benne van akkor a progi többi részét sem tudom szimulálni. Nem lehet valami konstans visszatérő értékkel kijelölni rutinokat?
|
Bejelentkezés
Hirdetés |
