Ne minden tizedikben mérj, hanem mindegyikben, de csak annyit, amennyi belefér (2-3 mérés, ha jól számolom), és ezekből számolj átlagot. Persze felvetődik, hogy milyen tranziensek vannak kapcsoláskor, hogy ne mindig abba mérj bele. Ha figyeled a PWM kitöltését is, változtathatod a mérések számát is, a kitöltés függvényében.

Nem...ha Te adod ki a PWM-et, akkor tudod, hogy mettől-meddig tart és csak azalatt mérj !

Üdv mindenkinek!

Egy PIC normál üzemelése közben fellépett hibával kapcsolatban szeretnék némi segítséget kérni.
Egy saját kapcsolásba beépített PIC18F1320 programozásával kapcsolatban lépett fel a hiba.
PICkit3-al programozok, MPLAB X v3.30 IDE-vel. XC8-Compilert használok.

Külső(labor táp), 12V feszültségből egy LM7805C (10µF a bemeneten, 100nF a kimeneten) segítségével 5V feszültséget kötöttem a PIC VDD lábára. A VSS-t pedig a 0 potenciálra kötöttem. Az MCLR lábat összekötöttem 15kOhm-on keresztül az 5V tápfeszültséggel. Mind az 5(VDD,VSS,MCLR,PGD,PGC) lábat rákötöttem a PICkit3 megfelelő pinjeire. Fel is ismerte a kontrollert, rátette a programot többször is. Később köréforrasztottam a még hiányzó áramköri elemeket. A program működését folyamatosan teszteltem közben. A programot breakpointokkal többször meg is állítottam futás közben, hogy a regiszterek tartalmát ellenőrizzem. Program szinten nem volt hiba egyszer sem.

Az RB1, RB0, RA3 lábakra 1-1 LED-et kötöttem, 10kOhm ellenállással, illetve a LEDekkel párhuzamosan IRLZ34N-eket, amik LED szallagokra kapcsolnak 12V-ot. Az egész kapcsolás, illetve program egy futófényt valósított meg. Működött is az egész, a LED-ek sorban fel-majd lekapcsoltak egymás után, ugyanúgy a LED-szalagok.

Aztán akartam változtatni a programon és mikor újra rádugtam a PICkit3-at, a programozás során hibát jelzett.

"Target Device ID (0xfc0) does not match expected Device ID (0x7c0).
Programming...
program memory
Address: 3 Expected Value: ef Received Value: ff
Failed to program device"

Azóta nem tudom a PIC-et programozni. Illetve az RB1-es lábon lévő LED nem villan már fel. A másik 2 lábon a LED-ek és IRLZ-ek zavartalanul üzemelnek.

Van valakinek valamilyen ötlete, hogy mi történhetett a PIC-el? Esetleg tönkrement volna? Miért nem ismeri fel a PICkit3 azt a kontrollert, amit eddig felismert? Ha esetleg kiforrasztanám a PIC-et és egy másik ugyanolyat beforrasztok, megoldhatja a dolgot?

Előre is köszönöm a válaszokat!

A programozó lábakat kimenetként használod? A program elején van késleltetés?

Szerintem ez nagyjából pontos. Hiszen az intervallum 10%-ában mérsz 12V-ot, 90%-ában pedig 0-át. Ha a teljes kitöltés 1018, akkor közel reális a 112. Számold át, hogy ez mekkora feszültségnek felel meg, és ellenőrizd egy multiméterrel. Hogy 8MHz-nél miért mér 202-őt azt nem értem. Ott is utóosztás nélkül 1 KHz a PWM jel? Egyébként keveslem a 4MHz/22 mintát.
Készítettem egy egyszerű tesztprogramot, ami bitbillegtetéssel megmutatja, mennyi idő alatt fut le az ADC 4MHz-n. Az eredményt a mellékelt képen láthatod. Tehát még a keretprogrammal együtt sem lehet több 20usecnél. Az pedig 50 mérés ciklusonként. Ez okozhatja a pontatlanságot.

A programozó lábak beállításait nem módosítottam, csak a programozó vezetékek vannak rájuk kötve. Csak a LED-ekre csatolt lábakat (RB1, RB0, RA3) konfiguráltam kimenetté.
Nincs késleletetés. A main() azonnal meghívja az init_pic() függvényt. Ami így néz ki:

OSCCON=0b01100110; // internal oscillator on FOSC=4MHZ
INTCON=0x00; //default

PORTA=0x00;
PORTB=0x00;
TRISAbits.RA0=0;
TRISBbits.RB1=0;
TRISBbits.RB0=0;
TRISBbits.RB3=1; //input
TRISAbits.RA3=0;
TRISAbits.RA2=0;

AzRB3-ra egy kapcsoló van kötve lehúzó ellenállással, de az működik is. RA0 meg RA2 még nincs használva, egy potit akartam majd odakötni, de azok nem programozó lábak egyik sem.

Talán azért mér 8MHz-en rosszul, mert a Tad idő nincs helyesen beállítva. Már 4MHz-en is kinn van a specifikációból, ezért a Te mérésed is pontatlan, hiszen a javasolt 2us*11=22us az átalakítási idő. A ciklusban levő 32 bites számítás nem tudni mennyi időt visz el, ezt kellene megmérni.

Ezt Mplab szimulátorban hogy tudom még érni? Egyelőre nem tudom miképpen kezdjek neki. Előre is köszi.

Beraksz a programba egy töréspontot (breakpoint), ott meg fog állni a program. A Window>Debugging>Stopwatch mutat egy stoppert, amivel mérheted az időt. A szimulátor órajelét helyesen kell beállítani.

Én PIC18F14K22-vel próbáltam. Adatlap szerint a minimum idő 0,7usec. Tehát a 16 usec konverzió még belül van a határértéken. Persze azt nem kétlem, hogy a don_peter által használt 16-os ennél lassabb. De még úgy is többet kell tudjon 22 mérésnél.

A képen egy mintavétel idő látszik.
Eszerint 64uS

És így szimulátorban számolva 39 mintát tud venni.
A teljes mintavételezési idő 2.5mS-ig tart.

Üdv!
Az RB5-ös lábbal nem történt valami? Ezen a lábon lehet alacsony feszültségű programozásra átállítani. Nekem volt olyan, hogy külső ellenállással ezt akaratlanul átkapcsoltam, és akkor én sem tudtam a PIC-et programozni. Igaz, az PIC16F883 volt.

Bocs, rosszul állítottam be a szimulátort.
Ez lesz a jó kép, itt viszont már komoly gondok vannak:
A teljes mintavételezési idő 10mS, 1 minta vételezése 256uS. (39 mintavételezés fér bele)

Mivel a C-hez változatlanul nem értek, így nem tudom, mit sikerült elrontanod, de ha a PWM frekid 1KHz, az órajeled 4 MHz akkor a teljes mintavételezésed a végén lévő számítással együtt sem lehetne több mint 1,2 mS. Egy analóg mintavételre pedig lehetetlenül sok 256uS.

Ez most 1MHz-en megy. Legalább is az utóbbi képeken.
Ha felteszem 4MHz-re gondolom 4szer gyorsabb lesz vagy is akkor lesz 64uS/minta.

4MHz-es órajelnél az alább látható két kép foglalja össze.
64uS/minta és 1mS/teljes minta.

8MHz-nél, 32uS/1minta és 8mS/teljes minta.

Beindítottam szimulátorban a neked írt programot.
Az első képen az első adat az 5 másodperces kivárás. Utána a teljes mérési ciklus ideje (1,001mS),
végül az osztási művelet a kilépésig (469uS). Azaz a teljes mérés ideje 1,47mS.
A kettes képen egy AD konverzió és a vele futó műveletek ideje van mérve. (19uS)

Ha a PIC16-os lassabb is, 4MHz-n egyedül az AD konverzió ideje lehet több, (ezáltal kevesebbszer mér) de a többi időnek azonosnak kellene lennie.
Ha ez nem így van, akkor hiba van a programodban, vagy a C telerakja minden szeméttel a fordítást.

Megnéztem, nem. Arra a részére a kontrollernek nem is kötöttem semmit. Azóta voltam a fősulin egy professzornál. Ránézett a régi MPLABbal. Kiolvasni lehetett a programot, törölni is, az írásnál viszont mindig ugyanazt a hibát jelezte. Kiolvastuk az írási kísérlet után az assembler-kódot a kontrollerből és a jelzett memóriaterületre valóban hibás érték került. Illetve az első három címén a ProgramCounternek NOP parancs szerepelt, miközben ott egyből a main()-ben lévő kód assembler megfelelője kellett volna, hogy álljon. Arra jutottunk hogy valószínűleg valami megterhelte a chipet és így írásra képtelenné vállt. Kiforrasztottam és IC foglalatot tettem a helyére, hogy egy következő hibánál ne kelljen újra ki-be forrasztani.
A chip-et nem dobtam ki, ha valaki mégis tudná mi lehet a gond, szívesen veszem a megoldást a későbbiekben is.

Ugyan ez látható. Tehát akkor jó a program.
Megvan az 5mp-es időköz is.
1ms a tejes minta és 15 mintát tud begyűjteni.
64uS-t ír egy minta vételi időre.

Az ADC 12uS alatt jön vissza az eredménnyel.
Amiért talán kicsit több idő a kiszolgálás, hogy külön függvényben van az ADC mérése ezért kicsit ugrál a programmemóriában és időt veszt, ha azt közvetlen lenne a megszakításban, akkor ez a 12uS lenne az alap.

Ha törlöd, akkor FF (illetve 3fff) érték kell, hogy ott álljon. A NOP kódja 00.
Ergó minden bitet meg tudott fordítani.
Ne programot próbálj beleiratni, hanem fix értékeket.

Sajna az kevés a pontos átlagoláshoz. Nem tudod valahogy az ADC-t gyorsítani?
Valaki azt írta, hogy 22uS alatt le tud futni. Az még a plusz műveletekkel is csak a fele lenne a mérésednek. 30 mintavételezés javítana az átlagon. Bár a tökéletes méréshez PR2 értékével megegyező számú mintavételezés lenne szükséges. Bár az sem lenne rossz megoldás, ha timer2-re állítanál egy 10-es utóosztót. Ez a PWM frekvenciáját nem befolyásolja, de az időzítést igen, ezért az 5000-et csökkentsd 500-ra. Így 10 ciklust mérne végig, és a mérés ideje, valamint a PWM ideje közti különbségből adódóan nem ugyanazokon a pontokon futnának le a mérések, így jobb átfedést kapnál.

10-es utóosztóval 149 mintát tud venni. (4MHz)
1Mhz-nél 37mintát tud venni ugyan így, 10-es utóosztással.

Nem tudja gyorsítani, ha növeli az órajelet, növelni kell az osztást is. Ennek az AD-je fele olyan gyors, más a memóriaszervezés is (bankokat kell váltani), kár hasonlítgatni.

Ha 10 ciklust mérsz végig átlag feszültséget kapsz. A C program lassú, főleg ilyen szervezésben. A megszakítás elején egyből mérj kettőt, ne legyen feltételvizsgálat, ciklusszervezés, sőt én még a read_AD függvényhívást is kivenném, az is lehet piszkál regisztereket feleslegesen. Mérd meg mennyi idő a 32 bites osztás, bele sem fér az 1ms-os időbe. Szervezd úgy, hogy mindig mér, legfeljebb nem használod fel. A komolyabb számításokat ne a IT rutinban csináld.

1MHz-es órajelnél, 104uS az osztás lefutási ideje.
Alant kép is van róla.

26 ciklus egy osztás? Hmm... nem 0-val osztasz?

Biztos, hogy nem, mert akkor a végeredmény 0 lenne, de terheletlen és terhelve is meg van a feszültség.

Szerintem meg igen, mert a while után ezt látom "Count = 0" így mikor megint a while-ba kerül a következő megszakításnál akkor az "ADC = ADC / Count" viszont nullával való osztást eredményez ami semmi esetre se adhat 0-át végeredményként!

Nem értem, do{} ciklusban gyűjti a mintát, osztás csak utána van. Nem fog nullával osztani.
Count pedig csak osztás után van kinullazva.

0 kitöltésnél 0 -val fog osztani.
if (temp > 0) Count ++;

A szimulátor AD-jén nincs jel, mindig 0-át mér. Valósan lehet nem így van, de az időzítés számításánál átvered magad.