Legutóbb nem sikerült: Bővebben: Link?

Tulajdonképpen mi a kérdés? Attól mert a kódvédelem be van kapcsolva, a PIC-be lehet tölteni a programot, nem változtat kb. semmin csak annyin, hogy nem lehet a kontrollerből kiolvasni a tartalmat, de ha megvan az eredeti hex fájl, ez kb. lényegtelen. Esetleg átírod a fenti módszer alapján.

A kérdés és a probléma az, amikor beírom a hex fájlt,azonnal kiírja az all protect-t,és csak egy darabig fut a program.Ha kiakarom olvasni a programot a proci/PIC16F1789/üres.
Ebből következtettem,hogy az hex fájl írásvédett.

Ugyancsak kiírta még:Waiting for file update,továbbá:click buton again to exit.

Betöltöttem e másik hex-t,ennél nem jelent meg a probléma.

Köszönöm,hogy válaszoltál.

Üdvözlettel:Alita

Ennek a hibának semmi köze ahhoz, hogy a PIC olvasásvédelme be van-e kapcsolva vagy sem.Ez természetes, ezt okozza az olvasásvédelem. Ha a programozott eszközt vagy csak a PIC-et odaadod valakinek, nem tudja kiolvasni belőle a programot.Ezt, ezeket akkor írja, amikor az "Auto Import HEX + Write Device" gombra kattintasz. Ha mégegyszer rákattintasz, kikapcsolod ezt a funkciót. Ennek sincs köze ahhoz, hogy a kontrollerben lévő program csak egy ideig fut. Magát a programot kell vizsgálni, mitől állaht le.

Én is a program hibájára gondoltam,de ez már sok nékem.Hiszen azt írja ki,hogy" a fájl
frissítésre vár."Érdekes még,hogy ehhez a kütyű életre keltéséhez még további három
fájl van letöltve és ezeknél is ugyanaz van.
Gondolom a szerző pénzt szeretne a programért,de akkor miért nem tüntette fel szándékát.
Azt hiszem én feladom egyenlőre.

Köszönöm a segíteni akarásod.

Üdvözlettel:Attila

Ez a funkció/opció a PICKit2 szoftverben van, egyfajta automatikus PIC égetési trükk.

Ha leírod, mit szeretnél, talán többet tudunk segíteni. Milyen három fájlról van szó? Milyen projekt?

Egy fémkereső építését kezdtem meg,ahhoz kellene.
Csatoltan megküldöm a kapcsolási rajzot,és a három hex fájl-t.
A három hex-ből bármelyik megfelelne.

Üdvözlettel:Attila

Téves a pdf.fájl.

Szervusz !

Tegnap tévesen küldtem el a pdf.fájlt.Most csatolom:

Üdvözlettel:Attila

Ebből én nem fogom tudni megállapítani, mitől áll le a kontroller a kapcsolásban. Ha abból a feltételezésből indulok ki, hogy a program jó, akkor még mindig marad sok lehetőség. Pl. zajos/instabil tápfeszültség miatt is lehet ilyen jelenség.

Az áramkör tápellátása kivan kapcsolva,csak a PC USB-ről kap tápot.Ez nem hiszem,hogy zajos legyen.
Én még mindig a hex-ben gondolom a hibát,mert amikor betöltöm a PIC2-ben már kiírja az
all protetc szót,még az égetésre váró proci nincs is csatlakoztatva.
Hasonló hex-nél ez nem fordul elő.
Amikor lefut egy darabig a program,lefagy az égető,bármit is csinálok nem mozdul semmi.
Megkérdezem,TE nem próbáltad ki valamelyik megküldött Hext ?

Hát azt hiszem ennek annyi.

Üdvözlettel és köszönettel:Attila

A másolás védelemmel ellátott hexet csak írd be aztán amikor beírta akkor próbálhatod is. Vissza olvasni nem fogod tudni a védelem miatt. Azzal ne foglalkozz hogy a pickit egy kicsit megakad nagy terjedelmű a program.

Nem próbáltam ki egyik hex fájlt sem, mert egyrészt nincs ilyen kontrollerem, másrészt önmagában a felprogramozott kontroller gyakorlatilag egy ASIC, ami a környezete nélkül nem sok dologra jó.

Az "All protect" részt felejtsd el, nem azzal van gond.



Ezt a részt nem teljesen értem. A program futása áll meg vagy már maga a program feltöltése is problémás? Ha az utóbbi, akkor nagy valószínűséggel az a gond, hogy a PICKit2 nem tud elég energiát szolgáltatni ahhoz, hogy a PIC-nek és a kapcsolás többi részének is jusson. Ha jól látom a kapcsolási rajzon, akkor a PIC tápfeszültsége és a kijelző tápfeszültsége direkt összeköttetésben van, ez így nem jó, legalábbis programozáskor. JC1 eltávolítva programozáskor? PGC láb össze van kötve a DA5.1 nevű valamivel, SCK a VT1 tranzisztor bázisával, PGD a VD2 tranzisztor bázisával.

Ha tutira akarsz menni, akkor a PICKit2-re csak a programozandó PIC-et kötöd, vagy megnézed az áramkör leírását, mit kell tenni ahhoz, hogy beforrasztott állapotban is tudd programozni a kontrollert.

Szervusz Sándor !

Köszönöm a válaszodat.Egyenlőre próbálkozok tovább,megfogadva a tanácsodat.

Szép napot kívánva !

Üdvözlettel.Attila

A program szépen betöltődik,ezt ki is listázza.A program futása akad el,majd egy kis várakozás
után kiírja,hogy a program teljes.De amikor kiolvasnám csak a sok nullát adja.
A kijelző nincs csatlakoztatva,mert az áránál fogva csak akkor veszem meg ha a programozás
sikerrel jár.A csatlakozások a programozó és a programozandó között jók.
A PIC-t csak beforrasztva lehet programozni,mivel 44 lábu smd.csodabogár.

Egyenlőre próbálkozok tovább,hátha csoda történik.

Üdvözlettel:Attila

A program működőképességét csak kész készüléken tudod tesztelni , kijelző nélkül csak beégeted a hex et és gondolkodsz hogy sikerült e . Hogy olvasás védett a hex teljesen lényegtelen mint már többen leírták neked . Milyen csodát vársz ?

Úgy érzem itt többszörösen egymás mellé beszélés megy, a kérdező részéről némi fogalom zavarral.
Tehát ha próbálom értelmezni:

A PicKit betírja a flash be a kódot és ki írja, hogy sikeres.

A vezérlő bent van az áramkörben , a program elakad.
De hová írja ki, hogy a program teljes, ha nincs rajta kijező?

Itt valami nem stimmel...
PIC16F1789 - Config1@2007H címen. Az adatlapja szerint a 8. bit az adat EEProm (CPD), a 7. bit a programtár kiolvasásvédelmét (CP) aktivizálja.
Az "All protect" felírat csak a "FOPT_M2 108 old style.HEX" és a "М2-114h(1).HEX" beolvasása után jogos (config1 = 3E22h), a "FOPT_M20B.HEX" betöltése után nem (config1=3FA2h).

Ha az utóbbit programozod be, vissza kellene tudnod olvasni a programot.
:02000E00223E0F --- sor kiolvasásvédelem aktív.
:02000E00A23F0F --- sor kiolvasásvédelem inaktív.

Felismeri a típust a PICkit2?

Hogy hova írja ki hogy teljes?A PICkit 2-re.de mint írtam kiolvasáskor csak a nagy semmi.Ehhez
nem kell kijelző.
Ha egy égetés sikeres akkor a zöld csík futása,és a kiolvasás jelzi.
Egyébként sok PIC programozáson vagyok túl,de ilyennel még nem találkoztam.

De ebből további vitát nem akarok.

Köszönöm a válaszod,ez sokat mond számomra,megjegyzem.
A PiCkit2 felismeri a típust,ugyanis kb.9 éve PK2DeviceFile-t betettem.Akkor hasonló,de nem azonos készüléknél sikeresen programoztam.

Erre van az olvasásvédelem ... Ez nem hiba csak nem tudod elfogadni ... Azért találták ki hogy ha megépít valaki valamit ne tudják a cuccost "le klónozni" a program működik de nem lehet kiolvasni így az áramkör sokszorosítása sem lehetséges (vagy csak nagy költséggel) És hogy értsd ,én sem vitatkozni akarok nekem mindegy meddig kínlódsz a jó hex beégetésével hidd el mindanyian csak segíteni akarunk ..

Sziasztok !
A hivatalos PICkit 2 (v2.61) programmal és ezzel a HE fórumról származó pk2devicefile_dat -al
sikeresen beírtam egy pic16f1788-ba a hex file-okat , és a verify is sikeres volt.
Az (М2-114h(1).HEX) , és a (FOPT_M2 108 old style.HEX) file-oknál a Configuration beállításokban a 7 , 8 bitet 1-be kellett állítani.

őrkutya

Egy elméleti kérdés : Mikor és hogyan kell- lehet-érdemes használni a picben a WDT opciót ?

Én gyakran használok 1-Wire adatátvitelt. Ott megvan az esélye annak, hogy nem érkezik meg mind a 8 bit, és ezért beragad a program, vagy épp a következő beérkező byte indítja tovább, ezért hibás lesz az adat. Ilyenkor mindíg használok WDT-t. De pl. egy zavarjel is beránthatja a programot vételbe, ahonnan aztán nem megy tovább.
Nem folyamatos üzem esetén, pl. telepes táplálás, időnkénti mintavételezés miatt a PIC alapvetően alszik. A WDT-vel jól tervezhető intervallumokban ébreszteni lehet a PIC-et.

Én mindig használom. Bármilyen ok miatt megakad a program, újraindítja a kontrollert.

Köszi mindkettőtöknek , eddig soha nem használtam de megfogadom a tanácsot .

ADC time

Sziasztok!
Valaki el tudná nekem magyarázni az ADC konverzió beállítását? Itt elsősorban az időre gondolok, alapból tudom használni.
Bővebben kifejtve a problémát: adott egy PIC18F6622, 4MHz-es belső órajellel. Ennek csak az AN0 csatornáján csinálok ADC-t. A lényeg, hogy 512 ADC értékem legyen a lehető leggyorsabban, de a gyorsaság nem mehet a pontosság rovására.
Próbaképpen azt csináltam, hogy az AN0 csatornát Vdd-re kötöttem, mértem 512-szer, majd az értékeket kimentettem eepromba, hogy utólag meg tudjam nézni. Viszont az első kb. 150 érték biztosan nem jó, az utána következő értékek már viszont jók. Azt nem tudom, hogy mivel folyamatosan ugyanazt az értéket mérem, hogy ezzel esetleg nem-e csapom be magam.

Az adatlap a 28-27-es táblázatra hivatkozik, ami a mellékleben látható. Tegyük fel, neked az 1µs jó érték, ez 1 MHz-nek felel meg, amihez az Fosc frekvenciát néggyel kell osztani. Mivel csak egy analóg csatornát használsz, az ACQT értéke lehet nulla.


Így működnie kellene rendesen. Az első mérés előtt meg kell várni, amíg stabilizálódik a tápfeszültség, ez jó esetben 10 - 20 ms, de ha bekapcsoláskor nem kapásból méréssel kezdesz, baj nem lehet. Ha ennek ellenére az első 150 mérés (ami rengeteg) hibás, akkor vagy kondenzátor van a PIC AN0 lába és a GND között (10 - 100 nF) ami gerjedést okozhat vagy a feszültségforrás ellenállása nagy (több, mint 8 - 10 kΩ) és nem tud a PIC belső mérőkondenzátora feltöltődni.

Köszi a segítséget! Az ADC-t én is hasonlóan állítottam be, annyi, hogy a 4Tad-t adtam az ADCON2-be. Megnéztem szimulátorban, 14ms alatt végez az 512 méréssel is, úgyhogy beraktam egy kis késleltetést az elejére.
De más probléma is van:
Az adatlapból vettem egy részt amivel végigírja az eeprom tartalmát. Az írás végére beraktam egy utasítást, amivel felkapcsolok egy LED-et. A LED nem akart felkapcsolódni. Elkezdtem lefuttatni a kódot megint szimulátorban és akkor láttam, hogy amikor megírja az utolsó eeprom területet is, nem ugrik át ahogy annak kéne, hanem kezdni előről az írást.

Túl rövid ez a részlet... az eeprom_iras hol van?
EEADR honnan indul? ugye a második incfsz az 65535-nél csordulna tovább, az eeprom meg csak
Data EEPROM (bytes):1024
Arról nem is beszélve hogy EEADRH bitjei: ---- --00
Mondjuk lehet hogy működik, hirtelen nem látom az adatlapban hogy a nemlétező bitek helyén mit olvas vissza, jobb az ilyet nem kihasználni, nem feltételezni a 0-t

A hiba szempontjából a kód többi része teljesen irreleváns. Az EEADRH csak az alsó 2 bitjét használja. A szimulátorban az látható is, hogy b'00000011' után nullázódik, de az ugrás nem hajtódik végre.
Ezt nem én feltételezem, az adatlapból származik a kódrészlet.