Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Őszintén szólva semmi hasonlóságot sem látok az általad elmondottak és a program logikája között.
Kezdjük ott, hogy a program a GPIO4-et figyeli, és a GPIO1-et kapcsolgatja... Idézet: „Ebből visszafejteni a programot nagyobb meló mint megírni.” Várj, ne hamarkodd el! Még nem tudjuk, hogy pontosan mi a feladat. 
Ennek úgy kellene működni, hogy a pic kap 5v-ot állandóan.
A GPIO4 re ha kap +5v-ot kb 1s múlva kiadja a GPIO1-re.
A program ennél többet csinál, mert a késletetés(vagy amit csinál) után is megnézi, hogy 1-ben van-e a 4-es láb. Továbbá van(nak) feltétele(i) a lekapcsolásnak is. Közben a program valamiért watchdogot és Timert is kezel, tehát a részleteknek a felét sem hallottuk még.
Meg azt sem hallottuk, hogy egy mezei monostabil multivibrátor miért nem felel meg a feladathoz?
A hexet és a rajzot egy román oldalról töltöttem le.
A lényege ennyi. Beleírtam a tartalmat és egy ellenálláson keresztül egy leddel próbáltam ki. De a tápfesz rákapcsolásakor már van kimeneti jel.
Az eredeti rajzon van ellenállásosztó és védődióda a 12V-os működéshez. Gondolom, ebből legalább a lehúzó ellenállást beépítetted akkor is, ha 5V-tal méregeted. A lebegő bemenet ugyanis akármilyen állapotú is lehet. Szintén csak gondolom, hogy a kimenetre a LED-del sorban tettél áramkorlátozó ellenállást is.
A hex-be belenéztem MPLAB-bal, ahogy icserny is írta, annál kicsit bonyolultabb a működése, ahogy Te azt leírtad, bár nem volt "kedvem" a pontos működést megérteni. Minden esetre a konfig bitek is jónak tűnnek, mert az volt még az ötletem, hogy esetleg ott lehet valami prücök.
El tudná valaki magyarázni hogy a comparator modul és a voltage reference modul hogyan működik és mire lehet használni őket?
Köszi a segítséget, mostmár nagyjából értem. 16f628A-nál van 4 komparátor bemenet és 2 komparátor kimenet, ezeket hogyan tudom használni? Ha mondjuk a 2-2 bemenetre különböző feszültségeket kapcsolok, akkor a kimeneteken lesz az eredmény? Vagy meglehet azt is csinálni hogy a programban adom meg annak a feszültségnek az értékét amit össze kell hasonlítani a külső fesz.-el?
Ja, ertem mar, hogy benzinnel megy az auto, de mi hajtja?
Szia!
A komparátor modulnak többféle felhasználása lehet. A lehetséges módokat az adatlap 10-1 ábrája mutatja be. A külső jeleken kívül egyes módokban egy belső feszültséget, a Vref modul kimenő feszültségét használható a komparátor(ok) egyik bemenetének. Van olyan üzemmód, melyben a komparátorok kimenete egy-egy kivezetésre ki lehet hozni (pl külső áramkörben felhasználható, vagy akár a kontroller másik bemenetére (Timer0 vagy Timer1 bemenetére) vihető). Más típusban, amiben van A/D, a konverzió indítható a kompátor kimenetéről is. A komparátor kimenete (közvetlenül vagy invertálva) kiolvasható programból. Példák: a komparátor segítségével a program meg tudja állapítani, hogy egy feszültség a beállított referencia érték alatt vagy fölött van, két bemenő feszültség közül melyik a nagyobb, stb. A komparátorok (ha a kimenetük vezérli a kontroller lábait) az áramkörben ugyan úgy használhatók, mintha külön ic-ben lennének. A referencia feszültség modul vázlata a 11-1 ábrán látható. VRCON regiszterbe történő írással a referencia feszültség programból állítható. Szia
Attól hogy tudod hogy benzinnel megy még nem feltétlenül tudod vezetni...Teeeee....nagyokos!!!
Szerintem az ilyen beszólásokkal csak magad alatt vágod a fát...
Üdv!
Újra van időm egy kicsit PIC-elni. Bele is futottam gyorsan egy jobb horogba. Annó irtam egy kis egyszerű progit PIC 16F877-20/P -re, most ugyanezt a progit szerettem volna beégetni egy PIC16F877A-I/P prociba. Az égetés sikertelen és az alábi hibaüzenet jön: " Verify failed (MemType = Program, Address = 0x0, Expected Val = 0x1683, Val Read = 0x0)" Ez azt akarná mondani, hogy a 77A-I/P procinak valami program memória cime máshol van? Vagy mi a baja? A progi elején a LIST P=16F877.inc szerepel és igy a 20/P be gond nélkül bement a program. Előre is köszi!
A programozas soran van a problema, nem a forditas soran, tehat ne az INC file-ban keresd a hibat!
A 877A nem teljesen azonos a sima 877-tel, es ezt a programozodnak is honoralnia kell(ene). Nem tudom mit hasznalsz, de ha tudod akkor allitsd be 877A-ra 877 helyett.
Üdv!
Valahol olvastam már a fórumon erről, de most nem találom. Ezért megkérdem újra, bocsi: Szóval eddig még nem csináltam idő mérést, csak a fő órajelről. Most viszont kipróbálom a TIMER1 -re kötött 32768Hz es óraquartzal is. Nem állítottam be prescalert, ezért elvileg mivel 16 bites a számláló, 2mp -enként van ugye TMR1 irg. Ha a megszakítás elején mindjárt feltöltöm a TMR1H -t 128 -al, akkor ugye pontosan 1mp -es megszakításokat fogok kapni ? Jár már az óra pár perce rendesen, de ugye ennyi idő alatt nem jön ki ha egy pici tévedés van az elméletemben.
Nem, ez igy sajnos sohasem lesz pontos. Eloszor is a megszakitasnak is van egy bizonyos kesleltetese, ami egyreszt a megszakitas vezerlobol, masreszt az ISR-edhez hasznalt fuggveny prologjabol ered. Mire oda elersz, hogy a timert beallitsd 128-ra, addigra mar valoszinuleg eltelt egy kis ido es a timer mar nem 0-n hanem X-en all... Azonkivul mikor a timer-t firkalod akkor egy ideig a szamlalas megakad (ha jol emlekszem 2ciklusig, de lehet tevedek). Azonkivul az ora kvartzrol jaratott timer nincs szinkronizalva a PIC fo orajelehez, tehat abbol is adidk egy kicsike bizonytalansag.
Gyakorlatilag meg kell talalnod azt az erteket, amivel pontosan 1mp megszakitast kapsz... Eloszor szkoppal merdd meg, hogy egy labra kiadott negyszog jel mennyire pontosan kozelit 1mp-re. Majd probaldd meg ezt kitolni 10 ill 100 mp-re, majd kesobb egy tobb oras jaratas utan nezdd meg. Elmeletileg eleg pontosan be lehet loni, szilvanak mar sikerult valami hasonlot alkotnia.
Sziasztok!
Ehez a számlálóhoz kellene beégetnem egy 16F88-as picet. Ezt az égetőt építettem hozzá. WinPIC progival próbálkozom, de nem jön össze a dolog. Tanácsokat szeretnék, hogy mivel, hogyan kéne csinálni. Íme pár kép egy próbálkozásról:
Szia!
Szerintem csak az úgynevezett "Interrupt latency" időtől fog változni egy konkrét időpont pontossága. Persze ez az idő sok mindentől függ: Van-e olyan rész a programban, ahol a timer1 megszakítás tiltva van, van-e más megszakítás kezelés is a rendszerben. Ez az idő viszont csak egy-egy időpont kis csúszását jelenheti, nem halmozódik. A megszakítás kezelő függvény prológusa (feltéve, ha ugyan az fut le mindig / Timer1 az első a kiszolgálásban) legfeljebb csúszást okozhat, mert mindig ugyanannyi idő a futása. Az értékadás a felső byte-re vonatkozik, Szerintem 7.8125 ms csak elég a megszakítási rutin lefutására... Viszont van egy másik probléma. Körülményes a Timer1 írása. Az adatlap egyszerűen azt mondja, hogy le kell tiltani a timert az írás előtt és engedélyezni az írás után. E műveletek időigényét kellene a timer1 órajelének egységében figyelenbe venni a korrekciónál. A korrekció viszont az alsó bájtot érintené. Itt jobb az TMR1L+= c / addwf TMR1L,f utasítás használata. Az adatlap nem említi az írás utáni órajel kihagyást. A mellékletben a timer1 írására vonatkozó errata. Nem mindegy, mikor írjuk a timer regisztereit... Szerencsére van egy gyári tipp: A TMR1L írása nem ajánlott, de a TMR1H írható... Pont ez van az idézett kódban... Szia
Ennek így elvileg működnie kell, természetesen a 8 bites írásmód (T1CONbits.RD16=0) beállításával. Az adatlap is ezt a példát hozza RTC üzemmódhoz, csupán annyi a különbség, hogy az interrupt kiszolgálásnál a bit beállító utasítást ajánlják:
Idézet: „Mire oda elersz, hogy a timert beallitsd 128-ra, addigra mar valoszinuleg eltelt egy kis ido es a timer mar nem 0-n hanem X-en all...” 8-bites írásnál ez aligha okoz gondot, hiszen a Timer1 magasabb helyiértékű bájtja csak 7 ms-onként lép egyet van idő az interrupt kiszolgálására . Az alacsony felét (ami 30.5 us-onként lép egyet) meg nem bántjuk.
Tehát ha jól értem, akkor 8MHz-es fő órajel esetén 30 utasításnyi időm van átállítani a TMR1H -t miután túlcsordult és megszakítást okoz a Timer1 .Ez azért talán menni fog. Köszi a válaszokat, mindenkinek !
Áááá Remek!
Valóban, hüm egy kis kihagyás és ez eszembe sem jut. MLAB-ot használok ICD2-vel. Átállitottam a devicét A ra és már fut is a progim csudaszépen a tesztpanelen  Köszönöm!
Ahhoz, hogy a Timer1 ne 2 másodpercenként csorduljon túl, hanem ennek "kerek" számmal történő osztása legyen a túlcsordulási sűrűség (azaz 1, fél, negyed, stb. másodperc), az interruptban a TMR1H valahány felső bitjét kell 1-be billenteni. Ha 1 bittel tesszük ezt, akkor egy másodperc lesz a túlcsordulások között, ha kettővel, akkor fél, és így tovább. Ha a bitbebillentést OR művelettel tesszük, akkor elvileg mindegy, hogy mikor sikerült odaérnünk az interrupt-kiszolgálóval, hogy ezt megtegyük, az idő közben az alsóbb bitekben bekövetkezett számlálás "nem vész el".
Én egy 16F946-tal megépített óra kapcsán dolgoztam így, ott a programfuttatás belső 8MHz-ről megy, így egyáltalán nincs szinkronban a 32768Hz-es Timer1 oszcillátorral. Az volt a tapasztalatom, hogy nem volt mindegy, mikor csinálom az OR-olást a TMR1H-ba, mert az órám állandóan késett, egészen addig, amíg bele nem tettem az OR-olás elé, hogy várja meg a TMR1L változását, és közvetlenül a változás után billentse TMR1H bitjeit. Később valamelyik erratában vagy az adatlap valamelyik passzusában meg is találtam, hogy ez tényleg bekövetkezhet, és eshetnek ki számlálóimpulzusok, ha nem "jókor" piszkálja az ember a TMR1H-t. Miután ez az állapotváltozás-várás bekerült a programba az óra pontos lett, aztán készült még belőle vagy három, mindegyik kielégítően pontos. Az egyik már másfél éve itt ketyeg az asztalom felett a polcon, két perc sietésnél tart az internetről szinkronizált PC órához képest.
Nem, ha nem =, hanem |= operátorral adsz értéket a TMR1H-nak, akkor szinte mindegy, hogy mikor érsz oda a kiszolgálással, egyedül az a lényeg, hogy az ISR ne "harapjon a saját farkába". De gondolom, ez megoldható, mivel ott nem szokott az ember olyan időhúzó dolgokat csinálni. Az értékadás elé a lentebb leírtak értelmében én betennék egy while ciklust, ami addig vár, míg meg nem változik TMR1L.
Idézet: „Az volt a tapasztalatom, hogy nem volt mindegy, mikor csinálom az OR-olást a TMR1H-ba, mert az órám állandóan késett, egészen addig, amíg bele nem tettem az OR-olás elé, hogy várja meg a TMR1L változását, és közvetlenül a változás után billentse TMR1H bitjeit.” Igen, erre emlekeztem, hogy volt ezzel szenvedes. Ez elott a kenyszer varakozas elott meg valami NOP-ozasos kiserletek zajlottak, hogy par NOP a billentgetes elott "hangolta" az oradat?
Ok, vettem, beleteszem az OR olást, és várakozást is. Illetve Or helyett a bsf -et gondoltam. Van olyan C utasítás sorom ami erre fordul, illetve ez pontosan egy OR a C nyelvben. Én ezeket használom:
A maszk az természetesen: 1-2-4-8-16-stb Nagyon klassz ez a fórum, rengeteg segítséget kap itt az ember. Pici gond csak akkor adódik ha a sok információt elő akarja keresni az ember.
Szia!
A hozzászólásomhoz csatoltam a Timer1 errata-t, abban pont az van leírva, hogy a hiba miatt hogyan kell a timer1 regisztereit írni.... Szia
csinalhatsz olyat is, hogy:
...tehat nem maszkot hanem bit szamot adsz meg... De csinalhatsz ilye is pl (C18-ban, mas C-ben lehet, hogy maskepp kell csinalni):
|
Bejelentkezés
Hirdetés |
