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   62 / 840
(#) szilva válasza Topi hozzászólására (») Aug 6, 2008 /
 
Tegnap este nyomtattam egy panelt, van rajta egy FT232 és egy DIP tokos Tiny2313.

A módosított hex-et PonyProg-gal beleírattam az AVR-be olyan módszerrel, hogy a PonyProg által használt soros interface-ből kilestem, melyik RS232 jeleket mire használja, és vezetékekkel odakötöttem a tokban lévő AVR megfelelő lábára az FT digitális kimeneteit (a hardver setup-ban pár bitet emiatt negált használatra kellett beállítani). A programozás lement rendben, bár iszonyat lassú, volt legalább negyed óra, mire a végére ért.

A kérdésem a config bitekkel kapcsolatos lenne. Milyen konfigurációt kell beállítanom a Tiny2313-nak, hogy jó legyen az eredeti 90S1200 helyére? Mellékelem a képet, hogy a PonyProgban hogyan látom a config biteket.


(#) szilva válasza szilva hozzászólására (») Aug 7, 2008 /
 
No, a tegnapi nap folyamán sikerült felélesztenem az AVR910-es appnote szerint épült programozót. A soros portot egy FT232RL USB/serial chip állítja elő, ehhez logikai szinteken csatlakozik a programozóban lévő ATTiny2313. Kicsit szenvedtem a konfiggal, de sikerült a végén minden nehézséget legyűrni. Az élesztés során életemben először írtam pár sor AVR assemblyt saját magam (soros porti kimenetre tesztsorozat küldése)

A kezelő szoftverekkel kapcsolatosan azt tapasztaltam ki, hogy az AVR Studióba beépített AVR Prog tényleg csak azokat a chipeket ismeri, amit az eszköz visszajelez neki ismertként (ezek közt pl. a Tiny2313 sem szerepel).

Az Atmel is az AVR911-es appnoteban szereplő AVROSP-t (AVR Open Source Programmer) ajánlja az AN910-es programozóhoz, ami viszont az AVR Studio-val együtt feltelepedett chip-információs XML file-ok alapján dolgozik, így nem volt neki gond a Tiny2313 sem! Igaz, ez egy parancssoros utility, de szerintem mindent tud, amire szükség lehet programozás terén.

Fogok képeket készíteni a kütyüről, de most nincs nálam ilyenre is használható fényképező.
(#) TavIR-AVR válasza szilva hozzászólására (») Aug 7, 2008 /
 
T2313 és a 90S1200 _nem_ csereszabatos.

Az AVROSP-hez létezik AVROSPii keretprogram, az grafikus.
Bővebben: Link (sok, AVR910hez való szoftver, összegyűjtve)
(#) TavIR-AVR válasza TavIR-AVR hozzászólására (») Aug 7, 2008 /
 
(#) szilva válasza TavIR-AVR hozzászólására (») Aug 7, 2008 /
 
Idézet:
„T2313 és a 90S1200 _nem_ csereszabatos”


Persze, emiatt kellett "erősen néznem" a forrást meg mindkét adatlapot is az elmúlt napokban De sikerült belefaragni, és a végén rájöttem, hogy a Topi által küldött kód is naná, hogy jó, csak a fuse-okat néztem el, meg más apróságokat az áramkörben.

Az AVROSPii-t megnézem, kösz, hogy mondod!
(#) Bender hozzászólása Aug 7, 2008 /
 
Hellall

Nincs valakinek otthon elfekvőben AT90S8515 IC-je? Olyan kéne, ami PLCC esetleg TQFP tokban lakik... Eléggé fontos lenne, és sajna már sehol nem lehet ilyet kapni
Az ATMega8515 helyettesítheti ezt a típust, vagy át kell hozzá irkálni a pogit is? A kütyüből régen kiolvastam a flash cuccosát és az megvan de a forrása nincs ezért nemtom átírni

Bender
(#) szilva válasza szilva hozzászólására (») Aug 7, 2008 /
 
Ígértem, hogy teszek fel képet róla, íme az USB/serial átalakítóval működő programozóm:

AVR910 programmer

Amivel megaz első AVR-t felprogramoztam az ez a soros porti szörnyűség:

Serial AVR programmer
(#) Sallala hozzászólása Aug 7, 2008 /
 
Letölt, kinyomtat, celluxszal AVR-re ráragaszt és mikor próbapanellel dolgozik, örül!
Szerintem tök jó ötlet, bár már biztos kitalálta más is.
Kép: Kép: Hivatkozás


ATmega16L és ATmega32-höz PDF nyomtatási minta letöltés
(#) Sallala hozzászólása Aug 8, 2008 /
 
Sziasztok!
Hajnalig bajlódtam az ATmegáimmal, de nem jutottam velük dűlőre. Kérlek segítsetek!

Építettem egy PPPD nevű LPT portos ISP programozót. Ez jól működik, legalább is ledeket kötve a kimenetre meg a vissza irányú MISO vonalat kimérve oké.

A gyári ATmega32-t lvarccal csak hosszas próbálkozások árán tudtam egyetlen egyszer összekapcsoni a kanda ISP progamozóval. Állítottam fuse biteket szerintem jól, utánna nem sikerült többet kapcsolódnom.

Összebarkácsoltam egy CMOS oszcillátort, nem tudom milyen frekin megy, azzal tízből egyszer életre tudtam kelteni a kütyüt. Hússzor megnéztem a fuse biteket, de kristályról nem űködött csak erről a külső oscillátorról.

Ráadásul igen bizonytalanul. Próbáltam flasht írni, de a betöltött program is bizonytalanul futott. Valószínűleg azért, mert az oszcillátor is bizonytalan volt.

Teljesen ködös a dolog. Próbáltam különböző frekvenciákat adni neki, mikor melyikre indult be.

- A fuse bitek beállításától függetlenül az XTAL1 lábra adott órajellel mindig el kell indulnia a procinak?
- A beadott órajel fekije független a beégetett fuse bitektől? Tehát ha belső 4Mhz RC oszvillátort adtam be a fuse bittel, akkor kívülről hajtva csak 4Mhz-s órajelre éled fel?

Szkóp nélkül tudom ellenőrizni, hogy rezeg-e a kvarcom?

Kanda prgoamozót próbálta valaki? PonyProgban nem tudok ATMega16-ot kiválasztani. Kanda prorgamozóval a kapcslat hol elindult hol nem, de ponyprog sosem.

Bocsánat hogy ilyen hosszú voltam, de nagyon tanácstlaan vagyok! Lehet, hogy a próbapanel rossz? Mennyire függ a dolog az LPT port beállításoktól?

Nem tudok honnan elindulni, mert ugyan az a beállítás hol megy hol nem úgy hogy nem nyúlok semmihez, csak nyomok egy resetet a kanda progamozó progamban.

(#) szilva válasza Sallala hozzászólására (») Aug 8, 2008 /
 
Elsősorban az AVR tápellátását ellenőrizd, megvan-e a stabil tápfeszültség, stabil-e, valamint van-e megfelelő hidegítés a tápon, lehetőleg minél közelebb az IC táplábaihoz.

Másodsorban ellenőrizni kellene, hogy a kvarc mellett vannak-e megfelelő értékű kondenzátorok (22pF körüli szokott lenni), ezek hiányában az oszcillátor nem biztos, hogy berezeg normálisan. Én vettem 3 lábú, 4MHz-es kerámiarezonátorokat, ezekben elvileg benne van a szükséges kondenzátor is, ezekkel semmiféle bizonytalanságot nem tapasztaltam.

A külső oszcillátorról véleményem szerint nem mindig kellene mennie a CPU-nak, mivel ha a fuse-okat úgy állítod, hogy az a két láb I/O legyen és ne az oszcillátorhoz legyen rendelve, akkor szerintem hiába is adsz oda külső órajelet.
(#) IMi válasza szilva hozzászólására (») Aug 8, 2008 /
 
Hello!
Én EZT a programozót építettem kb fél éve (ugyan az amit Topi is talált, csak HV rész nélküli).
Tökéletesen működik mint AVR Studió, mint Kontrollerlab (linux) alatt, STK500 kompatibilis. Csak ajánlani tudom!
Majd teszek fel képet is, csak most kupi van (szobafestés...)

U.i.:az általam megépített kapcsolás sem költségesebb mint a FT... megoldás talán még egyszerőbb is, viszont ha valaki megépíti a teljes AVRDoper-t akkor a hallot AVR-ek is életre kelthetők egész kis full-os cucc
(#) Sallala hozzászólása Aug 8, 2008 /
 
Hogyaza #&@%!'(+%'"/

Nagyon köszönöm a segítséget!
De felkeltem, ránéztem a cuccra, hüvelykujjal úgy izomból ránehézkedtem az avr-re mire az belepattant a próbapanelbe.

Szóval ilyen láma voltam! Nem volt rendesen belenyomva az IC, épphogy érintkezett. Te jó ég! Ez még saját magam előtt is égés.

Szilva! ATmega32-n az xtal lábak dedikáltak. De köszi a tippet, kisebb lábszámú tokonál jogos!
(#) szilva válasza IMi hozzászólására (») Aug 8, 2008 /
 
Köszi szépen a linket, nagyon szimpatikus darabnak tűnik! Megvárom még Topi ígért cikkét is, aztán valószínű, hogy egy komfortosabb programozót is összerakok, de egyelőre csak ismerkedek az AVR-ekkel. Addig meg ez az USB-sített soros portos programozó bőven elég lehet.

Épp most módosítottam a programját, hogy a programozás módból kilépve eressze el a RESET lábat is. A kicsike próbapanelemre (ami látszik is a tegnapi képeken) tettem 4 LED-et, egy nyomógombot és egy RESET gombot, a módosított firmware-ű programozóval így azon a panelkén tudok tanulni, kipróbálni dolgokat. A "hello world" (a 4 LED közül kettő kigyújtása) épp az imént indult el

Egy kérdés: mire érted a "halott AVR" kifejezést? Mitől halott, ha fel lehet éleszteni?
(#) Frankye válasza Sallala hozzászólására (») Aug 8, 2008 /
 
Egyszer én is nagyot szívtam ilyennel, azóta amit lehet, közvetlen a foglalat mellé tűzött vezetékkel kötök be, illetve "benyomva" tartom közben az IC-ket... Csak néha kevés a 10 ujjam!
(#) Topi válasza szilva hozzászólására (») Aug 8, 2008 /
 
Halott AVR: AVR-ek esetében a programozáshoz órajel szükséges. Amit alap esetben a belső RC biztosít.

Mitől lehet halott?
- Széttúrt konfig bit miatt el nem induló oszcillátor (többet nem programozható úgy, abban a formában)
- Programozóban rossz típus választás miatt egyszeri CB írás után halott lesz. Sok minden miatt is
- Akár az ISP-t is le lehet tiltani (főleg régi AVRStudiókban, mára szerencsére ezt javították), de más programokkal még mindig le lehet tiltani. Ha nincs ISP, nem lehet ISP-n programozni
- Ha a DWEN bitet belőttük, akkor a RESET megszűnt mint RESET funkcionálni. Ilyenkor ha nincs debugWire módra képes programozónk (pl. AVRDragon) akkor az már halott is, ugyanis az ISP nem tudja a processzorunkat kizavarni az álomból a RESET-en keresztül.
- Egy hibás bootloaderrel is lehet halott AVR-t készíteni, amiből csak HVSP, vagy PP móddal lehet kiszedni. Ám következő probléma, a kis lábszámú processzorokon a PP-re (párhuzamos programozás) nem nyílik lehetőség, csak a HVSP-re (High Voltage Serial Programming) amire ugye nemcsak külön hardver kell, de még bonyolult is. Persze az AVRDragon megoldás lehet mindegyikre, mint gyári, igen Low-cost mindennel felvértezett fejlesztői eszköz. (JTAG, debugWire, ISP, HVSP, PP)
(#) szilva válasza Topi hozzászólására (») Aug 8, 2008 /
 
Aha, értem, köszi. Ilyesmire gondoltam elsősorban én is, de az így "félrekezelt" chipet én nem nevezném halottnak, inkább magába roskadt-nak

Ahogy értelmeztem a dolgokat, rám nézve jelenleg igazából a debugWire lehet veszélyes, úgy emlékszem, az adatlap olyat írt, hogy az ISP programozás letiltására szolgáló bitet ISP-n keresztül nem lehet írni.

Az oszcillátoros kizárást már megtapasztaltam valamelyik nap, amikor a programozóba szánt AVR-t átállítottam kvarcoszcira és a panelkén, amiben programoztam, nem volt mellette kvarc
(#) Topi válasza szilva hozzászólására (») Aug 8, 2008 /
 
Igen. a debugWire-t nem lehet ISP-n visszaállítani. Azt csak debugWire-ön keresztül lehet.

Legtöbbször kezdésnél az oszcillátoros kizárás valósul meg. Pont ezért, az új hamarosan kész programozón kivezettem egy órajelet

Ám ha egy hibás processzor választás miatt éget az ember rossz CB-et, akkor az már problémásabb.
Napokban, dolgoztam egyszerre mega16-al és tiny45-el. Egy programozó, egyszerre fejlesztés. Egyszer elfelejtettem átállítani a device-t és rátoltam a mega16 config bitjeit a tiny45-re. Se ISP-vel, se dW-el, se külső órajellel nem sikerült visszahoznom az életbe.
Annyit meg nem ér egy tiny45, hogy összedrótozzam a HVSP-t
Ráírtam egy papírra, hogy CB halott, átszúrtam a lábait rajta, és eltettem. Majd ha megszorulok egyszer, akkor újraéleszerintem, de addig elővettem a csőből egy másikat
(#) szilva hozzászólása Aug 10, 2008 /
 
Lenne egy olyan kérdésem, hogy meg lehet-e azt határozni, hogy milyen kiosztás a legelterjedtebb az AVR-es ISP csatlakozók terén (mit lenne érdemes követnem az áramköreimben)?
(#) TavIR-AVR válasza szilva hozzászólására (») Aug 10, 2008 /
 
AVR ISP10 és (régebben/kisebb nyákfelület esetén) a AVR ISP6.

Bővebben: Link
(#) Topi válasza szilva hozzászólására (») Aug 10, 2008 /
 
Én erre létrehoztam egy külön alkatrészt protelben, ahol a lábak az Atmega16-nak megfelelően vannak, egysorban.
Nézd meg az adatlapot és okosan egymás mellé tették a lábakat.
Én ezt a sorrendet használom:
GND, VCC, RESET, SCK, MISO, MOSI

Jó, mert Megáknál mindehol ez a sorrend, Tiny-knál meg csak a reset és a táp van máshol, de az sck, miso, mosi ugyanúgy.

Én azt javaslom, hogy a célszerű programozás és az egyszerű kivitelezés mindenképpen ezt az utat mutatja. Pl. Ha csinálsz egy átalakítót (én is csináltam egy ISP10-Saját csati) átalakítót, melynek a vége egy hosszú tüske, és a VCC egy jumperrel lekapcsolható, akkor még próbapanelnél is jól jársz, ugyanis egyszerűen csak azt az egy-soros tüskét be kell szúrni az IC mellé. Semmi plusz drótozás, semmi felesleges táp kivezetés.
(#) huba hozzászólása Aug 10, 2008 /
 
Sziaszok. Normális az hogy egy egyszerű alfanumerikus lcd driver megeszi egy ATmega48 85%-át? azt több mind 3,5k. Otda még nem fér be nekem dcf77 dekódolás, I2c-s hőmérő kezelés....
(#) TavIR-AVR válasza huba hozzászólására (») Aug 10, 2008 /
 
Programnyelv? Programozási metódus? netán mintaprogram?


Bascom alatt ~1,2k körül lenne ez. Ha a Format/Fusing-et használod, az ~1k5 pluszt jelent....


C, ASM és Pascal esetén passz....
(#) huba válasza TavIR-AVR hozzászólására (») Aug 10, 2008 /
 
Na igen ezt elfelejtettem. Avr Studio+ winavr AVR GCC-be. Bascomban tudom egy Attiny2313-an is animáltam. Szerintem egy más könyvtárután nézek.
(#) Topi válasza huba hozzászólására (») Aug 10, 2008 /
 
Optimalization. Project / Config. options. Állítsd be a kód optimalizációt. O0, O1. Válassz valamit.

Kikapcsolt optimalizáció mellett az időzítések ami egy ügyetlenül megírt LCD driverben előfordulnak, megeszik az egész program memóriát.
(#) huba válasza Topi hozzászólására (») Aug 10, 2008 /
 
Végigpróbáltam mindet. Csak néhány százalékot nyertem. :no:
(#) Topi válasza huba hozzászólására (») Aug 10, 2008 /
 
Mellékeld a kódot kérlek. Egy 2313-ban el sem hiszed mennyi mindnre elég Flash van
Megnézzük, jó lesz az, nyugi. Lehet egy két részt, assemblyben kell megírni, megteszem szívesen.
(#) huba válasza Topi hozzászólására (») Aug 10, 2008 /
 
A driver gtk cikkéből letöltött És butitott verzió. De így is eszméletlen sokat foglal. Azt hiszem keresek egy másikat. Továbbá ráveszem magam a programozásra is, mert elég nehezen fogok neki a DFC77 dekodoló programnak és még sok elképzelésem sincs. Vagyis van de a második szinkronon gondolkodom.
(#) Topi válasza huba hozzászólására (») Aug 10, 2008 /
 
Én írtam egyet, a hamarosan kikerülő DCF-es cikkemben lesz külön unit.
Ha van kedved írni, akkor segítek egy keveset, nálam mi jött be.
Ugye alap, hogy interrupt vezérelt. Aztán be kell konfigurálni egy 16 bites timert cca. 1ms-os interruptra.
Ám nem a normál interruptot használod hanem simán az oveflow-t.
Hogy jobban kézben tartsd a biteket csinálj egy struktúrát, ahol minden rekord olyan hosszú mint ami a valóságban is.
  1. struct DCF77 {
  2.    unsigned long long bits       :16;
  3.    unsigned long long mez_mesz   :1;
  4.    unsigned long long zone1      :1; // 0=MEZ, 1=MESZ
  5.    unsigned long long zone2      :1; // 0=MESZ, 1=MEZ
  6.    unsigned long long leapsecond :1;
  7.    unsigned long long start      :1;
  8.    unsigned long long min        :7;
  9.    unsigned long long parity_min :1;
  10.    unsigned long long hour       :6;
  11.    unsigned long long parity_hour :1;
  12.    unsigned long long day        :6;
  13.    unsigned long long weekday    :3;
  14.    unsigned long long month      :5;
  15.    unsigned long long year       :8;
  16.    unsigned long long parity_date :1;
  17. };


Ez azért jó, mert a rekordot magát megcímezve timer overflow esetén máris a DCF77 struct + bitszámra írhatod is a bit értékét, és mivel a fordító egész bithalmazként kezeli, nagyon jól elkülönülnek a bájtok és bitek. Nem kell foglalkozni hogy most hova írod. Olvasásnál úgyis jó helyen lesz.
Továbbá: Vezesd be, hogy a jel 90%-át tekinted valósnak, ezenkívül nem pulzus szélességet nézel, hanem felfutó élnél indítod a timert max érték-150ms-nyi értékről. Így mikor a 150ms letelik és beesik az interrupt akkor már mérhetsz is. Ha 150-nél 1-est veszel akkor az egyes lesz, ha 150-nél nullát veszel (mert hogy a rövid impulzus az 100ms) akkor máris mehet bele a nulla.

Paritásokat real-time kell számolni, mindig mikor bejött egy bit, máris xorolsz.
Aztán úgy kell beállítani az interruptot hogy cca. a lefutó éltől számított 1200. ms után ha nem resetelik tehát nem compare-es interrupt hanem overflow akkor az az 59. másodperc, tehát a perckezdet.

Nekem egy mega16-ban, I2C hőmérő + DCF dekódolás + graf. kijelző kezelés 18%. Ami azt jelenti, hogy kb 2,6K kajál el. És köztudott, hogy a graf kijelző a sok fonttábla meg ilyenek miatt többet kajál. Persze én nem félek az assemblytől sem, és nem titok, egy két interruptos részt assemblyben írtam meg, de annélkül sem lépnéd túl a 4K-t. Ez tuti.
(#) huba válasza Topi hozzászólására (») Aug 10, 2008 /
 
Találtam eggyet 33%-bol megvan a lib+ demóprogram. Köszönöm a dekódolási tippeket. Nem értem teljes mértékben de meg fogom.
Tényleg nincs valami generátor program ami párhuzamos portra DCF77 jelet szimulál? Mert a vevő tökéletes müködésében nem vagyok biztos. Leden szépen látni a jelet de tudjátok hogy van...
(#) Topi válasza huba hozzászólására (») Aug 10, 2008 /
 
Ismerősöm ezt úgy oldotta meg, hogy felvette soundforge-ba. Majd kijavította kézzel a hullámformát.
majd illesztve visszajátszotta media playerrel annyiszor amíg játszott a fejlesztgetéssel
Következő: »»   62 / 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