Szia!

Az uart megszakítás kiszolgáló rutinja jó prioritású megszakítás kiszolgáló programban van? Hiba esetén kolvasod-e a RCREG -et? Vett karakterenként csak egyszer szabad a RCSTA és RCREG regisztereket olvasni, az RCREG olvasása törli a megszakítás kérést és lépteti a vételi fifo-t. A Baud beállítását előbb fejezném be, csak aztán engedélyezném a vételt.

Sok 18F kontroller küzködik a movff utasítás hibával, amikor a cél a WREG, STATUS, BSR és interrupt vezérlő regiszterek. Nézd meg, hogy köztük van-e. Ha a PIC18F14K22 is ilyen, akkor a megszakítási rutinokat alacsony prioritásúnak kell deklarálni / a mentéselet programból kell végezni...

MPLAB SIM-ben van-e arra valamilyen formában lehetőség, hogy egy megadott file regiszter cím írási eseményére tegyek breakpointot, vagy valami trace-ből kibányásszam, hogy hol nyúlt hozzá a programom?

A problémát az okozza, hogy az asm-ben írt firmware-em két azonos "objektumot" kezel, amiknek az összes saját változója indirekt címzéssel érhető el. A SIM-ben futtatva azt látom, hogy a két "objektum" adatterülete nem egyformán változik, az egyikben van két byte, ami szerintem rendellenesen felülíródik. A konkrét címre a forrásban azért is hiába keresnék rá, mert indirekt címzéssel érem el ezt a memóriaterületet, így tehát csak a futás közbeni eseménymegfogás tudna eredményre vezetni. Előre is köszönök minden ötletet!

(Bar mar megbeszeltuk MSN-en, gondoltam masoknak is talan hasznukra lesz)

Debugger menu --> Complex Breakpoints --> Add BreakPoint, ott valaszd ki a Data Memory-t, majd a Symbol/Hex legordulo menubol valaszd ki a regisztert vagy valtozot, es legvegul Breakpoint type: Write, Condition: Always Break.

Köszi, ez működik, most már csak azt kell kiderítenem, hogy tényleg hibás-e, amit annak látok a file registers ablak alapján, és ha igen, akkor hol történik a félrecímzés...

__CONFIG után mivel kapcsolom ki a külső oscillátor módot (PIC16F690)? A rendszeridő elég nekem, viszont kell az RA4&RA5 láb I/O-nak.

Megvan (ez) a hiba! Az adatterületben nem az adatterületen belüli offsetet jelentő egyik címkével, hanem egy globális változó nevét jelentő hasonló címkével pozícionáltam. Az éles, hardveres teszt majd este, otthon. Ez a komplex töréspont nagyon hasznos dolog ilyesmik felderítésére!

Szia!

Nyisd meg a c:\Program Files\Microchip\MPASM Suite\P16F690.INC állományt, a végén találhatók a konfigurációs beállítási lehetőségek. Az _INTRC_OSC_NOCLKOUT látszik a megoldásnak.

köszike és az mért van hogy hiába kapcsolom ki az mclre (_MCLRE_OFF) funkciót mégse tudom RA3-at I/O-ként használni?

Az a láb MCLR kikapcsolása esetén is csak bemenet lehet. Kimenetként nem fog működni.

Sziasztok
A 100nF-os kondi tényleg megodotta a problémám, minden működik rendesen, sőt a behaltnak hitt PIC is teszi a dolgát
Nagyon szépen köszönöm mindenkinek a segítséget!
Sziasztok

mit csináljak ha ezt a hiba üzenetet küldi a winpic800?

A végső és jó megoldás; az egyik kondi 22n, a másik 33n.
Így pontos, nem késik, nem siet

Szia!

Az előbb kérdezted, hogyan lehet a RA4 és RA5 lábakat I/O-nak, valamint a MCLR lábat bemenetnek használni. A PGC és PGD lábakat kimenetnek állítod be. Ilyen beállítás mellett a kontroller a Vdd ráadására azonnal indul, egy - két utasítás után a PGD és PGC lábakat kimenetnek állítja be - a programozó nem tud a kontrollerrel kapcsolatot teremteni.
Két megoldás lehet:
- Use Vpp first programming entry - Vpp bekapcsolásával belépni a programozási módba,
- A program elején, a PGC és PGD vonalak kimenetté állítása elé néhány 10ms késleltetést betenni.

Szia!

A program elejére az endc után meghívtam a var-t de még most sem jó

a watt féle égetővel próbálkozom

Na itt az égető, egy pict tovább fejlesztettem.

Köszi Watt!! :worship:

Gondolom tettél rá még Vdd és Vpp vezérlő tranyókat ugye?

A hibaüzenetből arra lehet következtetni, hogy semmit nem tud beégetni az égető. Lecsekkoltad, hogy rendben vannak a feszültségek az ICSP vonalon(PIC nélkül!)?
A WinPIC800-on van olyan lehetőség, hogy Vpp firts programming? Én még nem használtam ezt a funkciót rajta és most telepítve sincs nem tudom megnézni.

Biztosan nem tud programozói módba lépni a PIC, ha Vdd után indítja a Vpp-t? Ha belép programozói módba, akkor mindegy, hogy a PGD, PGC ki, vagy bemenet nem?
Nekem soha nem volt még ilyen gondom! Ebből kifolyólag a WPB sem támogatja ezt a módot. Sőt, én eddig kifejezetten károsnak gondoltam ha a Vpp hamarabb jelenik meg. A 10k-s felhúzó környékén is gondok lehetnek, erről már korábban beszéltünk, jól is kiveséztük.

Sziasztok, segítséget szeretnék kérni. A mellékelt kapcsolási rajz szerint építettem egy panelt, de icsp-n keresztül nem ismeri fel a pic-et az ICD2. Egyébként, mivel amatőr vagyok elektronikából, ha valami még nem stimmel a rajzon légyszíves jelezzétek.

Üdv.: Muszy

Nem látok 100n-s kondikat a táplábaknál.
Ezen kívül nem látok hibát. Ha az ICSP csatit jól kötötted be az égetőre, akkor ennek működnie kéne a kondik után.

Egy 10u-s, és egy 100n-s kondit tettem az USB után. Egyébként égettem be egy egyszerű led villogtató programot, és az simán ment. Ugyanezzel a csati kiosztással másik panel megy. Átnézem még egyszer a nyákot, hátha ott van valami.

Nem elég a tápon a kondi, Ismétlem, a PIC tálábaihoz kell, azaz ha több van, akkor több! A lehető legközelebb és a lehető legszélesebb vezetékeléssel a panelen. A tápot amúgy is szélesebbel szokás vinni, de ez már itt erősen OFF!

Egyébkén ha olvasnál is nem csak kérdeznél, akkor épp most volt ismételten bizonyítva ennek fontossága. A kérdés-válasz soron vissza lehet menni, ha érdekel miből idnult ki dolog. Bővebben: Link

Szia!

A Microchip hivatalos fórumán olvastam. Volt egy srác, aki vette a fáradságot és visszaküldött a Microchip -nek néhány beprogramozott 16F88 -at, mert még ők sem akarták elhinni. A 18 lábú kontrollereknél bukkant elő (MCLR letiltva, LVP letiltva, T1 oszcillátor engedélyezve), hogy a programozókkal csak egyszer lehetett beprogramozni. Meg tudom erősíteni, hasonlót csináltam én is - akkor olvastam utána. 50ms várakozás a program elején megoldotta a kérdést.
Egy - két hozzászólással később a PIC12F629A -vel kapcsolatban írták, hogy a PGC vagy a PGD a program legelején történő kimenetnek állítása is problémát okozhat. (Ott volt más probléma is - 1k soros ellenállás a vonalakon.)

16F87, 16F88, 16F818, 16F819 a programozást akadályozhatja a T1 oszcillátor kvarca, sőt a kvarcot tönkreteheti a programozás - frissítéskor a kvarc áramkörét meg kell szakítani / a kvarcot ki kell venni.

Ok, végigolvastam, bocs az elhamarkodott kérdésért. Teszek be kondikat.

Szia!
Igen, én is jártam így 18F1320-al. Talán még megvan valahol, elő kéne kotorni!
Akkor nem csak én csodálkozom rajta ezek szerint, hanem a gyártó is! Köszönöm a választ! Igyekszem beletenni a WPB-be ezt a funkciót is...

Rendben, reméljük csak ez volt a baj! Azért nézd át mégegyszer, hátha van valami kis hiba!

Hogy mit és hová(tranyó)?
Csak azt csináltam ami a kapcsolási rajzon volt, egyébként, a vonalak rendben vannak.

Szia!

RB5 / PGM lábat 10k -val a földre, a RC7 / Rx lábat 10k -val a tápra kellene húzni.

Kipróbáltam, mindegy hová vannak húzva ennél a PIC-nél.

Melyiken? Én még a WLPT_mini-nél tartok, de lehet, hogy már keverlek benneteket, amin nem kell csodálkozni!

- Az Rx vonalé majd akkor lesz kritikus, ha megszakításos soros vonal kezelés kerül bele, a lebegéstől vételi hiba lesz, megszakítást okozva minduntalan, a főprogramnak nem lesz ideje futni... (már megjártam egyszer...)
- A PGM vonal lehúzása csak az első programozáskor érdekes - a pic-et engedélyezett LVP -vel kapjuk meg...