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   618 / 837
(#) killbill válasza Sick-Bastard hozzászólására (») Szept 13, 2014 /
 
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
(#) csabeszq válasza killbill hozzászólására (») 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
(#) killbill válasza csabeszq hozzászólására (») Szept 14, 2014 /
 
Idézet:
„Na ez az, gyakorlatilag fogalmad sincs róla, hogy mi történik.”
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.
Idézet:
„É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.”
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.

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 //
(#) csabeszq válasza killbill hozzászólására (») Szept 15, 2014 /
 
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.
(#) killbill válasza csabeszq hozzászólására (») Szept 15, 2014 /
 
Idézet:
„Maradjunk annyiban, hogy hobbi szinten AVR alatt többen használják a C++-t, mint a C-t.”
Egeszsegukre 20 eve a Basic stamp-et hasznaltak, mos ez a slager.
(#) csabeszq válasza killbill hozzászólására (») Szept 15, 2014 / 1
 
É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.
(#) burgdavid hozzászólása Szept 16, 2014 /
 
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
(#) csabeszq válasza burgdavid hozzászólására (») Szept 16, 2014 /
 
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
(#) brugo válasza burgdavid hozzászólására (») Szept 16, 2014 /
 
AvrDragon
(#) Massawa válasza brugo hozzászólására (») Szept 16, 2014 /
 
Én is a Dragon mellett teszem le a voksot. Nálam igen jol bejött.
(#) rolandgw válasza burgdavid hozzászólására (») Szept 16, 2014 /
 
Ha van LPT és nem akarsz túl sokat költeni,én ezzel kezdtem anno,most is jól működik:programozó,szoftver.
(#) csabeszq válasza (Felhasználó 15355) hozzászólására (») Szept 16, 2014 /
 
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.
(#) burgdavid hozzászólása Szept 16, 2014 /
 
Úgytűnik megoldódott a dolog HE-n belül

Köszi szépen!
(#) Ivan93 hozzászólása Szept 17, 2014 /
 
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:
  1. while(1)
  2.         {      
  3.                 messageBuf[0] = (RTC); //Perc kiolvasása
  4.                 messageBuf[1] = MIN;       // Starting address in memory
  5.                 USI_TWI_Start_Random_Read( messageBuf, 3 );     // Read 1 bytes of data
  6.                 minute=(messageBuf[1]&0b01110000)/16*10+(messageBuf[1]&0b00001111);
  7.  
  8.                 messageBuf[0] = (RTC); //Óra kiolvasása
  9.                 messageBuf[1] = HOUR;       // Starting address in memory
  10.                 USI_TWI_Start_Random_Read( messageBuf, 3 );     // Read 1 bytes of data
  11.                 hour=(messageBuf[1]&0b00110000)/16*10+(messageBuf[1]&0b00001111);
  12.  
  13.                 for (uint8_t k=0; k<40; k++)
  14.                 {
  15.                         breakup(hour*100+minute); // idő kiírása
  16.                 }//for
  17.  
  18.                 messageBuf[0] = (IOEXP);  //Portbővítő beolvasása
  19.                 messageBuf[1] = GPIOB;       // Starting address in memory
  20.                 USI_TWI_Start_Random_Read( messageBuf, 3 );     // Read 1 bytes of data
  21.                 if(messageBuf[1]&0b00000001) //ha az 1es gomb megnyomva -> hour++
  22.                 {
  23.                         temp=hour;
  24.                         if(temp<23) {temp++;}
  25.                         else temp=0x00;
  26.                         temp=(temp/10*16)+(temp%10);
  27.                         messageBuf[0] = RTC;    // device address
  28.                         messageBuf[1] = HOUR;   // address in memory
  29.                         messageBuf[2] = temp;   // data
  30.                         USI_TWI_Start_Read_Write( messageBuf, 3 );  //Új óra beírása
  31.                 }//if
  32.                 if(messageBuf[1]&0b00000010) //ha a 2es gomb megnyomva -> minute++
  33.                 {
  34.                         temp=minute;
  35.                         if(temp<59) {temp++;}
  36.                         else temp=0x00;
  37.                         temp=(temp/10*16)+(temp%10);
  38.                         messageBuf[0] = RTC;    // device address
  39.                         messageBuf[1] = MIN;    // address in memory
  40.                         messageBuf[2] = temp;   // data
  41.                         USI_TWI_Start_Read_Write( messageBuf, 3 ); //Új perc beírása
  42.                 }//if
  43.         }//while

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
(#) holex válasza Ivan93 hozzászólására (») Szept 19, 2014 /
 
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.
(#) Ivan93 válasza holex hozzászólására (») Szept 20, 2014 /
 
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.
(#) Toyoo hozzászólása Szept 20, 2014 /
 
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:

  1. #ifndef F_CPU
  2. #define F_CPU 8000000
  3. #endif
  4.  
  5. #include<avr/io.h>
  6. #include<avr/delay.h>
  7.  
  8. int main(void)
  9.         {
  10.  
  11.         DDRB = 0x01;
  12.         PORTB = 0;
  13.  
  14.         while(1)
  15.         {
  16.                 PORTB = 0x01;
  17.         }
  18. }


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

  1. #ifndef F_CPU
  2. #define F_CPU 8000000
  3. #endif
  4.  
  5. #include<avr/io.h>
  6. #include<avr/delay.h>
  7.  
  8. int main(void) {
  9.  
  10.         DDRB = 0x01;
  11.         PORTB = 0;
  12.         while(1)
  13.         {
  14.                 PORTB = 0x01;
  15.                 _delay_ms(100);
  16.                 PORTB = 0x00;
  17.                 _delay_ms(100);
  18.         }
  19. }


A kérdés, hogy ez így kuka? Vagy van esetleg megoldás erre?

Válaszokat előre is köszönöm!
(#) benjami válasza Toyoo hozzászólására (») Szept 20, 2014 /
 
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.
(#) killbill válasza Ivan93 hozzászólására (») Szept 20, 2014 /
 
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.
(#) Toyoo válasza benjami hozzászólására (») Szept 20, 2014 /
 
Sajnos ezt most nem fogom tudni megmondani, ugyanis sikerült kitiltanom magam. Jövőhéten újraélesztem, ha tudom és megnézem.
(#) Ivan93 válasza killbill hozzászólására (») Szept 23, 2014 /
 
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
(#) killbill válasza Ivan93 hozzászólására (») 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.
(#) holex hozzászólása Szept 23, 2014 /
 
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?
(#) killbill válasza holex hozzászólására (») Szept 24, 2014 /
 
En olyan 20-50ms korul szoktam. 100ms mar elveszithet rovid megnyomasokat. 20ms-nel surubben nincs ertelme.
(#) Istvanpisti válasza holex hozzászólására (») Szept 24, 2014 /
 
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
(#) killbill válasza Istvanpisti hozzászólására (») Szept 24, 2014 /
 
Miert eroforrasigenyes az, hogy 20ms-onkent beolvasod az A/D utoljara mert erteket, es elinditod ujra? Ez kb. 10 utasitas.
(#) szines hozzászólása Szept 24, 2014 /
 
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
(#) csabeszq válasza szines hozzászólására (») Szept 24, 2014 /
 
(#) lajos1969 hozzászólása Szept 24, 2014 /
 
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!!
(#) holex válasza killbill hozzászólására (») Szept 24, 2014 /
 
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?
Következő: »»   618 / 837
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.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