Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
 
Témaindító: pakibec, idő: Márc 11, 2006
Témakörök:
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
Lapozás: OK   521 / 840
(#) karika200 válasza Istvanpisti hozzászólására (») Feb 25, 2013 /
 
Igen, jól értetted, a MAX232 11-es lába volt a mega 2-es lábán. Tehát Rx-Rx Tx-Tx volt a bekötés. Most felcseréltem őket a javaslatod szerint. Némi változás van, de még nem az igazi. Mostmár a terminálon billentyűleütésre visszajön valami karakter(sorozat). Csatoltam egy képet, amin egyetlen gombnyomás eredménye látható(Nyomtam egy A betűt).
A hozzászólás módosítva: Feb 25, 2013

terminal.JPG
    
(#) Istvanpisti válasza karika200 hozzászólására (») Feb 25, 2013 /
 
Szerintem nem állítottad át az órajel forrását külső kvarcra, hanem belső RC oszcillátoron van (ez a default 1 MHz), emiatt a sebesség nem jó.
A mellékletek alapján próbáld beállítani (external crystal-ra)
Ha nem vagy valamiben biztos, akkor ne állítsd át. Kicsit furcsa a logikája a fuse biteknek, azok a nullák, amik be vannak állítva és azok 1-ek, amik nem programozottak.
(#) karika200 válasza Istvanpisti hozzászólására (») Feb 25, 2013 /
 
Valóban! Ez lesz itt a gond. Ha jól veszem ki az adatlapból, akkor az alsó fuse legyen 0xcf a felső pedig maradhat 0xd9.
(#) karika200 válasza Istvanpisti hozzászólására (») Feb 25, 2013 /
 
Köszönöm a segítséget neked és a többieknek is! Két alapvető hiba volt. A fuse bitek és a fordított bekötés. Az alsó fuse-t átírtam 0xCF-re és meggyógyult, ksözönöm!
(#) ThompsoN hozzászólása Feb 26, 2013 /
 
Sziasztok.

Adódott problémám. Késleltetéseket szeretnék a programba tenni, de a valódi késleltetésnek a programban lévő számhoz köze sincsen. Beállítottam, hogy 2500msot késeltessen, de kb. 0,1s múlva már tovább is lép az MCU.

Íme a program:
  1. #ifndef F_CPU
  2.         #define F_CPU 1000000UL
  3. #endif
  4.  
  5. #include <avr/io.h>
  6. #include <util/delay.h>
  7.  
  8. #define DELAY_MS 2500
  9.  
  10. void delay_x_ms(int ms) {
  11.         for(int i = 0; i < ms; i++) {
  12.                 _delay_ms(1);
  13.         }
  14. }
  15.  
  16. int main() {
  17.         /*Lábak konfigurálása*/
  18.         /*Timer konfigurálása*/
  19.  
  20.         delay_x_ms(DELAY_MS);
  21.  
  22.         for(;;) {
  23.                 /*Kimenet állítása*/
  24.         }
  25. }


Csak azt hagytam bent, mai a problémához kapcsolódhat. A lényeg az, hogy a DELAY_MS konstansban szereplő értékhez köze sincsen a valódi késleltetésnek.
A dolog érdekessége, hogy korábban még jól működött.
(#) csabeszq válasza ThompsoN hozzászólására (») Feb 26, 2013 /
 
AVR-gcc-t használok, ott nem lenne baj, de ahogy a lap tetejét olvasod:

Idézet:
„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”


Emellett még javaslom az F_CPU átnézését is. Ha gyorsabban megy a proci, akkor szintén előfordulhat ez.

A lefordított assemblyből sokminden kiderülhet.
Nem 16MHz-n pörög véletlenül?
A hozzászólás módosítva: Feb 26, 2013
(#) ThompsoN válasza csabeszq hozzászólására (») Feb 26, 2013 /
 
Én is AVR-GCC-t használok. 1MHz-re van állítva. Azért vagyok teljesen tanácstalan, mert tegnap még működött, és ma a programnak csak másik részén változtattam.
(#) csabeszq válasza ThompsoN hozzászólására (») Feb 26, 2013 /
 
mint8-at ugye nem használsz (az int 8 bites lesz)?
a CKDIV8 fuse-t nem kapcsoltad ki?
(#) ThompsoN válasza csabeszq hozzászólására (») Feb 26, 2013 /
 
Az elsőt nem tudom, hogy mi, így feltételezem, hogy nem. CKDIV8 ki van kapcsolva. Ha be van kapcsolva, akkor nem is tudom az MCU-t programozni.
(#) Müszi hozzászólása Feb 26, 2013 /
 
Sziasztok!

Összeraktam ezt a kapcsolást: Bővebben: Link, de sajnos nem működik megfelelően. Csak a benti hőméréskletet méri, kb 5 másodpercig (eddig rendben is lenne), utána semmi életjelet nem ad. Csak akkor működik ujra, ha tápot kap, de akkor is csak az egyik szenzor hőméréskletét írja ki? Szerintetek mi lehet a gond? ÉN hibás égetésre tippelek, mert a panelen a feszültségek, és a szenzorok bekötései mind stimmelnek.

üdv: Müszi
(#) Fish hozzászólása Feb 26, 2013 /
 
Sziasztok!

ATTiny13 segítségével szeretnék készíteni egy időrelét, és ezzel kapcsolatban lenne egy kérdésem. Azt olvastam az adatlapon, hogy ennél a vezérlőnél az ADC0 és a RESET láb ugyanaz, és az adatlap szerint ha ezt a lábat 2,5us-nél hosszabb ideig alacsony szinten tartom, akkor generálódik egy RESET. Ez esetleg azt jelenti, hogy ha ezt a lábat ADC-ként akarom használni, akkor nem tudok rajta 0...5v közötti feszültséget figyelni? köszi a segítséget.
(#) blackdog válasza Fish hozzászólására (») Feb 26, 2013 /
 
Attól függ mire szeretnéd használni azt a lábat. Ha ADC bemenetként akkor inicializáláskor a megfelelő bit-ek beállításával megadod, hogy az ADC bemenet és megszűnik RESET lenni.
(#) Fish válasza blackdog hozzászólására (») Feb 26, 2013 /
 
Oké. Köszi
(#) sikolymester válasza blackdog hozzászólására (») Feb 26, 2013 /
 
Ezt hol lehet az adatlapban fellelni?
Gyanúm szerint ez csak fuse -zal lehet beállítani.
(#) sikolymester válasza ThompsoN hozzászólására (») Feb 26, 2013 /
 
Nem volt valahol mégis már definiálva az F_CPU?
Mondjuk a make fileban compiler switch-ként.
(#) Fish válasza sikolymester hozzászólására (») Feb 26, 2013 /
 
Szia!

Vagyis ez azt jelenti, hogy hiába konfigurálom fel az ATTiny13 egyes lábát ADC0-ként, ha ide 1,8v alatti feszültség kapcsolódik, 2,5us-nél hosszabb ideig, generálódhat RESET?
(#) ColT hozzászólása Feb 27, 2013 /
 
Hello!

Nem találok jobb topicot...

Arduino+Ds18b20 párosítás, és a DS hülyeségeket ad vissza A higanyos hőmérőm sem pontos, de a DS hol 3, hol 5 fokkal magasabbat mér. (26 fok meg nincs a szobában, csak észrevenném )
A furcsa az, hogy amíg az áramkör USB-ről ment, más volt az eltérés, mint a saját tápjáról.
A Ds18 meg elvileg kalibrálva van.
Mi okozhatja az eltérést? És mit lehet vele kezdeni?

A szenzor amúgy 5V-ot kap (4,93), a tápfeszt 4,94V-nak mérem, a szenzor adatlábát egy 4,7k-val húztam tápra. Az ellenállás közvetlenül a szenzor mellett van.

Köszi bármilyen segítséget
(#) sikolymester válasza Fish hozzászólására (») Feb 27, 2013 /
 
Véleményem szerint igen. Mi több: nem is működik ADC lábként, amíg a fuse biteket nem piszkálod meg. Utána viszont már nem fogod programozni sima programozóval.

Amúgy az adatlapot kéne áttúrni, vagy csak próbálj villogtatni ledet rajta, akkor kiderül lehet IO lábként használni.
A hozzászólás módosítva: Feb 27, 2013
(#) sikolymester válasza ColT hozzászólására (») Feb 27, 2013 /
 
És az offsetet stabilan hozza, vagy ugrál a hőmérséklet?
Nem csak rosszul számolod ki a hőmérsékletet?
(#) blackdog válasza Fish hozzászólására (») Feb 27, 2013 /
 
Bővebben: Link
Kicsit felületes volt a válaszom. Bocsi!
(#) sikolymester válasza blackdog hozzászólására (») Feb 27, 2013 /
 
Itt sem derül ki explicit módon, hogy nem fog resetelni, hogyha alacsony lesz a reset láb.
Én nem javasolnám a használatát ADC bemenetként.
(#) csabeszq válasza sikolymester hozzászólására (») Feb 27, 2013 /
 
Én abban a hiszemben voltam, hogy az AVR-eknek ez a pinje vagy RESET, vagy IO.
Ha IO, akkor nem RESET, ezért nem tudod programozni SPI-n sem.

Amikor meg RESET, akkor pedig nincs IO. Idáig egyetlen olyan megoldást sem találtam, hogy valaki outputra rakná a RESET pint, aztán 0-ra állítja a szoftver RESET-hez. Helyette a watchdog-gal idétlenkednek, ami valljuk be sokkal macerásabb.

Nekem egyenlőre érthetetlen, hogy az ADC-nek mi köze a RESET logikához, meg hogy hogyan zavarna be a 0V az ADC lábon, amikor programozni sem lehet RSTDISBL után. Persze ha tévednék javítsatok.
(#) zombee válasza csabeszq hozzászólására (») Feb 27, 2013 /
 
RSTDISBL ki: az IC-t tudod ISP-n programozni, I/O lábként nem lehet kapcsolgatni,
persze az ADC ettől még mehet csak ne adj rá 3V-nál kisebb feszt!
RSTDISBL be: használhatod I/O lábként, ADC-re is beállíthatod, de ekkor programozni
csak nagyfeszes cuccal lehet!
A hozzászólás módosítva: Feb 27, 2013
(#) karika200 hozzászólása Feb 27, 2013 /
 
Üdv!

Egy ATMega8-al szeretnék hangot generálni. Végső soron DTMF és/vagy távíró(morse) kódokat kellene előállítanom. Elgondolásom a következő a megvalósításról, de szeretném a hozzáértők véleményét kérni: Ha jól gondolom PWM-re lesz szükségem. Mondjuk kinevezem az MCU 14. lábát(PB0) és itt állítok elő szinusz hullámot aminek a frekvenciáját kedvem szerint változtatom. Viszont ezt a jelet nekem egy mikrofon bemenetre kellene kötnöm. Hogyan kellene ezt szépen megvalósítani hardware szempontból? Illetve szoftveresen az elgondolás helytálló-e?

Ha hülyeségeket beszélek szóljatok, sajnos nem igazán vagyok otthon a témában. Van egy két apró feladat, amit szeretnék megvalósítani ATMega segítségével tanulás célzattal. Többek közt ez az egyik.

üdv, karika200
(#) zombee válasza karika200 hozzászólására (») Feb 27, 2013 /
 
A hardveres illesztéshez: Bővebben: Link

PWM az lehet, de nem mindegy hogy milyen! Szinuszt nem fogsz vele előállítani, vagy ha igen az nagyon messze fog állni a szinusztól. Esetleg DAC-vel játszhatsz, vagy egy R-2R létra is megteszi.
A DTMF-t lehet négyszögjellel is emulálni, de ha nagyon tárcsázgatni akarsz telefonvonalon
akkor azt pulse módban is megteheted: ezerszer egyszerűbb, és ehhez csak egy relé kell...
A hozzászólás módosítva: Feb 27, 2013
(#) karika200 válasza zombee hozzászólására (») Feb 27, 2013 /
 
Köszönöm, akkor a hw rész megoldva 2 ellenállással. Igaz is, négyszög jel lesz az amit írni akartam.. Akkor már csak annyi(hogy ne szivassam magamat), hogy a fent említett pl. PB0 láb tökéletesen alkalmas a feladatra? Mivel 8 bites lábról van szó, ezért gondoltam erre.

szerk.: Még csak relé sem kell! Rádiós felhasználásra lesz a dolog. Az AVR egyenesen egy adásra kapcsolt rádió mikrofon bemenetére dolgozik majd.
A hozzászólás módosítva: Feb 27, 2013
(#) zombee válasza karika200 hozzászólására (») Feb 27, 2013 /
 
A PB0 az ICP, és nem PWM láb! A PB3-ra gondolhatsz, ez a 2-es timer(8 bites) PWM kimenete.
(#) karika200 válasza zombee hozzászólására (») Feb 27, 2013 /
 
Köszönöm!
(#) ColT válasza sikolymester hozzászólására (») Feb 27, 2013 /
 
Stabil offset elvileg. Ahogy elnéztem, a feszültség változásától függött, pedig az adatlap szerint nem függhetne...
A hőmérséklet számolását library végzi, amit a DS-hez javasoltak ar arduino.cc -n.
Azóta olvasgattam, egyesek a felhúzó ellenállás növelését javasolták, mások a kiolvasás ritkítását, merthogy a túl gyakoritól melegszik az IC... WTF...?
A hozzászólás módosítva: Feb 27, 2013
(#) csabeszq válasza zombee hozzászólására (») Feb 27, 2013 /
 
Hát, 8 bites timer hanggenerálásra bizony bátor húzás.

Persze ha egyébként sincs hallásod, vagy ha régebben sem zavart, amikor a kazettásmagnó kicsit húzta a zenét, akkor jó.



UI: Bocs, most olvasom, hogy szinuszt akarsz PWM-mel csinálni, aluláteresztő szűrővel. Így már van némi remény, de legalább 16-20 MHz-re pörgesd fel az IC-t, mert semmi mással nem fog foglalkozni, mint a PWM impulzusszélességének állítgatásával.
A hozzászólás módosítva: Feb 27, 2013
Következő: »»   521 / 840
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem