Ez elég nehezen értelmezhető. Felfelé megy a feszültség? Vagy közben témát váltottál?

Egyébként milyen típusú PIC-ről van szó (más-más lehetőségekkel rendelkeznek)?

Nem fogalmaztam elég pontosan...A panel LI-ON akkuról jár. tehát elvileg a tápfeszültség 2,7 és 4,2 V között bárhol lehet az akkumulátor töltöttségi szintjétől függően. A PIC (16F648A) tápja stabilizálva van a tápfigyelés miatt amit az egyik komparátorral figyeltetek. Ha működés közben a tápfesz leesik 3,4 V ra a komparátor átbillen, ekkor a PIC még elvégez egy két feladatot (pl batt low jelzést küld SMS ben stb), majd ezek után letiltom a megszakításokat és sleep be küldöm. Tehát a következő ki / bekapcsolásig fel sem éledhet elvileg. Ez azért van így mert a kontroller egy GSM modult vezérel, és a GSM modul 3,4V nál automatikusan kikapcsol és sleepbe kerül. Tehát a PIC nek innentől kezdve nincs feladata.

Az EEPROM ba csak esetlegesen írkálok, pl ha valamely paramétert átállítok SMS vezérléssel. Ilyenkor az sms ben érkező paramétert az eeprom területre mentem, hogy a következő bekapcsoláskor innen ki lehessen olvasni és az új beállított paraméterrel működjön a készülék.Amikor a hiba előjön a program a közelében sem lehet az EEPROM írás rutinnak mivel elvileg alszik...

Hűűűha..jut eszembe..hacsak nem a BOR miatt resetbe nem kerül az alacsony táp miatt...Lehet inkább le kéne tiltani a BOR t..? De első körben eredetileg be sem volt kapcsolva, és olyankor is megvolt ez a jelenség.

Milyen frekivel meg a PIC?

4 MHz es belső oszcillátorról

Még az a lehetőség eszembe jutott hogy a kontrollert kicserélem kisfeszültségű "LF" jelölésű tipusra. Elvileg az F tipus amit jelenleg használok 3 V tól üzemképes, amikor a tápfeszültség 3V alá esik elkezd meghülyülni a kontroller az alacsony táp miatt. Az LF tipus elvileg 2 V ról még elketyeg.. Egy próbát megér, ha kapok egyáltalán még belőle...

A BOR az adatlap szerint valamikor 4,35 és 3,65 V (tipikusan 4,0 V) között következik be. A 3,4 V-ot tehát már nem éri meg a program...

A sleep-be helyezésnél pedig arra kellene ügyelni, hogy se interrupt se más esemény ne ébreszthesse fel a kívánt feszültségszint alatt.

A megszakítások le vannak tiltva, WDT t nem használok, a GSM modul ahonnét esetleg érkezhetne adat a USART on (és a letiltott megszakítások ellenére esetleg bekavarhatna ) szintén sleepben van. Elvileg nem éledhet fel csak resetre, de ha 4.35V alatt már nem is lép közbe a BOR akkor még arra sem.

Természetesen a chipcadnél nincs az "LF" tipusból, rendelni kell, csak hogy ne legyen olyan egyszerű...

Ez valóban nincs leírva szóról szóra, de azért ha alaposabban tanulmányozod az SDCC manual-t, akkor rá fogsz lelni. A paraméterek az FSR2-es regiszteren keresztül mennek át a meghívott függvényekbe. Ha belekukkantasz a lefordított assembly listába, látni fogod, hogy hogyan. Ebbe belemenni egy ilyen egyszerű függvénynél, mint amit a mintád mutat, szerintem nem érdemes. A jó megoldás, ha létrehozol egy globális változót ( valamennyi függvényeden kívül létezőt ), mint itt a példádban a macro_delay. Ebbe a változóba teszed a hivatkozott értéket az assembly részen kívül és már meg is van oldva a feladat:

A helyi változók ( mint például a us ) memóriacímei úgy változnak, ahogy a programodat változtatod. Azokra fixen nem tudsz úgy hivatkozni, mint a globálisan létrehozott változókra. Sőt a helyi változók osztozhatnak is egy-egy memóriacímen, ez a fordító dolga, de a globális az mindig lefoglalja a számára szükségeset. Ezért kell óvatosabban létrehozni a globális változókat, mert hamar felemésztik a memóriát. A lokális változók addig jelentenek memóriafoglalást, amíg az adott függvény véget nem ér. A foglalás abban az esetben továbbra is fennmarad, ha a függvényből egy másikat is meghívsz.
A paraméterátdás mikéntje akkor lesz érdekes, ha bizonyos programrészleteket tisztán assemblyben míg másokat C-ben írsz meg. Az oda vissza hívásoknál már szükséged lesz tudni, hogyan megy végbe a paraméterátadás. Én javaslom, hogy kerüld a fentiekhez hasonló assembly beszúrásokat. Egy for(; ciklussal sokkal egyszerűbb és C szerűbb a megírása.

Köszönöm a segítséged, azt hiszem nincs is több kérdésem.
Nem célom a C és assembly túlzott keverése, csak egy ehhez hasonló időzítő/késleltető függvényt célszerűbbnek tartottam megírni assemblyben, mert így biztos lehetek abban, hogy a fordító nem változtat rajta semmit. Bár lehet, hogy felesleges...

Szia!

Nem lehet, hogy csak a referenciafeszültség nem stabil?
Szerintem mérj rá multiméterrel, és ha ingadozik vagy valami gond van vele, akkor az lesz a hibás.

Lehet lámaként nem kéne beleszólnom, de én inkább analóg műszerrel vagy még inkább szkóppal néznék rá. A digit multiméter elég lassú ahhoz hogy pl. egy msec nagyságrendű ingadozást észrevegyen vele, és az is bekavarhat...

DMultiméterrel is észre lehet venni, ha más nincs, ugyanis ha túl terhelve, akkor le esik a feszültség és ez már nem stabil.
És szerintem, ha csak olyan kicsit változna a feszültség, akkor nem ingadozna neki 20-at is fel le....

Nincs rángatózás se átcsúszás, minde úgymegy ahogy elképzeltem. És igen az áram kevés volt mert sok a led és egy bc182 hajtotta az egészet. Feltételeztem, de programhibára gyanakodtam. Köszi

Sajnos, nem a GIE macerája a gond! KIvettem (mert felesleges), de a bajok nem múltak el. Szimulátorban mindent jól csinál, a panelon meg most RB4 "0" esetén megy az időzítő és a komparátor is, de "1"-nél minden lehal, viszont "0"-nál megint jó. HW vizsgálat következik, de lehet, hogy a JDM égető szívat... Köszönöm a segítséget, pár nap múlva jelentkezem.

Köszönöm az ajánlást, volt benne új infó, igyekszem használni.

LVP bitet letiltottad a konfigurációs szóban?

Én is erre gondoltam, de a "nem ajánlott"-ból attól féltem, hogy még bajt is okozhat. (A polling pedig valóban egy ismételt rákérdezés, pl. négyévenként...) Köszönöm a magyarázatot.

LVP-vel nem foglalkoztam. Kellett volna?

Hát nem ártana, mivel ha nem tiltod le, akkor pont azt csinálja, amit az előbb leírtál.

A nem ajánlott azért van, mert ha a főprogramban kell mindig nézegetni az értékét, az felesleges időt vesz el a kontrolleren futó egyéb feladatok elől, hibás működést önmagában nem okoz. Általánosan igaz egy mikrokontrolleres fejlesztés esetén, hogy amit csak lehet azt a beépített hardverek segítségével végezzük, ez tehermentesíti a kontrollert.

Itt a pont, működik! Egy magamfajta (újra)kezdő autodidakta pákazsonglőr sokmindent összeolvas, de útmutatás nélkül egy labirintusban bolyong. Nem is tudom, van-e még bárhol is ilyen önzetlen segítőkészség. Nagyon köszönöm.

Sziasztok!
CCS-C-ben hogy lehet egy-egy bitet állítani egy :

ilyen meghatározásnál?
Köszönöm!

Jó, rájöttem mindegy....

Sziasztok!
Most egy komolyabb kérdéssel fordulok hozzátok....
Szeretném beüzemelni CCS-C-ből a 877-esem PWM modulját, és ehhez kérnék segítséget...
Annyit megtudtam
Arra már rájöttem, hogy a T2CON-t '00000100b'-re kell állítani (nincs elő-, utóosztó), aztán a CCP1CON-t '00001100b'-re, a PR2 regisztert a kívánt frekvenciára (azt hiszem), meg a CCPR1L kell változtatgatni (Ha jól tévedek...)...
Csak a CCP1CON 4., ill. 5. bitjének funkciójára nem jöttem rá...
Valakinek valami ötlete?

Az adatlap tartalmazza a kérdésedre a választ, érdemes lenne megbarátkozni vele.
A PWM 10 bites, viszont a CCPR1L, amivel a kitöltési tényezőt lehet változtatni, csak 8 bites, emiatt a CCP1CON bitjei közül van fenntartva 2 bit a 10 bites kitöltés alsó 2 bitje számára, mely a CCP1CON 4:5 bitje.

És egy 10 bites változót hogy tudok létrehozni?

Sziasztok!
Múltkor feltettem egy kérdést, most gondoltam megírom mire jutottam vele. A probléma ugye az volt, hogy nem ment az USB kommunikáció. Azt elfelejtettem mondani, hogy párszor kisültem az eszközön, miközben dolgoztam vele. Megpróbáltam azt, hogy a D+ és D- lábakat megrángatom programból, és szkóppal megnézem, hogy mi jön ki rajta. Így azt tapasztaltam, hogy semmi nem jött ki. Tehát a kontrollerben kinyírtam valamit. Volt egy másik ugyanilyen eszközöm, mert kettőt gyártottam le belőle, azt még nem hekkeltem annyira szét. Azon megnéztem, és volt négyszögjel az adott lábain. Erre mikor kipróbáltam, hogy megy-e az USB kommunikációm, azt tapasztaltam, hogy feljött egy felugró valami az óra mellett, hogy nem ismeri fel az eszközt a gép. Ebből arra következtetek, hogy valami miatt elkommunikálnak egymás mellett az eszközök a buszon. Tehát a PC gyorsabb, mint az én eszközöm. Ez mitől lehet szerintetek? Egy kondi értéke lenne túl nagy? Addig resetben van a kontroller? Később kapná meg a szükséges feszültséget? Megrajzolom a kapcsrajzot eagle-ben és csatolom, esetleg megnézné nekem valaki, hogy mi a rossz benne? Azt a kérdést viszont mai napig nem értem, hogy a furatszerelt próbapanelom miért megy ugyan ilyen értékek mellett?
Előre is köszönöm a válaszokat!

Szia!
Az oszcillátor beállítása megfelelő? Ez azt jelenti, hogy a PLL osztó kimenetén 4 MHz-nek kell lenni, különben nem működhet megfelelően az USB modul. Mekkora órajelet használsz és milyen beállítások mellett?
Ha az USB modul megfelelő órajelet kap a bemenetén (48 MHz), akkor nem fordulhat elő, hogy a busz kiessen a szinkronból.