Fórum témák
» Több friss téma |
Sry, félreértettem dolgokat. Ofc nem akarok égetőt építeni. Az égető kapcsrajzot azért nézegetem, hogy valamiből eldöntsem, hogyan alakítsam ki a környezetét.
Apropó nMCLR láb. Átlag 10K-t pakolásznak oda. Leszámítva a hasraütés esetét, van valami különleges oka is, hogy éppen 10K és nem mondjuk 33k? Idézet: „van valami különleges oka is, hogy éppen 10K és nem mondjuk 33k?” Nincs. Ne legyen túl kicsi se, hogy az égetőprogram birja húzgálni, illetve ne emelje meg a kontroller Vdd-jét, de ne legyen túl nagy se, hogy ne legyen nagyon zavarérzékeny. 1k-10k között szoktunk rakni, ami épp van kéznél.
A Te esetedben nincs különösebb jelentősége. Amikor azonban "magasfeszültségű" programozás történik (PIC16, vagy PIC18), akkor megfontolandó, hogy az ellenállás egyik vége 13 V-on, a másik vége meg 5 V-on lesz, s ez kis ellenállás esetén nem elhanyagolható áramot jelent. Ezért szeretjük a 10 kOhmot...
Ennél sokkal nagyobbat viszont a zavarérzékenység miatt nem érdemes használni, ahogy ezt Potyo elmondta. Idézet: „magfesz stabilizátornak meg inkább 10ľF tantált, a 470nF-ot kevésnek találom.” A gyári ajánlás 330nF, ha jól emlékszem(vagy 100n ?). Semmi esetre sem jó oda a tantál! Nem értem minek találsz ki ilyen dolgokat? A többi dologban sem tudlak igazán követni?
Sziasztok.
Szeretnék tanácsot kérni. Szeretnék egy gombbal ki / be kapcsolót csinálni, megírtam hozzá a progit, de nem azt csinálja amit szeretnék. Egyfolytában villog a ledem a portd 0-n. Válaszotokat előre is köszönöm.
Bocs, de félreértésből adódóan már többszörös keveredés van! PIC24 (vagy dsPIC33?) a (valódi) szóbanforgás tárgya, s oda 10 µF kell. Jó a tantál...
Ajaj, igen! Én az USB-s 470nF-ra gondoltam(PK2-n). Kész káosz van már!
  Pajti2! A hozzászólás tárgytalan!
Jólvan, mostanra meg már előkotortam neked a 18f2550-es adatlapját is a Vusb lábról. A doksi leírásban 220nanot ír +/- 20%-al, de ha lejjebb mész az adatlap kivonatokhoz, ott meg találsz egy ilyet:
http://img710.imageshack.us/img710/3884/cusb.jpg Remélem jól illeszti be a képet. Nem kell azt se olyan véresen komolyan venni, hogy most 470n-val akarj 300 lépésről virgonc kölyöknyuszit lőni. 220n-tól 12µF-ig még a normál üzem esetén is bármi belefér. Kerámia, tantál, ami van. Polisztirol, meg alu-elkó ne legyen. Amúgy a pic-kwik C5-ösről beszéltem. Ahány dsPIC adatlapot csak láttam, ezeknek a piceknek mind van külön belső magfeszültség stabilizátoruk, és mindegyik igényli egy külső izmos kapacitás jelenlétét a belső zavarok leszűrésére. Idézet: „220n-tól 12ľF-ig még a normál üzem esetén is bármi belefér.” Nem értünk egyet. Nézz utána miben más egy kerámia kondi és mi a különbség a pufferelés és a szűrés(hidegítés) között.
Hasonló programot úgy csináltam, hogy:
1.Lenyomásra várunk 2. Késleltetés 3. Felengedésre várunk 4. Késleltetés 5. Sipirc vissza az elejére. Az ízlés dolga, hogy a kimenet váltását 1. utánra vagy 3. utánra teszed be. Részleteket nem írok, mert a kód PIC24-re C nyelven íródott...
Elszokott már a szemem az assemblytől, szóval a kódhoz most inkább nem szólok hozzá. De a lényeg nem csak a késleltetés mértékében van.
Egy gomb lenyomásánál annyi történik, hogy amikor lenyomod / felengeded a kapcsolót, akkor a kapcsoló "beszikrázik". Ezért szokták prellmentesíteni a kapcsolót. Ezt te emberi reflexekkel nem biztos, hogy érzékeled, de egy pic programozott reflexei nagyon gyorsak. Le kell lassítani azt a beolvasást mondjuk tized másodpercesre. Amúgy is emberi reflexekkel kezeled a kapcsolót. Ha egymás után 3 alkalommal magas-alacsony-alacsony jelszinteket érzékeltél és mindemellett a jelvezeték eredeti állapota magas volt, csak akkor meghívod a rutint, ahol végrehajtod a magas->alacsony élátmenet rutinját. Eltárolod továbbá egy változóban, hogy az aktuális jelszinted alacsony. Ha a kapott jelszintek alacsony-magas-magas, és a letárolt eredeti jelszinted alacsony, akkor hívod az alacsony->magas feldolgozó rutint, és persze el kell tárolni az aktuális új szint értékét is. Az egymás utáni jelszinteket úgy lehet egyszerűen vizsgálni, hogy beolvasod a jelszintet a carry-be, alacsonytól magas helyiérték felé beshifteled a 0. bitre, és az addigiakat feljebb shifteled. Aztán csinálsz egy érték összehasonlítást a munkaregiszter alsó 3 bitjére (a felsőbb biteket egy AND 0x07 művelettel kinullázod, így azok tuti nem zavarnak majd be). Precízen prellmentesíteni sajnos nem a világ legegyszerűbb dolga. Viszont ha egyszer kidolgoztad, azt elrakhatod magadnak, mert az az eljárás sosem fog cserbenhagyni. Az egyszerűbb megoldások viszont igen.
Szia.
Nekem kicsit magas, nem rég próbálkozom ezzel a pic-es dologgal kisebb-nagyobb megszakításokkal.
Ne izgasd magad vele, nem kell túlbonyolítani! Most bőven elég, ha azt az algoritmust követed, amit leírtam. A késleltetések 15-30 ms időtartamúek legyenek. Hosszabbra venni azért nem érdemes, mert akkor a nagyon rövid gombnyomásokat "nem veszi észre" a program.
Egy alternatív, de hasonlóan egyszerű megoldást majd a programmegszakítások kapcsán lesz érdemes megtanulni. A bonyolultabb, precíz pergésmentesítő módszereket pedig meghagyhatod akkorra, amikor majd az atomrakéta-indító gomb kezelését programozod... 
Egy pénzbedobó automata enyhén gyakoribb eset, és biza elvárás a precizitás, különben összeszidnak téged a különbözet miatt.
Atomrakéta indító gombot meg nem kell prellmentesíteni. Max több rakétát lőssz ki, de ha úgyis a totális kicsinálás a cél, "nem fog megártani" még egy rakéta
Hello!
Azt szeretném kérdezni, hogy mennyire fontos a PIC-nek a pontos programozó feszültség? Mert nekem 12 V helyett olyan 11.65-11.70 V-om van.
Szia!
Nézd meg a kérdéses kontroller programozási adatlapját, egy 16F628-nak elég, a 16F84-nek kevés... Szia
Köszi a gyors választ!
Sajnos pont 16F84-esről lenne szó...
Tudsz valami infót adni a kérdéses égető áramkörről? Hogyan állítja elő a +12V-ot? Esetleg fel lehet piszkálni valahogy 12-ig.
Hát a Watt-féle LPT portos égetőről lenne szó...a 12 V-ot adapterről venném le és ebből állítok elő 5V-ot stabilizátorral.
Ma megnéztem egy másik adaptert is. Az 11.9 V-ot (+/-2V) ad le. Az elég a programozási módhoz? Néztem az pic adatlapját is, de sehol nem találtam a Vpp szórására utalást.
VIHH paraméter min és max értékét keresd! PIC18F4550 esetében pl. 9,0 V - 13.25 V közötti érték lehet.
Ha véletlenül nem lenne benne az adatlapban, akkor az adott PIC programozási (értsd: programbeégetési) specifikációjában benne van.
Köszi a segítséget, de igazából így sem találtam meg az adatlapban
 ,de ez már az én hibám... Viszont máshol megtaláltam: 12-14 V kell hozzá, szóval akkor kevés az a 11.9 V...
Nem olyan bonyolult, hiszen PDF-ben is lehet keresni. A PIC16F84 adatlapjában egyetlen helyen találtam meg a VIHH nevet, ott azt írja: lásd a programozási pecifikációban! A PIC16F8X programozási specifikációban pedig mindjárt a legelején is írják, hogy Vpp-hez 12-14 V-os tápegység kell.
Egyébként információt úgy érdemes keresni, hogy a Google ablakába azt írod be, hogy: PIC16F84 site:microchip.com A legelső találatok között ott lesz a PIC16F84 honlapja, ahol összeszedve minden fontos dokumentum megtalálható: adatlap, errata, programozási specifikáció, releváns alkalmazási mintapéldák, a midrange család kézikönyvének fejezetei,stb.
Köszi tényleg a türelmet, meg a segítséget is.
Most ismerkedek még csak ezekkel az adatlapokkal... Használtam a amúgy a keresőt, csak nem a programozási adatlapban kerestem.
C fordító hibalistát dobott ki. Ilyesmikből van 103 darab üzenetem:
Valamit elfelejtettem beilleszteni a projectbe. De mit? Ezt az üzenetet a linker küldte, nem a compiler. Headerek rendben kellene hogy legyenek.
Nem próbáltál véletlenül egy netről letöltött C fájlt közvetlenül megnyitni és fordítani? Mert az az elérési út nagyon erre utal, a C fordítók meg nem szeretik az ilyesmit. Csinálj egy mappát úgy, hogy C:\pic\feltegla_pic_c és abban próbálkozz. Persze nem muszáj a C-re, a lényeg, hogy semmi szóköz, ékezetes betű és egyéb ilyesmi ne legyen benne. Vagy lehet, hogy a fórum húzott szét valamit, csatold egy txt fájlba a fordító összes üzenetét.
Óh mamám, most nézem csak, mit művelt a fórum string helyettesítő az elérési útvonalakkal.
De nem, nincsen itten netről semmi sem. A "D:\feltegla_pic_c\" egy helyi könyvtár. Abban van benne a cumó, és ott fordítom. Amivel jellegében sem tudok mit kezdeni, hogy ezt az üzenetet nem a compiler dobta, hanem a linker. Az a fura temp könyvtár a linker temp file könyvtára. Az összes, amire panaszkodik, azok mind SFR-ek. Mind a 103 alkalom ilyen. Elvileg azok headerben rögzített nevek, és a compiler után már csak címzési bináris értékek szabadna, hogy legyenek. Erre a linker visszadobja nekem a regiszterek neveit. Hogy a bánatba tud az egyáltalán a linker szeme elé kerülni? Lehetséges lenne, hogy a kétlépcsős fordítás main.c-je dobta azt az üzenetet, és az assembly pic alapot nem találja a fordítóm? Edit: hibalistát csatoltam szöveg file-ban.
Legjobb lenne, ha a komplett projektet feltennéd becsomagolva, akkor jobban bele tudnánk nézni. De legelőször nézd meg, hogy a fordítónak be vannak-e állítva az elérési útvonalai. Project->Build options->Project->Directories és ott a Show directories for mellett menj végig az include, library és linker script search path útvonalakon.
Újrarántom a teljes fejlesztői környezetet, hátha az segít. Az utóbbi időben elég sokat vacakoltam telepítésekkel, és már a path-ot is illene kipucolni, mert vagy 3x benne ragadtak a könyvtárak. Meglesem, egy reinstall után is megmarad-e a probléma.
A PIC header állománya valamiért nem töltődött be, az összes "panaszkodás" ennek következménye.
A lehetséges okok: - kifelejtetted amegfelelő include direktívát - elírtad a fájlnevet - nincs megfelelően definiálva az elérési útvonal |
Bejelentkezés
Hirdetés |
:\feltegla_pic_c\main.
