Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Viszont szerintem ez alapján van csinálva:
http://www.geocities.com/vsurducan/electro/PIC/math/ds1620.txt Érdekes itt is BCF CLK - nál olvassa ki. Én sem értem
Ha már példálózunk, akkor a gyártó honlapjáról nézzünk példát.
Itt van egy sorrend a kivitelre C-ben:
Tehát: 1. Reset H 2. CLK L 3. Adat előkészítése a vonalon. 4. CLK H Ez eddig okés, akkor nézzük az olvasást.
Nos, neked volt igazad, mert a gyár is a CLK L után olvassa be a bitet. Ezek szerint ezzel nem lehet baj. Arra gyanakszom, hogy nem vársz elég időt a konverzió elkészüléséig. Ez akár 1sec is lehet, az adatlap szerint. Érdemes lenne a konverziós parancs kiküldése után, annak elkészültét vizsgálni a status bájt beolvasásával. Erre C-ben a példa:
Az egész kód - Itt - található. Nem PIC-re íródott, de a lényeg ebből is látható. Javasolnám, hogy Te is tegyél megjegyzéseket a kódba, mert így csupaszon még magad sem biztos, hogy követni tudod, hát még az, aki megérteni próbálja! Még egy észrevétel. Figyeld meg, hogy minden parancs és a hozzá tartozó beolvasás, ill. kivitel után a Resetet aktiválják. Ez nálad nem így történik. Ezt a menetet is érdemes követni szerintem.
Közben nem hagyott nyugodni, hogy miért CLK L után olvassák ki, mikor az adatlapon látszik, hogy a lefutó élnél nincs még kész az adat, de aztán látom, hogy 35ns(tDC) után az adat már él. Ez egy lassú rendszernél nem okoz gondot. Ennek ellenére a CLK H után 150ns ideig(tCCD) még ott az adat, és én első körben biztosan ott olvasnám ki, de ez most mindegy. Valószínű egy gyorsabb renszer esetében vagy várakozni kéne a CLK L után 35ns-et(tDC), vagy a felfutó él után kiolvasni az adatot.
Tisztelt kollégák!
A mellékelt programrész megoldására kérek segítséget. Ez lényegében egy megszakításban végezendő rutin. Először ellenőrzi, mennyi is a cnt0 értéke, ennek megfelelően ugrik.Három lépésben kellene neki végigcsinálni mindent. Az első OK, a második esetben, amikor ezt csinálja: movfw cnt0 sublw 0x02 a szimultáro szerint az akkuba nem kerül bele a cnt0 értéke (épp ezért nem jo helyre ugrik). Sőt, a rutin végén lévő tmr0 feltöltést sem végzi el... A kérdésem az lenne, hogy én bénázok el nagyon vmit, vagy szimulátorhiba lehet? A PIC egy 16f628a.
1. Nincs a megszakitas kezeloben context saving - tehat a foprogram kontextusa nagy valosiznuseggel elallitodik - ami ha csak egy ures vegtelen ciklus akkor nyilvan nem gond, de ha ott van ertelmes kod is akkor az nyilvanvaloan problemakhoz vezet...
2. Nem allitod be a bankot, ezert ki tudja hova nyulkalsz. Lehet mikor a megszakitas megtortenik egy egeszen mas bankban vagy eppen...
Ezzel a kóddal ránézésre több gond is van (amellett, hogy a működés helyességét nem is figyeltem):
- az interrupt elején sehol nem látom a context mentését és a végén ennek párjaként a visszaállítást; - sehol nem látok bankszelekciós uatsításokat vagy makrókat a változók elérésekor; - case2-nél van két bcf a status regiszterben, ott illene a kívánt bit nevét használni (adatlap szerint ezek a C és DC bitek - biztos ezt akartad?); - movfw utasítás nincs, ez egy makró, ami "movf ... ,w" -re fejtődik ki; kicsit zavaró, hogy mindkét formát használod a kódban.  Persze, a bank... Kedves Trudnai, köszönöm a választ!
Igen, igazad van. A context saving megvan, csak kivettem, hogy rövidebb legyen.
A C, és DC bitek törölgetését csak próbaképp tettem oda, hátha za lesz a baj...de nem az volt.  Köszönöm!
sziasztok,
egy konkrét programozási problémába ütköztem, remélem valaki tud segíteni kicsit.. PIC24F128GB110 chipre írok C-ben programot, egyelőre még nincs kész a hardver, ezért mindent szimulátorban kell csinálnom. nem sikerül az EXT_INT2/3 működtetése. amit csinálok:
és persze meg van írva az ISR is, benne egy Nop()-on egy breakpoint, piszkálom a megfelelő lábat aszinkron stimulálással, de semmi. Az IFS1 regiszterben nem billen be az interrupt flag. A periféria mappinges regiszterek beállítódnak, megy az unlock rendesen. A zavaró analóg perifériát rendesen lekapcsoltam, nem ad warning-ot a szimulátor sem. van valami ötlete valakinek esetleg?
Az aszinkron stimulálás hatására az adott PORTx regiszter megfelelő bitje beáll-e?
igen, az szépen be is állítódik. a TRIS regiszterben pedig csupa 1-es van (alapból is) tehát bemenetként van konfigurálva.
van valami CTPLS funkció is az RP14-en még felsorolva, ezzel nem tudom mi a helyzet, de az RP29-nél biztosan ez a legnagyobb prioritás és mégsem működik a dolog...
az a gyanúm, hogy a peripheral pin select nincs megvalósítva a szimulátorban. más fórumon is előjött egy helyen ez a probléma. nem tudná valaki, akinek van hardvere is esetleg kipróbálni?
Akkor lehet, hogy kellene egy stimulus file-t irnod hozza ami regiszter injektalassal bebillenti neked az IF-et.
Üdv!
Van valami a dologba. Bevallom hogy az időzítések nem igazán ugyanígy voltak a programba ahonnan koppintottam a rutinokat. A DELAY késleltetést én írtam. ezek helyett egy ilyesmi volt: WAIT d'255' A WAIT utáni szám mindig más volt. viszont ez a rutin így volt meghíva: ;Include fájlok (a modulok) #include "C:\Program Files\Microchip\modules\m_wait.asm" viszont így nem tudom lefordítani a programot nem engedi pedig a modult mellékeltem. Hibaüzenet: Error[113] E:\MENTETT\FORUMRA\MODULES\M_WAIT.ASM 84 : Symbol not previously defined (BASE) Error[118] E:\MENTETT\FORUMRA\PROBA1.ASM 57 : Overwriting previous address contents (0000) hogy tudnám azt megoldani hogy a modulokkal együtt is le tudjam fordítani?
Bocsi a modulos probléma megoldódott. Működik lefordította. Viszont még mindig nem ok a kommunikáció.
köszönöm, ez nagyon jó ötletnek bizonyult, most így szépen működik a dolog, aztán remélem majd a kész hardverben is menni fog.
Ennek örülünk.
Viszont legközelebb ne az új kérdés felvetése felirattal válaszolj egy hozzászólásra, ha megkérhetünk.
Én azt mondom, hogy ne időzíts, hanem vizsgálódj! Legalább rögtön kiderül, hogy egy regisztert ki tudsz- e olvasni belőle! Ha beragad a program a DONE bit vizsgálatába, akkor egyáltalán nincs kommunikáció! Rakd fel légyszi a mostani állapotot, illetve ha rászánod magad az ellenőrzéses megírására, akkor majd azt!
Sziasztok!
Ismét segítséget kérnék, egy timer0 interrupt nem akar jol müködni.. [code=c] org 0x04 bank0 MOVWF W_SAVE ;Először a Work regisztert MOVFW STATUS ;STATUS-t bele a már lementett Workbe MOVWF STATUS_SAVE ;Status_save-be beletölti a Worköt bcf INTCON,T0IF ;bit2 clear timer 0 interrupt flag movf cnt0, W sublw 0x03 ; W = CONST-A btfss STATUS, Z ; Check if zero goto case2 ; Z=0, A!=0, false cond'n bsf PORTB,0 ;data nop bsf PORTB,1 ;clck bcf PORTB,0 nop bcf PORTB,1 movlw szaz movwf PORTB decf cnt0,f goto IB case2: bank0 movfw cnt0 nop sublw 0x02 ; W = CONST-A btfss STATUS, Z ; Check if zero goto case3 ; Z=0, A!=0, false cond'n bsf PORTB,1 ;clck Dlay 100 bcf PORTB,1 movf cnt0, W movlw tiz movwf PORTB decf cnt0,f goto IB case3: bank0 bsf PORTB,1 ;clck Dlay 100 bcf PORTB,1 movf cnt0, W movlw egy movwf PORTB movlw d'3' movwf cnt0 goto IB IB: movlw d'100' movwf TMR0 BANKSEL INTCON ;clear the interrpt control register bsf INTCON,T0IE bank0 MOVFW STATUS_SAVE MOVWF STATUS MOVFW W_SAVE ; Re-swap to correct back into w (& avoid changing status bits) retfie A fenti IR-t egyszer szépen megcsinálja (reset után), de mikor másodszor is letelik a T0, a retfie utasítás után ujra a 0x04 cimre ugrik (azonnal). Mit rontottam el?
Bocsi hogy most írok de volt egy kis dolgom. Most már online maradok estig.
Szoval most itt tartok. Megcsináltam az időzítéseket. had rakjam már fel azt a programot is amiről koppintottam. A progi hosszú és már az LCD kijelzés is meg van oldva de csak a kommunikációs részt nézd. Ez működik mert már egy kipróbált project. A forrást mellékelem. Az oldal címe: http://www.tar.hu/masterfoxx/pichom.htm az ipse programjában csináltam egy javítást is. Szerintem elírt egy dolgot: a ds1620 inicializálásánál a write config parancs nem 0xac, hanem 0x0c. Nem tudom de az adatlapból ez jön ki. Viszont ezzel a változtatással sem jó. Idézet: „Mit rontottam el?” Azt, hogy te sem követed a fórumot, és nem próbálsz mások hibájából tanulni, hanem az képzeled, hogy mi itt szeretünk minden kérdést naponta újra és újra megválaszolni. Első: ezerszer el lett mondva, hogy az ilyen Dlay tipusú dolgokat hanyagolni kell, főleg megszakítási rutinba nem szabad tenni. Nálad egyszerűen az van, hogy mire végzett a megszakítás kiszolgálásával, már be is billent újra ugyanaz a megszakítás. Második: nem így mentjük el a contextet a megszakítási rutin elején és állítjuk vissza a végén. Adatlapban szépen le van írva, context saving during interrupts című fejezetben. Ne csak az ott levő kódot másold ki, hanem olvasd is el az egészet! Harmadik: minek akarod bekapcsolni a T0IE bitet, amikor az már eleve be van kapcsolva? Negyedik: a code tag használata is visszatérő dolog itt a témában. Azt is megtanulhatnád már használni!
Kedves Potyo!
Igazad van, figyelmetlen voltam, elnézést kérek érte. A választ köszönöm, az általad irt hibákat javítom. Üdv: acidum.
Nos irtam egy rutint a CALL START_CONVERT meg a 4 időzítés után, a CALL READ_TEMPERATURE - t pedig kikapcsoltam:
ezzel akartam megvizsgálni hogy convertálás után a ds1620 regiszterében a DONE bit mire áll. De sajnos a led állandóan kigyullad mintha immunis lenne a BTFSC feltételre. Az a gond hogy a vizsgálódásom sem működik ha eleve rossz mondjuk a SEND vagy a RECEIVE rész (bármelyik.) Viszont ezek a nagykönyv szerint vannak csinálva. Nagy turpisság van itt.
Nézd meg, hogy ha a LED -et be ki kapcsolod a jelzett pontokon, mennyi ideig világít. 500ms-et elég jól lehet érzékelni, és inkább több időt állíts be, mint kevesebbet.
Na akkor amit az imént írtam, (még akkor nem olvastam a tiéd) nem is aktuális, de azért kipróbálhatod, hogy stimmel-e az időzítés.
Amit próbáltál az egy jó lépés. Ilyen módszerekkel ki lehet és ki is kell szűrni a hibákat, legyen az programban, vagy elektronikában. Sajnos nekem nincs ilyen hőérzékelőm, mert akkor többet tudnék segíteni. A programba nehéz belekötni, mivel az a feltevés, hogy kipróbált és működik, annak ellenére, hogy nem erre a PIC-re íródott, mert nem nagyon van olyan rész benne ami PIC specifikus lenne.
Még annyit, hogy a 0xAC(Read Config) esetében az 1SHOT bitnek 1-nek kellene lenni, mivel az elején be van állítva az inicializálásnál. Ha az nem 1, akkor az egész kommunikció nem megy. Bár ha feltételeznénk, hogy az írás megy, akkor csak az olvasás a rossz. Nincs könnyű dolgod, de ne add fel, meglesz a hiba!
Azt nem értem hogy amikor megírtam azt a vizsgálódást akkor miért hagyja figyelmen kívül a BTFSC - t. Szerintem ez lesz a kulcsa a dolognak. A program minden dolgot megcsinál nem akad el sehol. viszont úgy tudom hogy egy kétállapotú bit vagy 0, vagy 1. Tehát a BTFSC - nek reagálnia kéne rá. maga a BEJOVO_TEMP regiszter akármelyik bitje akkor is nulla ha semmi nem történik. Viszont a BTFSC akkor is 1 nek érzi. vagyis azt a részt nem is nézi vagyis a legutolsó parancs hajtódik végre ami abban az esetmóben BSF LED. Tehát ég a led mint az állat. No mindjárt megcserélem
igen-igen. mindig a második állapot van ami a BTFSC után áll
|
Bejelentkezés
Hirdetés |
