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
MAX3002 : Ret-nél, farnellnél van....
 És működik is a programozó ISP, TPI és PDI segítségével is....
Ja azt nem mondtam hogy TPI-n és PDI-n ne működne, bár eddig az ISP mellett csak a TPI-t(6 lábú ATTiny-k)
mellett próbáltam, illetve egy vásárlóm szólt hogy PDI-n(ATXMega) is kiválóan működik. TPI, ATTiny10: Persze mindjárt egy olyan programot kellett írnom ahol a RESET láb is kellett volna, és persze hogy rossz volt a program így újra kellett (volna) programozni. RESET láb letiltva, de semmi gond, ezzel a programozóval nagyfeszezni is lehet! Csak egy optocsatoló és egy 12V-os táp kell!
Üdv!
Egy elég súlyos problémával küzdök és a szakik tanácsára szorulok. Adott egy beágyazott rendszer. Elég komplex( kb 13000 sor). Egy ATMEGA128-as proci van benne, amihez i2c-n kapcsolódik egy qt60160-as kapacitív billentyű ic és egy eeprom. A gond az,h a cucc pár óránként lefagy. Gondolkodok ,h hogyan valósítsam meg benne a watchdogot, de vannak benne hosszabban futó dolgok és nehéz lenne felmérni a futás időt... Viszont azt vettem észre, hogy lefagyáskor a billentyűre nem reagál és SCL láb 0 V volt az SDA meg 5V. Arra gondoltam,h valószínű az i2c kommunikációban történik valami gebasz és ott a kódban tényleg van while. Lehetséges-e az hogy a kommunikációban valami véletlen folytán előáll egy olyan dolog,h a billentyű IC és a proci is a másikra vár és ez miatt lesz fagyás? Egy vezetékkel egy pillanatra lehúztam az SDA lábat, amitől újra működni kezdett a cucc. Valami megoldást tudtok javasolni? Márió
Ilyen nekem is előfordult, csak I2C-s hőmérő esetén. Vagy akkor fagyott ki, ha valami zavar rákerült a buszra, vagy pedig lehúztam a szenzort. Visszatéve nem működött tovább. Sajnos nem tudtam jó hibakezelést csinálni... Ha lehetséges, próbáld meg csökkenteni a zavarlehetőségeket, esetleg valahogy árnyékolni a buszt, vagy a felhúzóellenállásokat csökkenteni.
Én olyasmire gondoltam, hogy átírom valahogy az I2C-s függvényt és ahol while-al vár egy regiszter bitjére ott berakok vm timeoutot. Számol valami relatív nagy számig, ami alatt tuti meg kellene jönnie a jelzésnek. Ha nem jön, akkor meg magától kiugrik. Max kis helytelen működés és megy tovább. Most megvárom míg még egyszer elhalálozik, aztán újra tesztelem ezt a "lehúzom az SDA" módszert és ha megy, akkor belenyúlok a szoftverbe.
Hello!
Ahol a while részek vannak, oda kell beletenni egy timeout-számolós részt. Most nem szúrnám be a könyvtárat amit saját magam írtam, de a lényeg hogy Atmel esetében 3 műveletnél kell várakozni a megfelelő flag átkapcsolására: START, WRITE, READ. Csak a STOP esetében nem kell semmire sem várni. DE! START esetén meg kell várni az előző STOP befejeződését ha még tart. Erre is lehet timeout. Így néz ki az én START függvényem:
Sziasztok!
90s2313 helyett betehetek mindenféle sw módosítás nélkül ATTINY2313-at? erről a kapcsolásról lenne szó: Bővebben: Link Köszönöm!
Elvileg igen. A kódot azért nem árt újrafordítani.
1:1 csereszabatos. A kód is mehet rá, nem kell újrafordítani.
A biztosítékbiteknél van némi eltérés: - ATTIny2313 esetén órajelforrást beállítani. Kész
Sziasztok! Talán emlékszik még valaki az atmega168 kizárás (#1032133 - #1032487). Megpróbáltam a debugWIRE-on keresztül beférkőzni, mert HVPP-n csatlakozva úgy tűnt a reset lábat átkapcsoltam debugWIRE-ra. Viszont teljesen össze-vissza olvasta ki a device id-t, kb 10-20× kellett olvasni mire a megfelelőt olvasta ki. Mindegy, ugyanígy legalább 10-20× megpróbáltam átírni a FUSE biteket a megfelelőre. Mindíg OK volt az írás de a verify failed. A végén ott is hagytam. Közben megérkezett egy STK500 "klón", ki akartam próbálni és persze az idegkárosodott Atmega168 volt kéznél még mindíg a boncasztalon. Megpróbáltam SPI-n elérni és SIKERÜLT!!! Olvassa, írja minden csitti-pató!!! Lehet, hogy HVPP-nél nem működik rendesen az ellenőrzés? De miért olvasott össze-vissza adatokat? Ellenőriztem minden csatlakozás rendben van. Ma még teszek egy próbát HVPP-vel amíg be van kötve. A vicces az egészben, hogy most már tuti nem teszem vissza a panelbe és ráment vagy 10-15 órám. De hát ez a szenvedély nem?
Tegnap még áthekkeltem a kódot hasonlóan. Reggelre nem úgy fagyott le, ahogy eddig, mert nem akadt meg a programfutás és futott a cucc, csak az i2c volt kihalva(2 példány ugyanúgy fagyott). A képernyőm nem az a szöveg volt ami a külső eepromban, hanem valami krix-krax és a billentyű se ment. Viszont amikor lehúztam vezetékkel az i2c vezetékeit megint életre kelt. Lehet meg kellene hívnom néha az i2c_init-et és az helyre csapná...
Nálam akkor okozott ilyen hülye jelenséget:
- 100nF kerámia hidegítőkondi kimaradt (vagy 100nF helyett 1µF lett berakva) - hidegítőkondi helyett 10k 1206-os ellenállás - zajos táp - VCCA és GNDA lebeg. Ezek helyrerakva: minden OK
Köszi!
Egy napelemet szeretnék figyelni ATTiny45-el (vagy más is jó, csak ez van itthon most).
A lényeg, hogy max 20V feszültséget ad le maximum 140mA-el. A cél az, hogy a napsütés "erejét" szeretném vele mérni és regisztrálni. A tárolt adatokat EEPROM-ba fogom írni tömörített formában, ezzel a részével nincs problémám. Azt viszont nem tudom hogyan kössem rá a napelemet az analóg bemenetre. (Másik project pedig két helység páratartalom különbségének mérése )Előre is köszönöm a segítséget.
Úgy néz ki sikerült megoldani az i2c-s gondot. Átírtam úgy, hogy ne tudjon beakadni az i2c és néha inicializálom. Ez még kevés volt, mert így is kifagyogatott, ezért a reset lábát egy elenállással PG4-re kötöttem (utolsó szabad IO) és bizonyos időközönként megpróbálok az i2c-s eepromból olvasni, ami szintén elromlik, ha i2c-s gond van. Előre ismert tartalmat olvasok ki belőle és ha nem stimmel, akkor az azt jelenti,h lefagyott az i2c és kimenetnek kapcsolom a PG4-et, ami reseteli így a cuccot. Raktam bele még egy indítási számlálót, így láttam, hogy hányszor halt meg. 2 nap alatt 4-szer.
Márió
Páratartalomra gondolom cél IC kell. Ami a napelemet illeti: Ellenállásosztóval kötöd a feszültséget a bemenetre, hogy a 20V max annyi legyen amin fut a uC-d. Áramot pedig legegyszerűbb egy sorba kötött ellenálláson eső feszültséggel mérni. I = U/R és kész is.
Megjegyzem, hogy léteznek olyan IC-k, amivel úgy mérhetsz áramot, hogy nem kell sorba kötni ellenállást. Eggyel konkrétan találkoztam, ami a hall effektussal mérte az áramot és I2C adta ki az infót. Valami ilyesmi, csak kis smd tokban volt: Bővebben: Link
Jó hír, hogy megoldódott a gondod.
Érdemes lenne utánajárni, hogy mi lehet az okozója a lefagyásoknak. Én a helyedben átvizsgálnám a NYÁK tervet, hogy minden IC aszerint van-e bekötve, ahogyan az az adatlapojaik ajánlják. Gondolok itt a megfelelő lábakra javasolt kondikra, illetve méretükre, továbbá, hogy ha azt mondta, hogy minél közelebb legyen az IC-hez, akkor nem a sarokba került-e mégis véletlen. Habár ha ezek után korrektül megy, akkor persze nem muszáj, csak a jövőben számodra érdekesnek bizonyulhat, hogyha esetleg a hiba forrását is netán sikerül felderítened. Legkésőbb az egész dolog következő revíziójánál pl, ha lesz ilyen.
Sziasztok.
Két problémám is lenne .Az első megépítettem egy minipov 3 -at és a neten találtam egy szenzoros változatot (program és fel is töltöttem) de túl lassú a szinkronizálás vagyis a megfelelő sebsebégre állás ha növelem a kódba akkor meg nem teljesen pontos. A másik kérdésem hogyan tudom megoldani h változón a "kép" vagyis pl. időnként váltózón mintha mozgó kép lenne remélem elég érthető voltam .
Segítséget köszönöm előre is: Suhanc ui.: Képen a jelenlegi kinézet kicsit gyengén világít.. De már megoldottam.
A szinkronizálást nehéz megmondani, ha nem haragszol nem folyok bele nagyon.
A kép változása ennél a sornál van:
Ehelyett kell más és mást megadnod neki (a largeimage_p helyett ugye) pl ha már 500-szor beolvasta ezt, akkor mast olvasson be... Ugyanakkor gyenge C skilleket érzek a kérdésedben, főleg ami a képváltozásra vonatkozik. Ha adhatok egy tanácsot, akkor kezdj el magadtól programokat írni és máris triviális lesz egy-egy ilyen dolog.
Köszönöm! Most már értem.Csak annyit kérdeznék,hogy miként tudnám megváltoztatni az órajelet anélkül,hogy kitörölném a mikrovezérlőt és újra beleégetném csak már 1 Mhz-s órajellel?
FUSE bitek...
Helló!
Hogyha van egy programozott avr-em abba lehet új programot égetni?És ha igen akkor az alap programot le kell törölni vagy egyből átírja azt?
igen-nem
1: mindig lehet írni bele amíg tönkre nem teszed 2: íráskor a régi program automatikusan törlődik/felülíródik.
Utóbbi akkor is megtörténik, ha nincs bekapcsolva az írás előtti törlés opció? Ha ki volt kapcsolva, akkor nekem kifagyott a doper, az STK500-zal meg nem próbáltam még...
Üdv!
Olvasgattam az itteni AVR-es cikkeket, és gondoltam kipróbálom magam. A programozás nem ismeretlen számomra, bár eddig c++ban nyomultam, és c-t sosem tanultam (hát nem furcsa?  ), így néhány dologra figyelnem kell (nincs például refi, meg bool visszatérési érték metódusnál, stb., de szerencsére mindent meg lehet oldani pointerrel és egyéb dolgokkal)A problémám a következő lenne: Az itteni AVR 8 lábon leckéit már átnéztem párszor, és akár a 2 ledes villogót, akár a jelzőlámpásat csináltam meg, az időzítés nem stimmel. Beállítottam a projektnél hogy 8.000.000 Hz (nyilván pont nélkül), megírtam a metódust is:
De ha mondjuk így hívom meg:
akkor ~24mp-et vár. Esetleg a debugger / szimulátor miatt lehet? "AVR Simulator" van beállítva. Nincs még programozóm meg kísérleti nyákom sem (már meg van rendelve, előbb-utóbb meg is érkezik... )Előre is köszi a válaszokat!
Érdekes megfigyelés:
Ha elindítom a debuggert, akkor bal oldalt azt írja, hogy a CPU frekije 4.0000 Mhz. A helyes időzítést pedig a következő képen értem el: 1024*1024 / 4 = 262144 És a 8000000 hz helyett 262144 hz-et írtam be, és voilá! Viszont ennek nem így kéne működnie, tehát várom majd az ötleteket (vagy ne foglalkozzak vele, biztos jó lesz avr-be programozva, élesben?)
Beallitasoknal allitsd be a CPU frekijet, es valoszinuleg be vanpipalva a CPU DIV 8 is... Az mar igy 16* lassabb mint amit szerettel volna, es lehet a tobbi keses abbol adodik, hogy optimalizacio ki van kapcsolva es ilyen sok idot vesz el maga a ciklusod.
A CPU frekijét beállítottam a project -> configuration options-nél a device-t (attiny45), frekit (8000000 hz), és az optimalizálást -01re, ahogy a lecke is mondta.
Hellosztok!
ATMEGA644-et programozok BASCOMban, és AVR-DOS-t használnék (kvarc:11,059200MHz). minden oké addig, amíg be van kapcsolva a 8-as divider, de ha kilövöm, elszáll... Az SPI szoftveres (a hardveres lábakon van, de az nem megy). Azt sejtem, hogy az SPI órajelfreki túl magas (az előző 8 szorosa ugyebár). Csatolom a kódot.
Hogy tudom csökkenteni az spi órajelfrekit? Segítségeteket előre is köszönöm! Üdv.: Hurka |
Bejelentkezés
Hirdetés |
