Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szia!
Ha jól értem, bizonyos értékek elérésekor módosítod a TMR0-t. Ha így van, az nem jó, mert ha jól tudom, szinte minden, vagy talán minden PIC-nél törlődik az előosztó, ha a TMR0-t módosítod. Mivel az előosztó értéke a módosításkor ismeretlen, így lőttek a pontosságnak. Inkább azt figyelgetném, hogy mikor csordul túl a TMR0, de nem módosítanám. Elméletben, optimalizálás nélkül így nézhetne ki ez a fajta megoldás: Minden túlcsorduláskor megnövelhetsz egy változót 256-tal, majd ellenőrzöd, hogy meghaladta-e a 15625-öt. Ha igen, kivonsz belőle ennyit, és a maradék értéket növelgeted tovább. Minden ilyen, 15625-tel való csökkentés másodpercenként egyszer következik be. A másodpercléptetés párszor 10 ms-ot imbolyogni fog, de egy másodperc átlagosan pontosan egy másodperc lesz (a kvarc pontosságának korlátain belül). A gyakorlatban persze jobb lenne 15625-ről indítani egy két byte-os változót, és minden TMR0 túlcsorduláskor 1-gyel csökkenteni a felső byte-ot. Amint 0 lesz a felső byte, 15625-öt adunk a változóhoz, és növeljük a másodperc-értéket. Ha nem bízol az oszcillátor pontosságában, akkor egy olyan progival ellenőrizd, amiben pl pár led alkot egy bináris számlálót, aminek biztosra tudod a ciklusidejét. Ja, igen. Még valami. Az MPLAB-ban van stopper. Szimulációban jól lehet vele ellenőrizni az ilyesmit, ha beraksz egy töréspontot a másodpercet léptető részbe.
Igazad van, sokfélék vagyunk, sokféle az elképzelésünk. Kérdés, hogy amikor nem értettünk még ehhez, akkor hogyan kezdtünk neki, mik voltak a sarokpontok, és emlékszünk-e ezekre ma, mikor másokat próbálunk a vélt helyes útra terelni.
Én úgy tapasztaltam, nem csak a PIC-ek területén, hogy a felülről építkezés időpocsékolás, ha az a cél, hogy megértsünk valamit. Csináljuk, de nem értjük, és ez űrt teremt az emberben, még ha néha sikerélményben is van részünk. El lehet választani, amikor valaki valamit utánépít, vagy célirányosan szeretne valamit megépíteni használati okból, sűrgősen, és azt, amikor amatőrködni szeretne, megérteni, belefolyni, játszani! Ez utóbbi esetben az idő nem számít, csak a megértés, és a fejlődés. Sok esetben úgy érzi az ember, hogy nem képes megérteni a dolgokat, pedig csak egy olyan elem hiányzik, amit korábban nem értett meg, illetve átsiklott felette. Ezt csak kellő affinitással, kitartással, komolysággal lehet szerintem végezni, aki nem így teszi, csak futó fellángolás lesz a PIC kaland (Ez sem akkora tragédia egyébként.). Sajnos mostanában nem jut időm az oldalam fejlesztésére, túl sok mindenbe kezdtem, remélem utolérem magam és folytatom, mert sok elképzelésem van. A te oldalad szépen fejlődik, minden elismerésem, nagy segítség azoknak, akik már a kezdeti lépéseken túlvannak és fejlődni szeretnének! Végül egy aranymondás, miszerint lehet, hogy két malomban őrölünk, de csak az számít, hogy jól őröljünk!
A CCS PIC Compiler topikban nemrég volt róla szó, hogy a printf() függvény a standard kimenetre ír, s ha ettől eltérő kimenetre akarsz írni a stream (adatfolyam) megadásával, akkor az fprintf() függvényt kell használni.
Idézet: Pedig a tudomány kutatás is így működik. „Én úgy tapasztaltam, nem csak a PIC-ek területén, hogy a felülről építkezés időpocsékolás, ha az a cél, hogy megértsünk valamit.”  De a PIC megismerés területéről is mondanék két példát:- USB-CDC kapcsolaton keresztül (anélkül, hogy fogalmam lenne az USB működéséről) egy egyszerű parancsértelmezővel állítgatom be az ADC regisztereit, s vizsgálom a működést. - Soros porti kommunikáció + parancsértelmező segítségével küldözgetek parancsokat az LCD modulnak, hogy annak működését "élesben" teszteljem. Ilyen esetekben az USB vagy a soros porti kommunikáció, a printf() függvény vagy egy beépített parancsértelmező (ami nagyobb mikrovezérlőknél lehet akár egy beépített FORTH vagy BASIC interpreter is!) csupán ugyanolyan segédeszköz, mint az oszcilloszkóp vagy a digitális voltmérő. Segít láthatóvá, érzékelhetővé tenni a működést. S majd ha az USB vagy a soros port működése érdekel, akkor annak a részleteiben merülök el, akkor arra koncentrálok. De nagyon furcsa volna, ha addig nem használ(hat)nám pl. az USB-t, amíg nincs időm/kedvem a részleteit töviről-hegyire megismerni.
Idézet: „Ilyen esetekben az USB vagy a soros porti kommunikáció, a printf() függvény vagy egy beépített parancsértelmező (ami nagyobb mikrovezérlőknél lehet akár egy beépített FORTH vagy BASIC interpreter is!) csupán ugyanolyan segédeszköz, mint az oszcilloszkóp vagy a digitális voltmérő. Segít láthatóvá, érzékelhetővé tenni a működést.” Hmm, ez egy nagyon messze meno tema, es nagyon hasonlatos a Linux kernel fejleszteshez. Vannak akik eskusznek a debuggerre, vannak akik ellenzik - pl maga Linus is... Nekem meg nem volt szuksegem parancs ertelmezore ahhoz, hogy kiprobaljak valamit, mindig volt programozom vagy bootloaderem, s igy mindig volt lehetosegem letolteni ujabb firmware-t. Amugy nagyon sokszor szimulacion keresztul probalom ki az ismeretlen dolgokat (mar ha nem olyan kulso aramkorrol van szo amihez nincs szimulacios modul). De, hogy watt-ot idezzem: Idézet: „Igazad van, sokfélék vagyunk, sokféle az elképzelésünk.” Idézet: Erre mondhatnám azt is, hogy én "ügyesebben" írtam meg a firware-t, mert módosítanom sem kellett. „Nekem meg nem volt szuksegem parancs ertelmezore ahhoz, hogy kiprobaljak valamit, mindig volt programozom vagy bootloaderem, s igy mindig volt lehetosegem letolteni ujabb firmware-t.”  De nem mondom, mert a lényeg az, hogy akiben van egészséges életösztön(=lustaság), mindig megtalálja a módját, hogy a számára legkézenfekvőbb, legkényelmesebb úton érje el a célját. A korábban említett példáknál kényelmesebbnek és gyorsabbnak tűnt begépelni egy #Akkmmnn formájú parancsot, mint módosítani a firmware-t, újrafordítani, majd letölteni. S nem utolsósorban: miért rongáljam a PIC flash memóriáját fölöslegesen újraprogramozással, ha nem is a programot akarom módosítani, hanem csupán néhány regiszter tartalmát? Más esetekben természetesen én sem csinálom így, csak akkor, ha előre tudható, hogy sok változatot kell próbálni. Idézet: A szimuláció valóban nagyon hasznos segítség. Én is sokat használom. „Amugy nagyon sokszor szimulacion keresztul probalom ki az ismeretlen dolgokat.”
Helló!
Kicsit hanyagoltam a témát, mert más fontosabb projectet csináltam, meg amúgy sincs meló mellett túl sok időm. Mindegy is. Az a lényeg, hogy most megint eszembe jutott, és az is eszembe jutott hogy mondtad hogy próbáljam ki az alacsony teljesítményű módot is, a TIMER1 32K kvarcához. Azért is hanyagoltam, mert az adatlap alapján az alacsony teljesítményű mód, érzékenyebb a zavarokra, ami instabilitást okoz. Ezért nem tulajdonítottam neki túl nagy jelentőséget. Idézet: „The default Timer1 configuration is the higher power mode. As the low-power Timer1 mode tends to be more sensitive to interference, high noise environments may cause some oscillator instability. The low-power option is, therefore, best suited for low noise applications where power conservation is an important design consideration.” Most már tudom, hogy hiba volt. Mondom veszteni nem vesztek vele, csak kipróbálom. És láss csodát, tökéletes. Most már be kellett raknom a megszakításkezelésbe a TMR1H=0x80; sort, és a karórához képest szemre tökéletes. Egész éjszaka (kb 9 óra alatt) nem késett/sietett semmit. Nem gondoltam volna hogy ennyit jelet ez a beállítás (főleg az adatlapot nézve). Miért nem próbáltam én ezt már ki akkor amikor írtad, nem is értem.  Köszi szépen a tippet! 
Arról lehet tudni valamit, hogy milyen gyártmányú/beszerzésű kvarccal szerezted ezt a tapasztalatot?
Azért érdekes, mert nálam egy ismeretlen gyártmányú (talán számítógép alaplapból bontottam) kvarccal pont fordított volt a tapasztalat: nagyobb teljesítményű módban ment stabilan, 2x22 pF-fel, ellenállás nélkül. Különbség van tehát az egyes gyártmányok viselkedésében.
Szia!
Használd a TMR2-t, lehet vele pontosan 1000 -rel, 4000 -rel osztani az órafrekvenciát... A TMR0 és a TMR2 nem múködik sleep üzemben, csak a TMR1...
Igen.
Lomexből rendeltem, 2010.02.05.-én 40-00-93 - 32.768KHz QUARZ D 3X8MM (NSK) ROHS cikkszám - név alatt. Legalábbis ez van a zacsira írva ami itt van a kezemben. Csatoltam egy friss fényképrészletet is. Más nincs a kvarcon. Nem tudom ez mond-e neked valamit. Idézet: „A korábban említett példáknál kényelmesebbnek és gyorsabbnak tűnt begépelni egy #Akkmmnn formájú parancsot, mint módosítani a firmware-t, újrafordítani, majd letölteni. S nem utolsósorban: miért rongáljam a PIC flash memóriáját fölöslegesen újraprogramozással, ha nem is a programot akarom módosítani, hanem csupán néhány regiszter tartalmát?” Hmm, egy regiszter tartlmat debuggerrel is meg lehet modositani, nem?  De mindegy amugy, mert ahogy irtad nem a modszer a lenyeg, hanem az eredmeny. Debuggerrel pedig nem lehet algoritmust kiprobalni dinamikus modon, egy interpreterrel viszont igen -- tehat nyilvan ilyen ertelemben igazad van.Amugy szerintem a program memoria ujrairhatosagi szama nem annyira kritikus, hisz ha jol emlekszem a 'leggyengebb' PIC-ek is tizezerszer irhatok ujra, de szamoljunk most csak ezerrel. Tehat veszek 10 db-ot fejlesztesi celra es legrosszabb esetben is tizezerszer probalhatom ki a firmware-em mire mukodik. Ez szerintem eleg nagy projectekre is elegendo kell legyen, bar lehet rosszul latom a kerdest?
Köszönöm az információakt. A felirat láthatóan különbözik az enyámtől. Nálad 32KNSK, nálam KDS7A olvasható a tokon. A tiedről (vagy ahhoz hasonlóról) itt találtam egy adatlapot.
Idézet: Igen, az is egy járható út. De ahhoz a PIC14K50 debugolható változata kellett volna, ami nekem nincsen. ("Fából van a kilincsem, oszt' madzag a húzója...")„Hmm, egy regiszter tartlmat debuggerrel is meg lehet modositani, nem?” Idézet: Igen, fejlesztésnél ez így megfelel. Tanulásnál azonban más a helyzet (sok programot kell fejeleszteni/kirpóbálni, nemcsak egyet csiszolgat az ember), másrészt a költségkeret is szűkebb. Ilyen kor érdemes megnézni, hogy pl. PIC18F4550 újraprogramozhatósági száma 10-szer nagyobb (ha igazat írnak az adatlapban...). Ezért csináltam olyat, hogy a kínlódások árán született programoknál inkább a 4550-et nyúztam, nem a 14K50-et. „Tehat veszek 10 db-ot fejlesztesi celra es legrosszabb esetben is tizezerszer probalhatom ki a firmware-em mire mukodik.”
Sziaztok!
OLvasgattam vicsys oldalán a PIC-es írását és ahol a progit tárgyalja ott van olyan hogy kattintsunk a menü ikonra ott új és ott válasszuk ki a project wizardot, majd mentsünk el. De hova kell kattintani, hogy le tudjam menteni?? 
Szia!
Kilépéskor menti (meg is kérdezi, hogy mentse-e). A Project / Save Project és a Project / Save Project As menüpontokkal is menthető...
Igen erre én is gondoltam de a menüpen az a pont nem elérhető és kilépéskor se kérdez semmit
Ha végigmentél a Project Wizard összes lépésén, akkor a projecnév.mcw és az Output nevű ablakok maradnak nyitva. (A forrás a nevére klikkentve megnyitható.) Ekkor már menthető lesz a project...
Lehet, hogy félreértettél
Idézet: Hova kell kattintani a mentéshez „Majd a "main.pjt"-t mentsük a kreált mappánkba. A felugró ablakban állítjuk a fő paramétereket:” Idézet: Mostmár csak azt lenne jó tudni, hogy miről beszélsz. Az már bizonyos, hogy nem az MPLAB IDE-ről van szó. Abban nincs .pjt „Majd a "main.pjt"-t mentsük”
Bővebben: Link
ezen az oldalon írja vicsys fórumtárs h hozzuk létre a mappát okéé az megvan. Nyissuk meg a progit azis megvan. Kiválasztom a project wizardot azon az útvonalon ahogy ott levan írva. Majd jön az, hogy a main.pjt-t mentsük el a kreált mappába.. de hova kattintok a mentésért vagy mit csinálok, hogy tudjak menteni??
Csak az az információ kellett, hogy ez a CCS C fejlesztői környezetéről szól. Részemről passz...
Hátha ez segít így néz ki miután kiválasztottam a project wizardot
Tipp: Mappa ikon Save All-al próbáltad már?
Nem segít, mert nálam nincs telepítve CCS C. Csak a Project Wizard említése láttán azt hittem, hogy az MPLAB-ról van szó.
Ha jól látom a varázsló nem indult el. Biztosan elment skandináv lottót játszani, vagy a progid nem 100%-os.
Üdv !
PIC24 PWM beállítási gondokkal kűzdök. 128Khz PWM-et szeretnék előállítani legalább 8 bites felbontással. Az órajel 16Mhz+PLL Ha bekapcsolom a pwm-et akkor azonnal jön valami jel és hiába próbálom változtatni a kitöltést nem lesz jó. A pic adatlap és a PWM FRM mást mond ezért nem egyértelmű. Ha timer2-t választom jelforrásnak akkor meg el sem indul a PWM. [code=c] OpenOC1_GB( // Sets OC1CON1 OC_IDLE_CON & OC_SYSCLK_SRC & OC_FAULT0_IN_DISABLE & OC_FAULT1_IN_DISABLE & CMP_FAULT2_IN_DISABLE & OC_PWM_FAULT_CLEAR & OC_TRIG_CLEAR_SYNC & OC_PWM_EDGE_ALIGN, // OC_CONTINUE_PULSE, // Sets OC1CON2 OC_FAULT_MODE_PWM_CYCLE & OC_PWM_FAULT_OUT_HIGH & OC_FAULT_PIN_UNCHANGE & OC_OUT_NOT_INVERT & DELAY_OC_FALL_EDGE_00 & OC_CASCADE_DISABLE & OC_SYNC_ENABLE & OC_TRIGGER_TIMER & OC_DIRN_OUTPUT & OC_SYNC_TRIG_IN_CURR_OC, // Period 2048 , // On-time 1024); Igazából azt sem értem mi az az ON-time, a régebbi pic-eken ha jól rámlik nem volt ilyen, csak a periódus és akitöltési tényező. Egyébként a céleszköz PIC24FJ64GB002
Végeredményben ezzel a sok hókusz-pókusszal az a cél, hogy az alábbi négy értékadás (az OCM bit törlését nem számítom bele) megtörténhessen.
Érdemes volna megnézni szimulátorban, hogy a négy regiszterbe tényleg az adatlap szerint tervezett konfiguráció íródik be. Volt már rá példa a világtörténelemben, hogy a gyári header állományokban egy-két maszk elcsúszott helyiértékkel volt definiálva! Ebből a szempontból bölcsebb volna az OR maszkokat használni. Ehhez definiálni kell az USE_AND_OR szimbólumot, valamint a & művelet helyett a | műveletet kell használni.
Ennek az volna az értelme, hogy az OR maszkoknál hamarabb észrevenni, ha valamelyik bit rossz helyiértéken van. Idézet: Én a többit sem értem... :hide: „Igazából azt sem értem mi az az ON-time...”
Az 1 másodperces probléma úgy láttam, visszatérő itt a fórumon ( is ). Egy kis tudományos segítség hozzá:
Egy másodperces időzítés nulla hibával A lényeg az egyenesrajzoló algoritmusban van.
Helló. Kicsit hülyén érzem magam, mert ez a program nem működik. A proci egy 16f690, a compiler HI-TECH, PICKit2 és Low Count Demo Board
Led1 bekapcsol, de amikor RA5 és VDD közé rakok egy ellenállást, akkor nem kapcsol ki. void Delay(unsigned int sec /* ~15ms/sec */) { unsigned int i; sec = sec * 8; // factor of 15 ms for(i=0; i void configure(void) { __CONFIG(LP & WDTDIS & PWRTDIS & UNPROTECT & BORDIS); TRISC = 0; TRISA = 1; IRCF2 = 0; IRCF1 = 0; IRCF0 = 0; SCS |= 1; } void fut(void) { if (RA5 == 0) { RC0 = 0; } if (RA5 == 0) { RC0 = 1; } } // fut void parazs(void) { } //parazs void csorlo(void) { } //csorlo void stop(void) { } //stop void main(void) { configure(); while (1) { fut(); parazs(); csorlo(); stop(); } }> |
Bejelentkezés
Hirdetés |
