Az MCLR lábat használod a programban?

Nagy valószínűséggel nincs jól a foglaltban, lásd melléklet (nem találtam ettől jobb képet). A képed szerinti állásban teljesen fel, jumper-ek: J1 alul, a többi jobb oldalon.

Nálam a programozó foglalatnak a hátulján, J1-2-es állást mutat, hogy oda kell tenni.

Felső táblázat:
DIP28, 40: J1: 3, J2, J3, J4, J5, J6, J7: 2-3
Kicsit lejjebb, a 38-as és 37-e sláb között mutat anyíl a DIP28-ra, teljesen fel. Az utolsó lába a foglalat 27-es lábáig ér.

Ott a pont, 2-dik napja szenvedtem vele, csak totál félreértelmeztem az egészet. Működik, sikerült feltenni a programot.
Köszönöm

Üdv! Tök amatőr vagyok a témában. Kérdésem a következő. Van 4 db E/SM1630 12F1822 PIC.
Ebből 1 be van programozva a másik 3 nincs. Kérdésem, hogy az elsőn levő programot át lehet-e másolni a másik 3-ra? Ha igen tudna-e valaki ebben segíteni?

Szia!

Ha nincs aktiválva a kódvédelem benne, akkor át lehet másolni...

Ha be van forrasztva, akkor lehet, hogy ki kell forasztani a helyéről. Ha a programozott PIC-ben be van kapcsolv aa kódvédelem, akkor nem lehet másolni.

Az IC-k ki vannak forrasztva. Az egyikről a programot át kellene másolni a másik 3-ra. Nekem nincs ilyen programom se hw-m, amivel ezt meg tudnám csinálni. Mivel egyszeri műveletről van szó, ezért nem éri meg nekem se időben se energiában elmerülni a pic programozásban, illetve beszerezni mindent, ami ehhez kell. Ezért gondoltam, hogy megkérdezem valaki (Aszód, Gödöllő, Budapest környéke) meg tudná-e csinálni nekem? Elviszem a 4 IC-t, átmásolja (ha nincs kódvédelem) a másik 3-ra és kér érte valami elfogadható összeget.

Ha hajlandó vagy eljönni (Bp. 17. ker.), szívesen átmásolom. Magánban megírom, hogy juthatsz el hozzám.

Sziasztok!

DSPIC33FJ-n dolgozok. Igazából teljesen jól működik szinte minden, kódok, RF, A/D konverzió minden. Azonban szeretnék egy ICSP-t feltenni a PCB-re, hogy gyorsan lehessen kódot tölteni rá, meg nem jó, ha sokszor ki/be rakom szerencsétlen ic-t. Korábban olyasmit csináltam, -de már szétszeddtem-, hogy egy kapcsoló leválasztja a tápról, pontosabban GND-t és a tápot is, azaz választani lehetett, hogy a PICKIT3 adja-e a tápot és a földet, vagy a külső tápom. Ez működött is, csak plusz jumperekkel oldottam meg a többi láb leválasztását is. Ezt a lépést ki szeretném hagyni, azaz a kapcsolgatást és a jumpert is.

Szóval olvasgattam az ICSP-ről pár dolgot, de még nem értem pontosan, mert az Angolllal is Cseh-ül állok.

Amit megértettem:
-Nem kell a PICKIT3-nak adnia a tápot és a GND-t sem, az lehet a külső táp is, gondolom mikor a jeleket előállítja ezeket kapcsolja bőszen. Az /MCLR lábra is a tápból tornázza fel a kellő feszültséget, ha jól gondolom.
-MCLR lábat be kell jól kötni, egy diódával védve pluszban a tápegységemet, ezt is értem miért van. (MCLR+12V is lehet néha, az ne legyen kapcsolatban a külső táppal ilyenkor)
A mellkelt ábrán van egy lehetséges kapcsolás.
A PGED1, és PGEC1 lábakra nem kötök semmit, azt fenntartom a programozónak.
-Ekkor az MPLAB-ban nem kell kipipálni, hogy a PICKIT3 adja a tápot, ezt még értem talán.

De.

Mi van akkor, ha valaki (én) véletlenül bepipálja, hogy a Pickit adja a tápot is, miközben rá van kötve a külső táp is, meg a programozó is? Tapasztalataim szerint ilyenkor a fesz szintek nem egyformák, mert a GND -k között lehet különbség. Az egyik ugye a PC-tápról jön, a másik meg 230 trafó, egyenirányítás, meg stab ic-k. Ezért gondolom ezt, mert a logikai analizátor sem ment rendesen, ha nem megfelelő GND-re volt kötve...

Szóval nem kell esetleg a PICKIT3 VDD-re és a GND-re is egy védő dióda? Mi történhet ilyenkor? A PICKIT3 valamihez képest kiad 3.3V-t, a külső táp is valamihez képest kiad 3.3V-ot, akkor ok is lenne, de mi van, ha a GND-k nem egyformák? Ilyen lehet?
Mit kellene pluszban betenni, hogy ezt a hibát is kiküszöböljem tutira? Gondoltam olyasmire is, hogy tranzisztorokkal lekapcsolom a lábakat, ha a PICKIT3 felől van 3.3V, úgy a külső táp nem látna semmit sem ebben az esetben.

Maradjon a lekapcsolás?

Azaz a kérdés arra vonatkozik, hogy a programozót nem kell védeni? Mert ha olyan extrém eset fordulna elő, hogy külső 5V lenne a táp, a pickitben 3.3V lenne beállítva és a GND-k ugyanazon a potenciálon vannak, akkor a külső táp nyer 1.7V-al. Ok, értem, hogy a pickit tudja, hogy milyen PIC van rákötve, meg nem is kaphatna 3.3V-os PIC 5V tápot, de mi van ha?

Próbálom minden hibára felkészíteni, mert néha annyira elfoglal más probléma, hogy figyelmetlen leszek, ami könnyen füstté konvertálja a bakijaimat...

Bizony figyelni kell ra, hogy ne csinalj ilyet. Jo esetben kicsit melegedik es ha idoben eszreveszed akkor semmi gond. Rossz esetben cserelheted a pickitben a 74LVC1T45 tranciever-t(en mar eljatszottam ezt). Gyakorlatilag ez vedi a kontroller kimenetet a pickitben. A vedodioda nem jo megoldas mert a rajta eso 0.6-0.7V miatt nem fog mukodni a Pickit, nem lesz megfelelo a feszultsegszint. Lekapcsolni mely labakat akarod, a kulso tapot? Kerdes mennyire akarod bonyolitani az aramkoreidet.

Melyik programmal szándékozol programozni?
- PICkit3 önálló programjával: Elavult... Ha nem pipálod be a Vdd előtti négyzetet, akkor megnézi a program, hogy van-e feszültség a Vdd vonalon mielőtt rákapcsolná a tápját. Az automatikus típuskeresést le kell felejteni (Manual selest), és előre ki kell választani a családot és a típust. Ezzel azt is eléred, hogy a PICkit3 saját tápfeszültségét 3.3V -ra állítsa be.
-MpLabX IPE: Ez a most támogatott. A programozó általi táplálást nem egyszerű beállítani, de nem is szükséges.

Bekötések:
Az ajánlott bekötés PICkit2 leírásában megtalálható. Figure 2-4

Köszönöm a választ!

Korábban úgy oldottam meg, hogy a kapcsoló tökéletesen leválasztotta a GND-t és a +3.3V-ot a rendszerről.
Ebben az esetben az /MCLR lábat egy jumperrel kapcsoltam, azaz az egyik állásban látta a kondenzátort és az ellenállásokat, a másikban nem, így direktben kapcsolódott a PICKIT3-ra mikor programozta a PICKIT.

A másik két programozó lábbal is így jártam el.

Ez még nem biztos, hogy bolondbiztos, de lehet az is, nem tudom. Elvileg ha így nem okoz a hibás futáson kívül semmi mást, akkor maradhat is így, de ha ekkor is baj lehet, akkor változtatni kell.

Ekkor a legrosszabb eset szerintem a következő:

A kapcsoló külső tápra van állítva, minden jumper a külső forrás állásában van, mintha NEM programoznám. De véletlenül ideges leszek, mert nem jól kódoltam valamit, vagy elfelejtettem MPLAB-ban lefordítani és a régi kódot töltöttem fel, átkapcsolom programozó állásba, de a jumpereket nem rakom át. Ekkor, ha az MPLAB-ban be van pipálva, hogy adja a tápot is, elvileg nem történik nagy baj, hiszen le van választva, azonban az /MCLR lábra és a 2 programozó lábra ki fog küldeni valamilyen feszültségeket. Az MCLR oldalon a dióda elvileg védi a +12V-tól (mihez képest 12 ugye) a külső tápot.

Azonban a másik két lábra is küld óra jelet és adatokat is. Ezzel addig nincs gond, míg minden táp azonos GND-n van/lenne és a feszültségük is megegyezik.

Lehet még egy problémás eset is, ha nincs leválasztva jumperrel az /MCLR lábról a kondi programozás esetén. Programozná a PICKIT3 +12V-al és fel is tölti a kondit, mert a GND-t is a PICKIT3-ról kapja. A +12V-al feltölti, időállandó miatt hibára fut, utána leveszi a +12V-ot akondiról akkorr az milyen irányban sül ki?
Remélem jó irányban... A dióda ezt nem akadályoza.

Erre azt találtam ki, hogy NPN-PNP tranzisztor párokkal kiválasztom az adott ágat, mint egy H-híd meghajtásnál. Ha például jön a külső tápról 3.3V, akkor a PICK /MCLR és a két programozó lábát nem kapcsolja rá a PIC-re ez a plusz áramkör.

Minden ICSP leírásban csak a korábban általam küldött kapcsolást mutatják, de szerintem nem teljesen bolond biztos, illetve nem veszi figyelembe a két táp különbségeit.

De lehet mindez tök felesleges és nem értek hozzá, ebben az esetben bocsi, de éppen ezért kérdezek mi lehetne a jó megoldás.

Lehet, hogy a PICKIT3 eleve megold mindent ilyen problémát, nem tudom, nem értem leírását teljesen. Azonban szeretnék olyan megoldást, ami tuti kikerüli a fentebb SZERINTEM jelentkező gondokat, meg ha van más is akkor azokat is. Kérdezek, ha tudnám a válaszokat és tudnám, hogy amiket feltételeztem teljes badarság, akkor nem kérdezném.

MPLAB IPE 6.X. Eddig tökéletesen megy/ment minden, nincs is sok gond, de tudom, hogy figyelmetlen tudok lenni. Megszoktam az Arduino-t, ott USB-ről ment minden, illetve ha külső tápról megy, akkor is simán lehet programozni USB felől. Ezért sokszor alapvető lépéseket tudok kihagyni a PIC-nél, minél jobban szeretném védeni a saját áramköreimet és a PICKIT3-t is. Szeretném, ha nem menne tönkre semmi sem, ezért parázok kicsit, de lehet túlgondolom, nem tudom.

Jaj. Megzavartak, elvesztettem a fonalat, nem jót írtam.



Mivel le van választva nem lesz nagyobb baj a táp nem látja a dióda nélkül sem a PICKIT /MCLR feszültségét...

De a kondit feltölti. Kicsit belezavarodtam most, át kell gondolnom. Lehet, hogy a sima kapcsolás és a jumper leválasztás minden esetben jó? Azaz nem tudok olyan keverést csinálni az MPLAB-ban sem, ami tönkre tenné? Ha ez igaz, akkor meg is van a megoldás, marad a korábbi megoldás és ok minden.

Ajaj. Nem tölti fel, ha van dióda. Már belekeveredtem rendesen. Báraleírásokban diódát írnak, vagy ellenállást. Ellenállás esetén feltöltheti.

Átgondolom, mert a parázás miatt nem látok tisztán már.

De az lett volna a cél, hogy külső táp esetén is csak rádugom a PICKIT-et és mehet fel a kód, ekkor nem kell kapcsoló, meg jumper meg semmi sem. De ekkor sajnos tudok bekeverni az MPLAB-al, mert bekapcsolom, hogy az adja a tápot, és akkor gond lehet. Ez volt az alap feltevés, de ha ez nem okozna gondot, akkor jó lenne, de mint írták már, igen is lehet baj ebből is. Ezt kellene kiküszöbölni, azaz külső tápról működjön minden esetben és semmiképpen sem legyen baj, ha bepipálom az MPLAB-ban hogy a tápot is adja. Ez lenne a cél, mert akkor könnyű programozni, hibabiztos és jó minden. (nem elég, hogy a fesz szintek eltérhetnek, de a GND-k is összeakadhatnak ilyenkor szerintem)

Nem árt a para, de nem kell belőle sok.
- Ha a programozó adja a tápfeszültséget a kártyára forrasztott dsPIC számára:
A típus kiválasztásával a tápfeszültség automatikusan 3.3V -ra áll. A panelen a futáshoz szükséges tápszűrés van kiépítve, ami túl nagy kapacitiv terhelés lehet a programozó számára. Előfordulhat, hogy Vdd feszültség hibát jelez emiatt.

- Ha a kártya saját tápfeszültségéről programozzuk a dsPIC -et:
Ha programozást indítod, a program megméri az ICSP csatlakozón a Vdd láb feszültségét. Amennyiben megfelelő, nem kapcsolja be a sajátját. Figyelni kell a csatlakoztatásra (a programozó 1. lába a dsPIC MCLR lábára csatlakozzon), ugyanis feszültség alatt kell elvégezni.

Jobb nem használni kimenetnek az ICSP adat és órajel lábakat.

Az automatikus típusfelismerés kockázatot jelent. A keresést ugyan az alacsonyabb tápfeszültségű típusokkal kezdi, de hibás bekötésnék, rossz érintkezésnél nem találja meg a kontrollert és végigpróbálja a nagyobb tápfeszültségű típusoknak megfelelő beállításokkal is.

Tényleg mély víz, de a panelre csak az az bekötés kell, amit az ICSP leírása mutat. Jól meg kell jelölni az ICSP csatlakozó 1. kivezetését a panelen.

Igen, tényleg túlparázom.

Közben megkérdeztem a mesterséges agyat is, azt mondta, hogy a PICKIT3 kellően okos ehhez, azaz megnézni, hogy a külső táp kellően erős-e, illetve a fesz is jó és ha az van, akkor hiába van bepipálva bármi is, akkor is a helyes úton megy tovább. Na ezt nem tudtam, illetve nekem a leírásból sajnos nem jött át.

És igen, nagyon jó ötleteket adtál, vigyázni kell, de most már világosabb a dolog, köszönöm mindenkinek!

A sima ICSP bekötés mehet, mint ahogy a mellékelt kapcsolási rajzon is van, elvieg védi a tápot az MCLR lábtól, illetve a PICKIT3 maga védi saját magát az én össze vissza pipálgatásomtól bizonyos mértékig.

Így megspórolok kapcsolót, meg mást is, remélem működni fog, nem teszek tönkre semmit sem.

A maradék két programozó lábat pedig csak erre a célra tartom fent, nem kötök rá semmit sem.

Srácok, találkoztatok már olyannal, hogy egy PIC egy idő után a PWM frekijét elejti?
A problémás MCU egy P16F684-es.
Kb 6 éve készítettem egy eszközt, amely egy 1KHz-es jelet nyom ki magából. Ezen eszköz random idő után (általában 1év elteltével) elkezdi ejteni a frekit. A másik eszköz, amelyhez készítettem maximum +-5%-os eltérést engedélyez, de legutóbbi hiba mértéke 7% volt. Egyből jelentkezett is a hiba.

A PIC belső órajelét használom, amely tudom, hogy a drasztikusabb környezeti változás esetén tud változni, de ilyen mértékben nem kellene neki. Ráadásul a most meghibásodott rendszer nincs kitéve ilyen változásoknak. (cseréltem PIC-et és 4ből 3 alacsonyabb PWM frekit tolt ki mint anno beállítottam, tehát PIC és PIC közt is lehet különbség.

Van esetleg valakinek tapasztalata vagy ötlete, hogy miért lehet ez? Meg lehet ezt oldani valahogy az eszköz áttervezése nélkül?

Saját következtetésem: A PIC lassan elhasználódik és a belső órajele ennek hatására képes elmászni az eredetileg beállított értéktől ez pedig kihatással van a PWM frekire is mert kötve van a belső órajelhez.

Elméleti megoldás, amin agyalok: a PIC PWM jele vissza van vezetve az egyik analóg portra, amelyen figyelem, mivel amplitúdó modulációval kommunikál a két eszköz. Ezen a szállón gondolnám visszamérni a PWM frekit, de kérdés, hogy ha a belső órajel ment el, a mérésem mennyire lehet majd megbízható, mivel ugyan ahhoz az órajelhez van rendelve a timer is, amivel mondjuk vissza mérhetem a PWM-et. Mi a véleményetek, hogy tudnám automatára megoldani a PWM freki állandó 1KHz-es jelét? Csak szoftveresen, mert a hardverez nem lehet nyúlni.

Itt akkor meg is állt a történet. Időmérés (is) az órajelhez van kötve, ha az mászik, mászik minden vele.

Miért fontos a belső órajel ? Külső kvarcot nem bír el a hardver ?

Mert anno így terveztem meg, de nem számoltam a belső órajel elmászására. Mivel így le is lett gyártva és sok helyen üzemel is az eszköz, így hardveres móka nem jöhet szóba, de jó lenne, ha a szoftvert ki tudnám úgy egészíteni, hogy automatikusan utána állítsa magát, ha elmászik. De sajna minden a belső frekihez van kötve, így balszerencsésen, soha nem tudok értelmesen mérni. Az még egy megoldás lehet, hogy élesben vissza mérem és korrigálom, de ez sok munka mindnél megcsinálni és ki tudja meddig lesz ismét jó.

Hát kicsit "kókány " de megpróbálnám a kvarcot ráaplikálni a pic lábaira ....Ez a legegyszerűbb és legbiztosabbb megoldás .

Nah igen, de sajna használatban vannak a külső kvarc lábak. Marad a szoftveres mókolás most már. Mindig tanul az ember..

Szerk: Ha mondjuk mindenképp hardveresen kell hozzányúlnom, akkor már egy analóg bementet felszabadítani és egy 5-10K-s potmétert beiktatni és azzal kompenzálni, ha elcsúszik a PWM freki.

Ha másként nem, készítesz egy "öcsi panelt", amit a kontroller helyére tudsz forrasztani, az öcsipanelen pedig kvarccal hajtott kontroller. 14 lábú helyett lehet 20 lábú is, ha az eredeti kiépítésben nem tudsz felszabadítani annyi lábat. Ha a kontroller furatszerelt és foglalatban van, könnyen és gyorsan megoldható a csere tüskesorral.

Már ha tényleg tudsz variálni a HW kiépítésén, mert az első feltételed az volt, hogy nem.

Minden módosításnak az a baja, hogy hozzá kell nyúlni. Lehetetlen minden hova elmenni, ahol használatban van ez a cucc. Az a gondom, hogy feltételezhetően minden eszköznél ez elő fog jönni előbb vagy utóbb. A szoftveres megoldás lett volna jó, mert nem lenne nyoma, de sajna észszerűen nem lehet megfaragni a kódot, kelleni fog hardveres piszkálás. El akartam kerülni, de nem tudom másként megoldani. Még az is eszembe jutott, hogy tervezek egy másik panelt és kicsit módosítok rajta, de ugyan abban a méretben és ugyan olyanra, csak még is kicsit más. Akkor lehet majd javítás helyett cserélni egyből. Kicsit bosszant, hogy tesztfázisban ez nem jött ki.

Ha a kommunikáció kétirányú, akkor a másik oldal amit küld ahhoz lehet igazítani magadat. Ez egy tipikus trükk például a kvarc nélküli serialnál, hogy az egyik a master, a másik méri az órajelet és ahhoz igazítja magát.
Ha nincsen semmi módod a másik órajelének mérésére, akkor sajnos nincs megoldás (szerintem), mert ha nincs fogódzó, akkor nincs semmi amihez viszonyítani lehetne a pontatlanságot.
A potival kompenzálást nem javasolnám, ha már hozzányúlnék, akkor én mindenképpen automatikusan jól működő megoldást csinálnék, ami a kvarc alapú órajel, vagy kívülről jövő órajel mérése, és az alapján kompenzálás szoftverből.

Üdv!

A frekvencia változás folytonos? Gondolom igen, de mint mindennek ennek is lehet határa, valami csak megálltja ezt a folyamatot nem? Ha más nem akkor a teljes leállás.

Ha nem lehet hardveresen hozzányúlni, akkor csere. Gondolom nem DIP tokban vannak.

Esetleg egy külső kütyü + szoftveres utánállítás, ha van szabad digitális láb. Olyasmire gondolok, hogy atombiztos stabil jelet kiadni, mérni pl. a timerrel, abból visszakövetkeztetni az óra frekire, onnan meg a többire. De ehhez csak ki kellene menni mindegyikhez.

Ezt tisztán szoftveresen megoldani nem lehet, vagyis én nem tudok ilyen megoldásról.