Fórum témák
» Több friss téma |
Az előzőt még kicsit megspékelném egy igen érdekes dologgal.
Van ez a forráskód, ami a 4Mhz-s kristállyal eddig a mobilomon lévő stopperhez képest tökéletes szinkronban volt eddig, most ha a mobil kerek 1 percnél tart, akkor a PICeszköz csak 45mp-nél.
Aztán itt jön a nagyobb csavar. Ha kiszedem a végéről ezt a kis részt, tehát elvileg kevesebb dolgot kellene végrehajtani, tehát gyorsabban kellene hogy számoljon, de NEM, mert így ha a mobilon 1 kerek 1 perc van a stopperen, akkor a PICeszközön csak 33mp
Na most akkor ez hogy is van? Minnél kevesebb a kód, annál lassabb a PIC?
A 32k kristalyt a Timer1 -re tetted csak vagy az egesz PIC azzal ment? Ha az egesz PIC, akkor allitottad a fuses-t? Ha igen, vissza allitottad a 4MHz-hez?
32k eseten nem az volt a baj, hogy akkor a PIC mar tul lassan porog ahhoz, hogy azt a sokmindent idoben evegezz? Szemely szerint jobban szeretem, ha a PIC porog nagy sebesseggel, pl 20 MHz, van egy masik 32Khz kristaly az T1-en ami alvaskor is porog, es igy minel gyorsabban elvegzem a muveletet majd altatom a PIC-et (elmeletileg minel gyorsabban vegzel, annal tobbet tudsz aludni ebresztesig, igy osszessegeben kevesebb a fogyasztas - csak egy otlet amin erdemes elfilozni esetleg)
Alapból 4Mhz-n pörgött a PIC, csak a Timer1 ment a 32.768 Khz-vel.
De sajna mivel 32.768 Khz-ből nem lehet kihozni a pontos 1 tiz4ed másodperces léptetést, ezért visszatöltöttem a biztonsági mentést a kapcsolásból meg kiszedtem a Timer1re kötött 32.768 Khz-s kvarcot. A FUSES-t meg nem bántottam egyik állapotban sem. Szóval minden visszaállt alapra és valamiért lassabb mint volt. De mint írtam, ha kevesebb végrehajtás van a programkódba, akkor még lassabban számol valamiért. Teljesen értetlenül állok már a dolgok előtt. Számomra sokkal logikusabb volna, ha több feladatot kell végrehajtania a programkódnak a main-en belül akkor belassulhat a timer1, de az, hogy ez fordítva van, számomra logikátlan.
Szia!
Pontosan kellene tudni, mit csinálnak a könyvtári függvények... Ha tiltják a megszakítást, törlik a timer1 megszakítási kérését, akkor bekövetkezhet a késés. Még akkor is késhet, ha túl későn törli a megszakításkérést - persze ehhez kitartóan kellene tiltani a megszakítást... Ugyanis ha a feldolgozás alatt befut egy kérés, a kiszolglása alatt, az ok törlése elött befut még egy, akkor az ok törlésével elvész a második kérés. Olvastad a Timer1 errata -t? Egy másik fordítóval nem próbálod ki: Pl. HighTech C?
Probald mar meg ugy hogy a RB IT-t nem hasznalod. Abban van egy 10 ms delay, es ha rafut addig a TMR1 IT nem tud dolgozni. IT kezelesben nem illik Delay-t tenni. A nyomogomb kezelest talan a TMR1 IT alatt meg lehetne oldani, megpedig ugy hogy beolvasod a bemenet allapotat, eltarolod, es a kovetkezo IT alatt osszehasonlitod az elozo allapottal. Amikor ket egymas utani IT-ben a megnyomott allapotot olvasod, akkor bebillentesz egy jelzobitet (int1) hogy gombnyomas volt. Lekezeles utan torlod.
Isten áldjon komám.
Hát erre rá nem jöttem volna magamtól. Kiszettem a delay-t az RB_ISR-ből és egyből jó lett. (Csak nem értem, ezelőtt, hogy-hogy jó volt így is, de lényeg, hogy most már jó.) És így arra is meglett a válasz, hogy miért lassult be a Timer1, ha kevesebb dolognak kellett végrehajtódnia a main-en belül. (Gondolom így, mivel kevesebb dolog volt a mainben, hamarabb jutott az RB_ISR-hez és így sűrűbben futott le ugyan annyi idő alatt a delay.) (Egyébként nem tudom, minek tettem, vagy hogy került oda delay. Nyilván valami kósza ctrl+v lehetett.) Ezer köszönet érte!
Sziasztok!
Találkoztam egy számomra rejtélyes jelenséggel, segítsetek kitalálni mi okozza. PIC16F676 a donor. A kérdéses lábak PORTC0-3 kimenetként, TRISC törölve. BSF PORTC,0 BSF PORTC,1 eredménye az lesz, hogy CSAK a PORTC,1 marad logikai H. BSF PORTC,0 BSF PORTC,1 BSF PORTC,2 BSF PORTC,3 eredménye pedig hogy csak PORTC,3 marad H szinten, tehát csak az a legutolsó port, ahol elvégeztem a BSF utasítást. Elgondolásom szerint egyesével be lehet állítani a biteket, viszont a gyakorlatban nem működik.
Ez az úgynevezett read-modify-write probléma lehet. A bitmanipulációs utasításoknál ugyanis mindig beolvasásra kerül a port pillanatnyi állapota, s a kijelölt bit módosítása után az egész regiszter újra lesz írva.
Ha túl gyorsan jönnek az utasítások egymás után, akkor az első utasítás eredménye még nem látszik (lassan megy fel a feszültség a külső kapacitív terhelés miatt), így visszaolvasáskor nulla íródik vissza. Megoldások: Tegyél be egy kis várakozást az utasítások közé. Vagy használj egy szoftveres buffert, azon tartsd nyilván a I/O regiszter állapotát, azon végezd a bitműveleteteket, s az egészet egyben írd ki. Vagy használj PIC18-at, abban van hardveres buffer (LATA, LATB, LATC,...), ami megoldja ezt a problémát.
Az eredeti feladatot megoldottam más módon, csak érdekelt, hogy miért van a leírt jelenség.
Köszönöm!
Sziasztok.
Nekem is van egy furcsa jelenségem. 12F675 nem hajlandó végrehajtani a DECFSZ műveletet. A szimulátorban szépen működik, a valóságban viszont nem. Szereztem már másik PIC-ket is de ugyanaz. Próbáltam f helyett 1-et írni de semmi. Az adatlapon említi a TMR0-ához rendelést de ez nekem ködös és nem is hiszem hogy ide vonatkozik. Találkozott valaki már ilyen problémával? előre is köszi. Üdv Idézet: Ezt miből gondolod? „12F675 nem hajlandó végrehajtani a DECFSZ műveletet.”
Szóval a 16F84A programozás már elég jól megy és a méretei miatt szerettem volna a 12F675-öst is begyakorolni, azért is mert van analóg bemenet, de semmi sem úgy megy ahogy szeretném.
Ezt gyakorlásra írtam. MPLAB IDE listP=PIC12F675 include "P12F675.INC" __CONFIG _CPD_OFF & _CP_OFF & _BODEN_OFF & _MCLRE_OFF & _PWRTE_OFF & _WDT_OFF & _INTRC_OSC_NOCLKOUT CBLOCK 0x0C T1 T2 LEP ENDC BCF STATUS,RP0 ;Bank 0 CLRF GPIO ;Init GPIO MOVLW b'00000111' ;Set GP<2:0> to MOVWF CMCON ;digital IO - Komparátor kikapcsolása BSF STATUS,RP0 ;Bank 1 CLRF ANSEL ;Digital I/O - Összes láb dihitális módra állítása MOVLW b'00001100' ;Set GP<3:2> as inputs MOVWF TRISIO ;and set GP<5:4,1:0> as outputs ;bsf2007h,4 BCF STATUS,RP0 ;Bank 0 VISSZA: VIS0 BSF GPIO,0 BSF GPIO,1 CALL DELAY BSF GPIO,0 BCF GPIO,1 CALL DELAY BSF GPIO,0 BSF GPIO,1 CALL DELAY BCF GPIO,0 BSF GPIO,1 CALL DELAY GOTO VISSZA DELAY: MOVLW d'150' MOVWF T1 DEL: MOVLW d'255' MOVWF T2 DEL1: NOP NOP NOP BSF GPIO,5 NOP NOP NOP NOP NOP DECFSZ T2,1 GOTO DEL1 BSF GPIO,4 DECFSZ T1,1 GOTO DEL RETURN end A GPIO,5 kigyullad de a négyesig már nem jut el a program
Szia!
A probléma kulcsa a16F675 adatlap 2.2.2 fejezet -ben található meg. Ld.2-2 ábra. A szabad RAM terület 0x20 -tól kezdődik, 0x00 - 0x1F között a speciális célú regiszterek vannak...
Úgy néz ki hogy még egy kis segítség elkelne. Elég kezdő vagyok. Nem tudok rájönni mire gondoltál.
Köszi.[OFF]
"CBLOCK 0x0C "
Ez nem jó benne. Nézd meg az adatlapon hogy ez milyen memória cím.
Hát igen. Itt 0x20-nál kezdődik. Sohasem jöttem volna rá. Betöltöttem és már villog is. Ott csúsztam el hogy az 16F84A programból másoltam.
Még egyszer köszi.  [OFF]
Nincs mit. Amúgy hogy ha kijelölöd Hp41C-nek ezt a hozzá szólásat akkor megkapod a választ:
Idézet: „Szia! A probléma kulcsa a16F675 adatlap 2.2.2 fejezet -ben található meg. Ld.2-2 ábra. A szabad RAM terület 0x20 -tól kezdődik, 0x00 - 0x1F között a speciális célú regiszterek vannak...”
Persze köszönet neked Hp41C az önzetlen segítségért. Észre sem vettem hogy mrobi is válaszol.
 A halványan írt szöveg nálam nem látszik mert sötétebb a háttér.  Egy csomó időt megspóroltam volna.[OFF]
Jól csinálja. Most jöttem rá a trükkre. Így nagyobb az esély hogy ránk kezdőkre ragad valami.
 És a végeredmény is megvan. Mindketten jók vagytok. Köszi.  [OFF]
Sziasztok!
Egyik tanárom készített egy kis doksit. Beleolvasgattam. Véleményem szerint kezdőknek tökéletes. Nem csak a hardveres dolgokat magyarázza el hanem a softveres részeket is. Én csak az assambly nyelvet ismerem de ebből a dokumentumból már elkezdtem C nyelvet tanulni. Nem is olyan nagy ördöngösség. Itt a link!
Köszi a dolgozatot. Kerestem már magyar nyelvű C vagy PASCAL leírást, de elég gyéren találtam. Ez nagyon jó lesz.
Örülök neki hogy tetszik! Persze a C nyelvet ez se teljesen az alapoktól kezdi de szerintem a példákkal nagyon szemléletesen van bemutatva.
MicroSD kártyákkal bírkózott már valaki a közelmúltban? Olyasmit olvastam róla (egy ramtron adatlap említette meg), hogy nagyfrekis környezeti zavarok hatására hibásodhat az adatblokk, ami felkerül a kártyára.
Valós ez a probléma az alkalmazott gyakorlatban?
A Kónya-féle PIC könyv 3. kiadása is viszonylag részletesen tárgyalja a C-ben történő programozást.
Oshonsoft PIC szimulátorban valaki próbált már szimulálni 4-bites LCD kezelést?
Én megírtam a programot, de az Istennek se akart csinálni semmit a virtuális LCD-vel. Úgy voltam vele, hogy biztos elszúrtam valamit, de képtelen voltam rájönni, mi lehet az. Végül ma fogtam a kódot, beégettem egy PIC-be, és egy dugaszolós próbapanelen gyorsan összeraktam egy minimális teszt kapcsolást. Elsőre működött a dolog. Tehát vagy a szimulátor hibás, vagy rosszul állítottam be (habár végigpróbáltam szinte mindent benne). Szóval PORT B, 4-bit high a beállítás, az RS és E jelek a PORT A megfelelő bitjeire vannak konfigurálva. A vicc az, hogy ha megírom 8-bitesre a vezérlést, és csak annyit változtatok a beálításokon, hogy PORT B, 8-bit, akkor egyből megy a szimuláció. |
Bejelentkezés
Hirdetés |
