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.

Szia,
Megnéztem az adatlapban ezt a kódrészletet.
Bár nem próbáltam, de érdekes hogy nem működik. Lehet a szimulátor rosszul kezeli ezeket a regisztereket.
Illetve, nem hinném hogy ez a gond, de fontos megjegyzés, hogy a BRA utasítással nem éred el a teljes programmemóriát. A teljes programmemória ~65kB, de BRA-val csak 1kB "távolságra" tudsz ugrani, ugyanis a BRA mögé írt címből (ami egy label, de abból számolja ki a címet a fordító) csak az alsó 11 bit fér bele az utasításba (amiből még lejön az előjelbit).
Bár ha nagyobbat írsz lehet kiabál a fordító.
Mindenesetre én kerülném az összes ilyen utasítás használatát: BC, BN, BNC, BNN, BNOV, BNZ, BZ (ezekkel ráadásul jóval kisebb "távolságra" lehet ugrani, csak 127 byte!) és a BRA-t.
Hát vagy nagyon-nagyon körültekintően kell használni: ha biztosan tudja az ember, hogy a label, amire ugrik, tutira nincs 127 (illetve 1023) byte-nál nagyobb távolságra (és nem is lesz!).
Illetve BRA-hoz hasonló megkötése van még az RCALL-nak is, na azzal futottam bele ilyen hibába. Ezt is kerülöm.

A BRA működik, mert visszalép oda ahová kell. Ami nem működik az az INFSZ, mert amikor nullázódik az EEARDH regiszter, akkorsem ugorja át a BRA-t.

Szia !
Találtam egy fórum bejegyzést (#12), ahol ugyanebbe a problémába ütköztek.
Itt az írják , hogy a szimulátor a hibás , elméletileg ez a pic-ben jól hajtódik végre ( nem próbáltam )
Itt ajánlják a plusz egy "nullás értéket" tesztelő sort :
incf EEADRH
tstfsz EEADRH

Szia!
Köszönöm, ez működik!
Egyébként nem szimulátor hiba, mert az INCFSZ EEARDH utáni utasítások nem hajtódnak végre, tehát itt "elakadt" a program a valóságban is. De ezzel a kiegészítéssel tökéletesen működik.

Idézet a PIC16F887 adatlapjából (DS41291D-page 26):


Idézet a PIC18F6622 adatlapjából (DS39646B-page 77)

A kihasználatlan bitek a SFR regiszterekben a 18F2266 -nál nem garantáltan 0 értékűek.
Egy kis változás a dokumetáció írójának, hagy gond a programozónak.

Innetől az egyik verzión fog működni, de egy másikon már nem biztosan.

Csak az nem világos, hogy az INCFSZ-nél mi váltja ki az ugrást amikor eléri a nullát? Mert ha a regiszer teljes értéke nem nulla, akkor a TSTFSZ sem működne. Vagy rosszul gondolom?

Normál regiszternél FF-ből (túlcsordul) és 00-ba vált ,
de az EEADRH regiszternél lehet hogy 03-ból 04 lesz (lenne),
de valami törli a nem használt biteket ,
és lehet emiatt nem teljesül a incfsz utasítás.
De így kiderült , hogy néhány PIC leírásban hibás a program példa.

Az adatlap is lehet hibás, nem szentírás csak a fele Mondom én, hogy ilyen kérdéses állapotot nem szabad kihasználni, normálisan meg kell írni a programot, különben meg kijön egy új revision chip, és lehet csodálkozni mi változott, mitől más a progi futása.

Nem kérdéses az állapot. A regiszter értéke nulla a túlcsordulás után, ugyanúgy mintha 8 bites lenne, hiszen akkor a TSTFSZ sem működne ha bármelyik bit is nem nulla a regiszterben.

Akkor használd ki. Fél év mulva próbálsz módosítani a progin, aztán csodálkozol hogy pl mint írod a szimulátorban nem megy, de akkor már ki emlékszik rá... Igy pl máris kizárod magad a szimulátor használatából... Vagy ugye telerakod a programot feltételes fordítással attól függően hogy szimulátorra, vagy procira fordítasz. Te tudod...

Az "unknown" bármit jelenthet: egyes utasítások végrehajtásakor vagy más egyéb körülménytől függően más értéket adhat.
Pl a jó öreg Z80 input / output indirekt címzésű utasításai csak a 8 bites C regisztert említik, de a processzor a címbusra a BC regiszterpár értékét teszi ki. Milyen jó lehet, ha a INI vagy IND vagy azok INIR, INDR változatánál mivelezek az utasítások módosítják a B tartalmát.

Ezt értem. Ami nem világos, hogy az ugrás kiváltása szempontjából mi a különbség a INCFSZ és TSTFSZ között? A jelenlegi példában az egyik működik, a másik meg nem, pedig mindkettő akkor ugrik ha a regiszter értéke nulla, tehát nem akármennyi, mert akkor egyik utasítás sem működne. Ez miért lehet?