Problém s PIC16F716

Pomóóc! Navrhnul a postavil jsem si měřák kapacit s PIC 16F716 a teď bych ho rád naprogramoval, ale ICD2 mi nechce zmiňovaný PIC korektně načíst a píše mi “Invalid target device id (expected=0x8D, read=0x8A)” ale pokud MPLAB přepnu do programovacího módu tak je vše v naprostém pořádku a programování i verifikace je OK. Na stránkách Microchipu je napsáno, žePIC16F716 podporuje ICD Debuging, ale v CONFIGWORD vůbec není uvedena položka kterou bych Debuging mohl aktivovat jako např u PIC16F877A. Mám něco špatně nebo jsem si vybral špatný procesor?

Vybral sis špatný procesor. Spousta procesorů ve skutečnosti debugging implementovaný v základní verzi nemá. Potřebuješ speciální verzi např.
PIC16F716 ICD. A ta je docela drahá. Když se podíváš v MPLABu (já mám verzi 8) na Select Device, tak vpravo dole se ti objevuje nutnost použití ICE/ICD Headers. To je ten adaptér se speciální verzí ICD procesoru.

Sice si mě vůbec nepotěšil ba přímo … no raději nic. Ale moc díky za upozornění vůbec jsem o téhle fintičce Microchipu nevěděl,tak si alespoň dám příště pozor. Ušetřil jsi mi spoustu času, který bych zbytečně strávil oživováním Debugingu. A měřák pro tátu asi tekhle pod stromečkem nebude :frowning:

Debuggovat sice nemůžeš, ale simulovat v MPLABu jde! Nemusí vždycky pršet…

To nemusí, ale když si člověk pořídí s velkým nadšením ICD2, potom ho skoro tři měsíce reklamuje a pak hned u druhé konstrukce s ním, si pořídí procesor bez debugingu tak to zamrzí. Zvlášť když to spěchá. Ale to už je teď jedno,navíc u takové prkotiny jako je orientační měření kapacity to tak nevadí. Větší problémje že nemůžu najít ani v MPLABU v7.56 ani na stránkách Microchipu upozornění u kterých procesorů Debuging je a kde ne. Já jsem si zvykl vybýrat procesory podle jejich tabulek kde jsou desítky nejdůležitějších parametrů včetně informace o ICD debuging, viz. link “http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1002&mid=10&lang=en&pageId=74
a volba “Show All Specs” tam je uvedono jen že ICD Debug YES/NO a nic dalšího nebo to jen nevidím?

No, oni u tohohle procesoru mají v položce Integrated ICD-Debug dokonce YES/YES, ale je to nesmysl.

Adaptér 16F716 ICD stojí cca 24eur. Ovšem s dopravou se to prodraží. K debuggingu používám z menších procesorů 16F819 a v některých případech může být dobrá 16F88.

Pokud bys chtěl otci rychle postavit nějaký C metr, tak se zkus kouknout sem. Jsou tam hned tři, ale asi nebudou měřit moc přesně…

Díky za typ,ale o těch stránkách dobře vím- asi před pěti lety jsem nad těmito stránkami začínal s PIC a ikdyž se tam mnoho neděje pravidelně je navštěvuji do dnes.
S měřákem kapacity to vypadá zatím dobře asi to nakonec do vánoc stihnu (pokud mi můj zaměstnavatel nechá aspoň jeden den volna :angry: ) Ale k otázce, doposud jsem pracoval asi se sedmi různými typy PIC ale nikdy jsem se nesetkal s tolika vyjímkami funkce jako v případě 16F716, je to normální i u ostatních procesorů, že jeden či dva piny nejdou nastavit jako plnohodnotné výstupy, ale jen jako výstup s otevřeným kolektorem. Nebo že použití jednoho pinu jako analogového vstupu zruší možnost použití dalšího pinu jako digitálního výstupu? Nějak mi to nejde na rozum, přeci nemůžu vybírat procerory tak že budu do detailů studovat jejich datascheety jestli tam náhodou použití něčeho nevypne něco úplně jiného?

Otevřený kolektor je vcelku častá věc, ovšem obvykle jde analog a digital I/O nastavit naprosto nezávisle. O které piny konkrétně jde?


Už jsem se na to podíval a je mi to jasné. Existuje řešení. Když nastavíš TRISA “analogového” pinu jako Output, tak jako výstup fungovat bude. Platí však jedno omezení - nemužeš vnitřně přečíst jeho stav. Bude se zevnitř jevit jako hodnota nula. A s tím souvisí problém, že při jakékoliv operaci s PORTA s vyjímkou čtení a pak nastavení tohoto konkrétního bitu, se tento výstup vynuluje. To platí i pro BSF. Ale dá se to vcelku rozumně v programu vyřešit.

Spousta programátorů mikrokontroléry nevybírá a používá opakovaně několik v různých velikostech. Není to zase až tak velká chyba. Mnohdy by stačil mnohem hloupější mikrokontrolér, ale proč nepoužít svůj oblíbený, když je jen o 5 Kč dražší :slight_smile:?

A jakými PICkama bys admine vyplnil řadu 16F?

Pokud mi povolíš i 12F, tak by to vypadalo takto:

DIP8 - 12F675
DIP18 - 16F628A
DIP28 - 16F876A
DIP40 - 16F877A

Dovolím si doplnit:
16F628A (50Kč) je určitě dobrá volba v případě, kdy nepotřebuji analogový převodník, respektive si vystačím s analogovým komparátorem. Má ale ještě pro mne jednu zásadní chybu. Nemá In-Circuit Debugger. Už jsem se zmiňoval. Abych mohl využít možnosti ICD2 a debugging bez drahých speciálních obvodů, tak používám 16F819 (70Kč), ten má SSP a nebo dražší 16F88 (100Kč) s UARTEm. Oba dva tyto procesory jdou na rozdíl od 16F628A debuggovat přímo.

Já už jsem také vyléčen z podobného experimentování a s výčtem doporučených PIC po korekci vřele souhlasím, všechny mám odzkoušené a téměř absolutní spokojenost.

Netroufnul by si někdo na podobný výčet v ředě 18F ? Jak je to u této řady s Debugingem? Tzn. podporují ho všechny obvody nebo zase jen některé a u ostatních pouze extra exoti? A je mezi vámi někdo kdo s 18F řadou dělá? Pomalu,ale jistě chystám přechod na tuto řadu a současně přechod z asembleru na C takže budu určitě potřebovat nějakou tu radu a pomoc v začátcích.

Rodina 18F by se dala rozdělit na 18Fxxx a na novější 18Fxxx0.

Jak je to s debuggingem nevím. Předpokládám, že to bude lepší - přece jenom je řada 18 mnohem modernější.

Větší brouky bych napsal asi takto:

DIP28 - 18F252(0)
DIP40 - 18F452(0)