Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „Szóval viccesek ezek a fiúk, de igazából elolvashattam volna a doksikat, mielőtt erre a vezérlőre esik a választásom.” Sajnos az van, hogy hacsak nem elkerülhetetlen, nem érdemes azonnal lecsapni az új típusokra, meg kell várni legalább az első erratakat, hogy lássuk, mire számíthatunk. Egyébként azt írod, hogy a probléma csak akkor van, ha az AD átalakító RC oszcillátorát használod. Van ennek valami oka, hogy nem használod hozzá a rendszer órajelét? Nekem más típusoktól rémlik valami, hogy már 1MHz rendszerórajel felett nem ajánlották az RC használatát az AD átalakításhoz.
A megszokás...
 Holnap majd játszok tovább abba az irányba, amit most sugalltál. Viszont eddig még nem állt le az ADC, azóta, hogy beírtam a fórumra. Kíváncsi vagyok, mit mutat majd ha a rendszerórajelet leosztva használom majd.
Sziasztok!
Már majdnem megépítettem teljesen készre a szilva féle furatszerelt pickit2 klónt / még pár ellenállást kell vennem / . Abban szeretném a segítségeteket kérni, hogy a 18F2550 es vezérlőzét melyik lábra mit és hogyan kötve tudnám felprogramozni..? Rendelkezésemre áll az eredeti Starter Kites Pickit2, sajnos csak kölcsönbe.. :/ Válaszotokat előre is köszönöm
Érintés-értézékeléssel foglalkoztatok már (CTMU modul)? Az újnak hozzá kell érni a fémhez vagy elég ha csak közel van hozzá? Ha egy nyák egyik oldalára rézből alakítom ki az érzékelőt akkor ha a nyák túloldalát érintem meg, működni fog?
Ez szerinted egy haladó kérdés?
 Egyébként vedd elő az adatlapját és nézz fel az oldalamra az ICSP ügyében!
Az ujjnak nem kell hozzáérnie a fém felülethez, nem is nagyon szokás, hogy fém felületeket kelljen fogdosni. Sokszor a szenzorra kerül pl. egy üveg vagy plexi lap, azon keresztül is remekül működik. A kalibrációtól függ, hogy mekkora kapacitásváltozást érzékel "gombnyomásként". A microchip oldalán van fent jó néhány mintaalkalmazás és alkalmazási segédlet.
Szerintem az elgondolásod nem helytálló, mert a NYÁK túloldalán GND fóliának kellene lennie, hiszen a síkkondenzátornak két egymással szemben levő fegyverzete van. Gyanítom ezt figyelembe véve, nem jó, ha a NYÁK túloldalát fogdossuk, mert túl kicsi lesz a kapacitásváltozás. További hátránya a kapacitív érintésérzékelésnek például, hogy amint pl. nedves (vagy piszkos) lesz a felület, elkezd hibásan érzékelni, mert megváltozik a relatív dielektromos állandó. A készülék fém burkolata szintén zavarhatja az üzembiztos érzékelést. Mindenesetre érdemes megpróbálkozni vele, a Microchip AppNote-k alapján szerintem össze lehetne hozni valami működőképes alkalmazást.
Na most egy kicsit frissebben újból elolvastam az errata-t és ezt találom benne:
An ADC conversion may not complete under these conditions: 1. When FOSC is greater than 8 MHz and it is the clock source used for the ADC converter. 2. The ADC is operating from its dedicated internal FRC oscillator and the device is not in Sleep mode (any FOSC frequency). Ami valami olyasmit jelent, hogy az AD átalakítás előfordulhat, hogy nem fejeződik be az alábbi körülmények esetén: 1. Amikor az Fosc nagyobb mint 8MHz és ez az AD converter órajel forrása 2. Az AD converter a saját RC oszcillátoráról üzemel és az eszköz nincs Alvó módban ( bármilyen Fosc frekvenciánál ) Nálam most 32MHz órajelről megy a PIC belső 8MHz-es órajel 4x PLL-lel és az ADC átalakító erről az órajelről megy 64-es osztással. Eddig még nem tapasztalom az ADC leállását. Itt van a beolvasás módja:
Ugyanez a kód az ADCON1-nél Frc-t kiválasztva pár másodperc után nem frissíti az ADRESH értékét. Tehát úgy néz ki, hogy az Fosc/64 megoldás lesz a nyerő. Kíváncsi vagyok, hogy csak ennél az egy példánynál jön ez így össze vagy a sorozatnál is. Meg majd még tovább bonyolódik a helyzet, ha csatornákat is váltok és nem csak az AN0-t akarom folyamatosan olvasni.
Sajnálom, hogy PIC-es téren még nem ütöm meg a haladó szintet
 , bár ezt az ICSP-s dolgot már alkalmaztam a 16F626A és a 16F84 esek égetésénél, csak nem voltam biztos benne ill. nem volt világos számomra, hogy ezt ugyanígy kell másik pic-eknél is :/ Köszönöm az útmutatást..!
Nem az a baj, hogy nem vagy haladó, hanem az, hogy egy olyan topicba írtál, aminek a címében ott van, hogy haladó. Van egy olyan topic is, hogy kezdő...
Minden PIC-et ugyanúgy kell bekötni, ugyanolyan lábakra, de ezt a ICSP cikkben leírtam. Én is PK3-at használók és semmi bajom sincs a használatával. Én főleg 18F típusokat használok, így nem szokta újra rátölteni a firmware-t. Előtte ICD2-m volt (tönkre ment, ezután vettem a PK3-t), de a PK3 sokkal gyorsabban programozza az IC-ket, és a debugolási sebessége is kb. 5-10x gyorsabb. Én teljesen elégedett vagyok vele, megbízható, gyors, kényelmes, kicsi. Szerintem nincs vele semmi baj az új MLAB-okkal.
Hmm ez érdekes. 16F1824 nél is ugyanezt a hibát írták.
Most kipróbáltam én is, 32Mhz (8 belső * 4 PLL) de Fosc/32 osztással, és működni látszik, nem fagy le. Igazából a "may not complete" azt jelenti hogy lehet hogy nem fejeződik be. Nem tudom, merjem-e használni így.
Nem lehet, hogy a tiéd már A3 revíziós? Mert az errata szerint csak az A1-et érinti ez az ADC probléma.
Na ezt most nem tudom megnézni, mert mplab alatt pk2 nem támogatja ezt a picet, csak a saját programjával írtam be a teszt hexet. Az nem irja sehol a device ID t. A pk3 at választva 8.7 es mplab alatt meg nem konnektál, de úgy emlékszem 1x sikerult v.hogy megnéznem, és A1 es volt.
Szerk: átdugtam másik usb portba a pk3 at: Device ID Revision = 00000001 Kicsit bővebben írhattak volna az erratában erről a gondról, hogy pontosan minek is kell bekövetkeznie hogy ne működjön. Mert egy technikai dokumentációban a "lehet" -szót használni vicces. 
A 16F690-es errata-jában meg még érdekesebb jelenségről írnak valamelyik revízió esetén. Az AD konverternél, ha csatornaváltás történik a VP6-os referenciára miközben a korábban kiválasztott csatornán 1,2V-nál nagyobb feszültség került a bemenetre, átmenetileg megzavarhatja a HFINTOSC oszcillátort. Szerencsére ebbe a hibába soha nem futottam bele.
Az aktuális problémámnál maradva, a kettővel korábban közölt megoldásomnál is, ahol a használat végeztével lekapcsolom az ADC-t, folyamatosan frissült az ADRES regiszterpár, de a Fosc leosztásban jobban bízok. Igaz, a programban itt is lekapcsolom az ADC-t az átalakítás végeztével, habár enélkül sem tapasztaltam leállást. A csatornaváltások mellett is ( AN0 - AN3 folyamatos letapogatása ) jól dolgozik az AD átalakítás. Lassan-lassan helyére kerül minden kódrészlet. Idézet: Szerintem arra utalhat, hogy hazárdjelenségek miatt előállhat ilyen hiba --> áramköri szórásból fakad, nem lehet előre megmondani, hogy ilyen vagy olyan bemenő feltételek mellett biztosan bekövetkezik !„Mert egy technikai dokumentációban a "lehet" -szót használni vicces.” Steve
Miért nem okoz a CCP3 modul megszakítást? Szimulátorban várom hogy belépjen, de semmi. Watch ablakban megnéztem, a TMR1 nem számlál. Miért?
Talán meg kellene nézni, hogy a CCP3CON, CCP3PR, stb regiszterekbe valóban betöltődnek a megfelelő értékek.
A CCP3 modul regiszteriet BANKED módon kell címezni. Pl:
Ezek a regiszterek nincsenek az ACCESS BANK-ban.
Inkább így:
Ezt nem írtam, de a Watch ablakban megnéztem és az inicializáláskor minden regiszterbe betöltődik amit szeretnék. De azért kipróbáltam azt amit írtatok, de semmi változás.
Beállítod, hogy a modul melyik prioritáson legyen lekezelve? Engedélyezed a prioritásos megszakítást?
Szia!
Szerintem a fordító a banksel után automatikusan beállítja a BANKED bitet, tehát nem kell sem a "BANKED", sem a "B", sem az 1. Arra figyelj majd, hogy a megszakítás kezelésénél a CCP3IF bitet programból törölni kell.
Persze majd törölve lesz ha eljutok odáig hogy elkezdjem a programot megírni! Egyenlőre egy töréspontot tettem a megszakítás-vektorra és várom hogy oda lépjen, de nem teszi.
Amit kérdeztem megvan? (Megkapod a megoldást, elmész mellette? (IPR4, RCON,IPEN) ???
Szimulálom a programodat, de nem a CCP3 -nal lesz a gond, hanem a TMR1 nem változik.
Idézet: „Szimulálom a programodat,” És neked sem tűnik fel, hogy az IPEN alapból 0? A Timer1 szimulációjával korábban is több gond volt... Idézet: „És neked sem tűnik fel, hogy az IPEN alapból 0?” Figyelembe vettem.... Ha IPEN = 0, akkor egy prioritásos megszakítási rendszer fog működni, hasonló, mint a 16F -ekben, A GIEL bit PEIE értelmezését kell szem előtt tartani. A figure 10-1 szernit az IPR1..4 bitek értéke nem érdekes, mert vagy az alsó vagy a felső ágon jut a magas szintű kérésre... A programban mindkét megszakítás a magas szintű kiszolgáló rutinre fut... Idézet: „A Timer1 szimulációjával korábban is több gond volt...” Sem a Timer1 -et, sem a timer3 -at nem sikerült még ebben a kontrollerben a szimulátorban számlálásra bírnom belső órajelről (több másikban sikerült...), a Timer0 megy.
Gondoltam egyértelmű a kódból, hogy nincs jelentősége a prioritásos megszakításnak:
És azt is írtam hogy nem a megszakítással van a gond hanem hogy a TMR1 nem számlál.
Ha a T1CON.RD16 = 0, a szimulátor szerint TMR1 számol. A CCP3 is működik, törli a TMR1 -et, de a PIR4.CCP3IF nem állítódik 1 -re...
És tényleg! Ha nyolcbites módba állítom a TMR1-et akkor számol, ráadásul nem nyolc hanem 16 bites módban! CCP3 valóban nullázza, de a CCP3IF nem lesz sose 1.
|
Bejelentkezés
Hirdetés |
