I/O vs. Progr/Debug piny u PIC

[romiadam]

Cavte,
studujem, studujem katalog PIC16F887 a nie som si celkom isty ci som to spravne pochopil. PIC16F887 ma na pine
39 - RB6 a ICSPCLC
40 - RB7 a ICSPDAT
1 - RE3, MCLR a VPP

ICSPCLC, ICSPDAT, a VPP sa pouzivaju na programovanie IO a aj na debugovanie.

Lenze co ak ja pouzijem aj tieto porty ako RB, RB7, a RE3 ci uz ako vystupne (rozsvecuju LED-ku) alebo vstupne (tlacitko).
Bude mi fungovat debugovanie a programovanie? Ak tam bude LED-ka tak piny budu trvale (i ked nie priamo) pripojene na zem cez LED a jeho odpor. Ak tam bude tlacidlo tak v kludovom stave tlacidla na pinoch bude trvale pripojenych (cez odpory) 5V alebo 0V (podla zapojenia) a pri stlaceni tlacidla tam pojde plnych 5V alebo 0V (podla zapojenia).
V katalogu som sa docital, ze pocas debugovania tieto porty nepracuju v rezime I/O. Cize mi tie porty nerozvietia LEDku a ani nezaregistruju stlacene tlacidlo to chapem, ale nebude mu vadit tych trvale pripojenych (cez odpor) +5V alebo 0V?
Pre pochopenie prikladam obrazok. nebude to nepriaznivo posobit na programovanie alebo debugovanie?
Ako sa informacie z IO dostanu do PC ak na pine (cez odpor) je 5V alebo 0V? Co sa stane ak pocas debugovania stlacim tlacidlo (pojde tam priamo 5V alebo 0V). Toto som sa zatial v katalogu nedocital.
Ma stym z vas niekto skusenosti?

[mato3000]

prečo potrebuješ mať zapojený pin na +5V? šak si to sprav opačne.

počas stlačenia tlačítka ti samozrejme v tvojom prípade nepojde programovanie a ani debudggácia. a zariadenie ti vyhodí error.
prečo si nesprvíš to tlačítko niekde inde ?

//Automatické spojenie príspevkov. Pridané po 55 minútach:

nedalo mi, tak ti to sem dopíšem celé.

moja otázočka, načo potrebuješ mať stlačené tlačítko pri programovaní ?? predpokladám že na nič a preto ťa tento problém nemusí trápiť

tvoj problém je asi, potrebuješ pri debuggácii stlačiť tlačítko . a tu máme dva stavy:
1 . prehodíš ho inde a máš po probléme
2. potrebuješ ho práve tam kôli prerušeniu. no ale ty nemusíš pri debuggácii stlačiť tlačítko, stačí ak program zastavíš na vhodnom mieste, zmeníš ručne register INTCON,RBIF vo WATCH a krokuješ ďalej . ak máš správne nadstavené prerušenie tak sa vykoná

[jaromir]

Cavte,
Lenze co ak ja pouzijem aj tieto porty ako RB, RB7, a RE3 ci uz ako vystupne (rozsvecuju LED-ku) alebo vstupne (tlacitko).

Pri debuggovani plati toto:
MPLAB ti nedovoli nastavit konfiguracne bity tak, aby pin 1 bol RE3 a nie MCLR. Ak by sa ti to aj nejako podarilo, tak ti nebude fungovat debuggovanie.
Dalej, MPLAB zapne konfiguracny dit DEBUG (bez ohladu na to, co si nastavi uzivatel), cim piny RB6 a RB7 stratia svoju IO funkciu a sluzia na debuggovanie. Ziadnymi beznymi IO operaciami zvnutra PIC to nemozes zmenit. Samozrejme, ak zvonku pripojis tlacidlo a niektory z tych pinov supnes na zem alebo napajanie, tak debugger strati kontakt s targetom, vyhodi chybu a dodebugoval si. Vtedy treba reset a od zaciatku.

Cize mi tie porty nerozvietia LEDku a ani nezaregistruju stlacene tlacidlo to chapem, ale nebude mu vadit tych trvale pripojenych (cez odpor) +5V alebo 0V?

Spravne si pochopil, pri debuggovani nie su dostupne piny RB6 a RB7 a samozrejme RE3 (MCLR). K RE3 (MCLR) treba pripojit pull-up odpor cca 22kOhm. K RB6 a RB7 nepripajat radsej nic. Ked uz tam musi byt tlacidlo (ktore pri debuggovani nemozes pouzivat), tak ho radsej pripoj trochu neobvykle v pozitivnej logike - teda pulldown odpor a tlacidlo medzi pin a Vdd.
Je to z toho dovodu, ze debuggery pre PIC (PicKit2, 3, ICD2, ICD3) mavaju uz v sebe pre debuggovanie pull-down odpory (4,7-10k), takze dalsi paralelne (s rozumnou hodnotou, povedzme 22kOhm) nemoze uskodit.

Idealne vsak je nemat na RB6 a RB7 pripojene nic, iba programator/debugger. Okrem toho, nikdy nepouzivam interny MCLR, vzdy iba externy - teda v tomto pripade RE3 nemam, ale mam tam MCLR.

[vama]

Zaujimave, ja mam trosku ine skusenosti s debuggom. Ked som mal MCU typu 16F874a (klon 16F877a), tak som mal prave na RB6, RB7 pripojeny mechanicky inkrementacny enkoder, cize mozeme uvazovat ako keby o 2 tlacidlach. Tieto kanaly som mal pripojene v kladnej logike, cize s rezistormi pulldown. Ked som spustil debugg, tak som sa mohol pohybovat s enkoderom, size nebolo to 100% spolahlive, ale ak si dobre pamatam tak pripojenie mi ani raz nevypadlo.

Takze jaromir vysvetli mi, preco mne to fungovalo, ked to vyvracia tvoje tvrdenia? Aksak samozrejme, ze to tlacidlo nemoze byt nejaku dlhu dobu stlacene pocas debuggu.
Je ale pravda, ked netreba, tak na na RB6, RB7 nic nepripajat (ale ja som nemal inu moznost, vsetkych 33 I/O obsadene).

[mato3000]

no lebo si sa netrafil práve do komunikácie, enkoder má krátke zopnutia, ale tlačítkom to odrovnáš, aj mne to občas šlo občas nie, ale pri dlhšom stlačení to spolahlivo zhavaruje. treba dať enkodre na RB4, RB5, len ja mám najčastejšie na RB zapojený LCD

[vama]

Tak to je mozne, ale aj tak pochybujem, ze som mal tolkokrat take stastie, ze som sa netrafil do komunikacie. Myslim si, ze po neuspechu viackrat zopakuje komunikaciu.

[mato3000]

pravdepodobne hej, bude mať nejakú opravu chýb v komunikácii

[jaromir]

Ked som spustil debugg, tak som sa mohol pohybovat s enkoderom, size nebolo to 100% spolahlive, ale ak si dobre pamatam tak pripojenie mi ani raz nevypadlo.

No velmi pravdepodobne preto, ze debuggery drzia pocas debugovania na RB6 a RB7 nejaku logicku uroven, takze sa tlacili proti sebe dva vystupy. Potom zalezi na tom, co z toho "vyhra". Nepoznam vsetky detaily tvojho HW a teda neviem posudit preco to fungovalo, okrem toho neviem co znamena "...nebolo to 100% spolahlive, ale ak si dobre pamatam tak pripojenie mi ani raz nevypadlo."
Nechcel som tu komplikovat rozpravu okolo debuggerov, ale napriklad na mojej stranke http://jaromir.xf.cz/hdeb/bdm/bdm.html je popisane ako funguje debugovanie - ked PICko bezi (a su splnene ostatne podmienky), tak vzostupnou hranou na RB6 sa vyvola BDM mod a PIC caka na komunikaciu s debuggerom. Ale o tom debugger nemoze vediet, pretoze tuto zmenu neinicioval. Ked potom prikazes debuggeru, aby target zastavil, tak to urobi - ale ten uz davno stoji, takze debugger si mysli, ze je vsetko OK. Podla okolnosti sa tento jeden clock navyse na RB6 pine moze ale nemusi prejavit chybou v komunikacii (data posunute o jeden bit).
Co sa debuggerov na 8-bitove PICy tyka, citim sa tam byt celkom doma, lebo jeden http://jaromir.xf.cz/hdeb/hw1/pdeb_hw1.html som si uz navrhol a vyrobil na zaklade informacii, ktore som dlhe mesiace reverzoval a disassembloval.

Takze jaromir vysvetli mi, preco mne to fungovalo, ked to vyvracia tvoje tvrdenia?

Lebo si mal stastie

Je ale pravda, ked netreba, tak na na RB6, RB7 nic nepripajat (ale ja som nemal inu moznost, vsetkych 33 I/O obsadene).

Svata pravda.
Na programovacie/debugovacie piny nic nepripajat, ak aj ano, tak velmi opatrne, ale radsej nic. S PICkami robim uz nejaky ten piatok, ale nikdy by som si takto nekomplikoval zivot.
Ak nie je dost pinov, pouzit vacsie PIC alebo nejak vhodne "upratat" ostatne. Hlavne s tym druhym sa daju obcas robit uplne divy.

[vama]

... size nebolo to 100% spolahlive, ale ak si dobre pamatam tak pripojenie mi ani raz nevypadlo.
...

Tak sam seba si zacitujem , aby som to upresnil, tusim ani raz mi nevypadol debugg, ale obcas sa stalo, ze enkoder neprepol na 1.-x, niekedy ani 2.-x , ale samotny debugg pracovat OK.

...
Ak nie je dost pinov, pouzit vacsie PIC alebo nejak vhodne "upratat" ostatne.
...

Tak ja by som pouzil aj 50 I/O MCU, ale ziadne z rady 16Fxxx nie je bezne, aj to neviem ci vlastne aj nejake exituje s viac ako 33 I/O v tejto rade?

[jaromir]

Tak ja by som pouzil aj 50 I/O MCU, ale ziadne z rady 16Fxxx nie je bezne, aj to neviem ci vlastne aj nejake exituje s viac ako 33 I/O v tejto rade?

Toto je dobra vec: http://www.microchip.com/maps/main.aspx alebo http://www.microchip.com/stellent/idcpl ... e=en544123# zvolis si vlastnosti ake chces a
Vychadza mi z toho PIC16F946, 16F1946, 16F1947, 16F1526, 16F1527

Alebo prejdi na PIC18F, z PIC16 je to pomerne jednoduche, tam mas este vacsi vyber. Ale o tomto snad uz aj separatne diskusne vlakno...

[romiadam]

Sorry chalani, trosku som bol zaneprazdneny a nemal som cas sem kuknut na vase reakcie.

Dovod preco som sa toto pytal je ten, ze mi dosli I/O a potreboval som este jeden I/O na rozvietenie LED. Len som si nebol isty ci to MCU bude vadit alebo nie. Kym som este od vas nedostal odpovede tak som to "riskol" (bez toho ze by som si bol isty co sa stane) a pripojil na RB7 LEDku cez odpor 100 ohmov.
Chovalo sa to tak, ze pocas programovania MCU LEDka bikala (... je to logicke preco) a pocas debugovania trvalo svietila. Cize RB7micka bola mimo prevadzky. Ked som MCU odpojil od pickit2 a spustil sa MCU tak RB7micka fungovala ako I/O a ledka fungovala tak ako treba podla programu.

Zaver:
Predpokladam, ze obdobne je to aj s RB6, teda v pripade LEDky, sa daju pouzit aj RB6 a RB7, avsak pocas debugovania su mimo prevadzky. Cize sa neda pocas debugovania sledovat ci sa LEDka rozsvieti alebo nie pretoze trvale svieti.

So spinacmi som to neskusal, lebo som uz nechcel riskovat pustit do MCU/Pickitu primo 5V alebo 0V bez odporu (a bez toho aby som vedel ze cosa stane). Len som chcel vediet ze ci sa daju pouzit alebo nie. Ale jaromir uz vyssie spomina zapojenie s tlacidlom (cez pull down odpor) a ak tam uz ozaj musi byt, tak sa nesmie stlacit (strata komunikacie) a v debugovani to je trochu neprakticke. Ja tam ani nechcem davat tlacidla (komplikvat si zivot), skor LED. A ako vidim, s LED na RB7 sa pocas debugu neprerusi komunikacia MCU s pickit2.

Na tlacidla som sa len preto pytal, ze ci je to mozne alebo nie a ci sa to bezne robi.

Samozrejme, ak je dostatok I/O tak nema zmysel obsadzovat RE3, RB6 a RB7. Vtedy sa to necha volne. AKo som vyssie spominal, dosli mi uz I/O.

Este jedna otazocka:
Ak by som na RB6 a RB7 predsa dal tlacidlo (pull down) a stalcim ho pocas debugu (zabudnem sa), bude to vadit MCU?Moze sa poskodit RB6 a RB7? Alebo len sa strati komunikacia?

[mato3000]

nie nepoškodí a môže sa stratiť komunikácia

[romiadam]

Zaver:

Takze ak je to nutne, mozem na RB6 a RB7 dat aj didodu aj spinac, akurat ich nemozem pocas debugovania pouzit (dioda trvale svieti, zatlacene tlacidlo sposobi stratu komunikacie s MPLAB).

Diki vsetkym za rady.