hát, igen. Mondd csak, ezek - ugye - pillanatnyi feszültségtüskék?

Hello!

Hátha valki már megoldotta ezt a problémát:

Egy lift vezérlésén bütykölök. Opto kapuk adják a jeleket (+3,2 V) a lift mozgása közben, amik egy 25 eres nyomtató kábelbe ágyazva jön a PIC megfelelő lábára.
A kábel árnyékolt, mégis valahogy összeszed olyasmit, ami ugyan nem mérhető, de a PIC elindul (próba villogásnál tartok).
Pl. a pincében, kb. 1,5 m-re lévő hűtőszekrény kikapcsolására is elindul a PIC.

Hogy lehetne ezt a zavaró valamit kigyilkolni.

A PIC a fázisátalakító közelében va ugyan de a kérdéses láb, ahová a jel jön, 10K-val a földre van kötve.


Üdv
Ray

PIC-es (16LF628) fejlesztésre keresünk hozzáértőt.
Az áramkör készen van.

Azért, mert így lehet tesztelni egy regiszter tartalmát nullára. MOVF REG, F nem változtat semminek a tartalmán, viszont a Z bitet állítja.

Miért? Azért, mert lusta voltál elolvasni előre, hogy mikor mi történik, és feltételezésekre építve írtad meg a programot? Ezesetben így jártál...

Ha memória címről másolok a W-be, akkor miért változtatja meg a Z bitet???
Amikor tervezték a PIC-t, ugyan minek tettek bele ilyen fícsört? Ez nem segítség, hanem hátráltatás. Adatmozgatáskor nem volna szabad a status biteket bántani. Most nézhetem át az egész kódot újra.

Kivonás utasításnál az adatlapban dokumentálva van, hogy milyen status bitekre van kihatással a művelet, és hogy mikor mi történik.

Hát én megőrülök. Ha a picnél két egyforma számot kivonok egymásból (FF) akkor a C, a DC és a Z is 1 lesz. Ez meg hogyan? Az utolsó kettő az oké, de miért lenne átvitel????
Valaki valamit nagyon elrontott.

szerk: ha 1-ből vonok ki 2-őt akkor meg a három status bit nulla.
Mi ez már? Az MPlab szimulátorja rossz, vagy a PIC kivonás műveletét rontották el?

szerk2: Na rájöttem végre. Kivonásnál a Carry pont fordítva működik, mint összeadásnál. Remek.

Sziasztok
Leszedtem a microchip honlapjáról a legujabb MPLAB-ot és elakadtam vele mert nem tudom egyszerre használni a MPLAB simulátort és a PICkit2 -t a korábbi verzióban lehetett(8.1) de az uj verben nem tudom.Az uj verben tudom PK2 tápját szabályozni(azt már régóta várom) és erra nekem nagy szükségem van.Valakinek van valami 5lete hogyan tudnám ezt megvalósitani.

Milyen revíciójúak a chipek?

Másik IC-vel is ki lett próbálva. (az előző IC-t két hónappal ezelőtt kicseréltem egy újra, de a hiba most megint előjött...)

Mármint úgy érted, hogy több uC-vel is próbáltad, vagy ugyanazzal az eggyel??? Olyan már volt nekem is, hogy egy megbolondult. Ment a kukába.

Találkoztatok már olyannal, hogy bekapcsolt írásvédelemmel rendelkező PIC-ben megsérült a program? Visszaolvasva mindig máshol keletkeznek hibák, teljesen rendszertelen időközönként... Egyelőre teljesen tanácstalanok vagyunk. BOR, POR, WDT be van kapcsolva.

Van valami ötletetek?

Köszönöm!

Vagy min. 200 ohm - ot sorosan minden (SDIN, SCLK, D/C, SCE) vezetéken. (Adatlap alapján)

atta

Sajnos nem lehet.


Itt a vezérlő IC-jének az adatlapja.

Nem tudod a kontrollert is 3,3V-ról járatni? Az lenne a legegyszerűbb. Ha már néhány percig kibirta, akkor jó eséllyel tartósan is birja. Nincs róla adatlap?

A Nokia 3310 LCD kijelzője 3.3V-ról megy, a mikrokontrollerem 5V-ról.
Egy angol oldalon azt olvastam, hogy az LCD logikai bemeneteinél kibírja az 5V-ot.
Tartósan is bírja? Vagy használjak inkább feszültség osztót?

Köszönöm szépen!

http://picprojects.org.uk/projects/picprojects.htm

Sziasztok PIC guruk!
Megjött a ChipCad-től a MICROCHIP PICkit 2 Debug Express készletem. Mivel kezdő vagyok az lenne a kérésem, hogy valaki ajándékozzon meg egy működő kütyüvel egy linkben. Előre is mély tisztelettel megköszönöm a segítségeteket!

Most nézem, hogy egy link nem működik.
Helyesen: http://elm-chan.org/works/lux/report.html

Arra gondoltam, mi lenne, ha az LM335-tel sorban alapból lenne egy 10-20 Ohmos ellenállás is. Ehez kalibrálnám. Így az esetleges kábelhosszból adódó különbségek csak 1% alatti pontatlanságot okozhatnának.

Más:
A hőmérsékleten kívül, napfényerősséget is kell mérnem.
Ezt egy BPW21-es típusú fotodiódával fogom, utána műv. erősítő és szintén a PIC A/D-je.
Itt van egy hasonló, igaz más típussal és más mikrokontrollerrel:
http://www.pir.org/
http://elm-chan.org/works/lux/lux.png

Vagy itt mégegy megoldás: http://www.chirio.com/lux_meter.htm

A BPW21 9uA/klux -ot produkál. Max fényerőnél 100 klux mellett 900uA folyik a diódán.
A probléma megint csak az esetleges 30m-es kábelhossz. 9uA ingadozás, nálam 1klux eltérést fog eredményezni a kijelzőn. Egy árnykolt kábel elég lehet a problémára? Vagy esetleg 3 vezetéket használva kitenném mellé a műv erősítőt, és akkor már 0-5V os jel szaladgálna?

Nem tud valaki véletlenül egy helyet ahol tudok 16F887-et szerezni? Egyelőre legalább 1db kell (jobb lenne 2), mert a chipcad kifogyott, és csak március 3. utánra igértek.

Köszi a választ!
Én is úgy gondolom, hogy elég lesz az analóg megoldás.
Az adatlapban ez : http://www.zotyaxxx.tvn.hu/LM335/LM335_LM334.JPG van mint áramgenerátoros meghajtás, szerintem ennél egyszerűbbet és jobbat hiába is próbálnék összerakni.
Vélemény?
A másik, hogy a kábel hossz az nem rajtam fog múlni, és nincs lehetőség utólagos korrekcióra. Max belövöm 15m-es kábellal, ha attól valamit eltér az talán annyit nem számít.

Nem javasolnám a 1-wire-t ilyen távolságra. Esetleg I2C lehetne, azt le lehet lassítani, de az analóggal sincs semmi gond, ha megszűrik. Az LM335Z adatlap szerint ha nagy távoságban akarsz mérni, akkor áramgenerátorral kell meghajtani ellenállás helyett, és akkor az oda-vissza ágakon egy fix feszültségesés lesz, amivel lehet kompenzálni a mérés eredményét. A feszültségesést meg egyszerű lemérni, a szenzornál rövidre kell zárni a kábelt, és megnézni a túlsó végénél, hogy mekkora a maradékfeszültség. A PIC felőli oldalon egy RC szűrővel kell fogadni a jelet, ami kiszűri a zaj nagy részét, majd egy műveleti erősítő neminvertáló bekötésben a megfelelő erősítéssel, és mehet a pic lábára. Esetleg a PIC elég mehet még egy RC szűrő. Csavart érpárt célszerű használni. Persze ha rendelkezésre áll táp a szenzor felőli végénél, akkor lehet oda is tenni egy kis PIC-et, majd RS485-ön keresztül vinni át a másik oldalra, szintén csavart érpáron. De szerintem felesleges, jó lesz az analógban.

Esetleg 1-wire DS18B20?
Potyo fórumán olvashatsz a 1-wire-ről.

Sziasztok!
Most szeretnék hőmérőt (egyebek mellett) építeni 0-100 C között.
Felbontás 1C, nem kell semmi extra pontosság, csak megbízhatóság.
Nézegettem többféle szenzort és a KTY81-220, ill. az LM335Z jöhetne szóba.
Én inkább az utóbbi felé hajlok, mert ez jóval lineárisabb mint a KTY. (azzal is menne, csak sokkal több macera kalibrálni)
Ezt szeretném egy LM258-al a PIC A/D bemenetére kötni. Ez nem is okozhat gondot.
A kérdés az, hogy vajon megbízhatóan működne-e max 30m-es kábelhosszal?
Dolgozott már valaki LM335-tel?
Ha nem, akkor megoldás lehet-e, ha kiteszem mellé a műv erősítőt is, és mondjuk a panelon is egy LM258 fogadná nem közvetlenül a PIC A/D-je?

Igazad lehet, de most sem a basuc izélgetett. Szerintem ezt a hibát simán elvétettem volna másik nyelveben is, ez a tulajdonság inkább hardwer függő. próbálkoztam C-ben is és ASM-ben is, de talán túl kényelmes vagyok, vagy inkább szokás, vagy mit tudom én miért ragadtam le itt.
Rá akartam fogni hogy még semmi komolyat ne csináltam, de ez sem teljesen igaz, de most nem sorolnám. Hát ez van
Igaz már gaynúba fogtam a kompajlert, hogy hibásan fordit, böngésztem az ASMkódot is, de hát mint amint kiderült nem jó helyen keresgéltem.

Köszi a segitséget meg hálám mindenkinek, hogy megmentettek egy depresziótól!

A Basic-et inkább hanyagold a kontrollereknél. Inkább rá se szokj. Asm és C való ezekhez.

Üdv minden kedves fórumozónak és kösz a segitséget!

Potyó király vagy! a mayarázatod alapján elindultam és átnéztem mindent és igen megvan működik. Kikapcsoltan az analóg komparátort és láss csodát, mot már teljesen szótffogad a bsf és bcf utasitásoknak. Mégegyszer nagyon kösz és hálám midnörökre üldözni fog!

Kösz neked is T68m!

Az eredeti ötlet a hobbielektronikán jelent meg. Egy fényjátékrókl van szó, RGB ledek meghajtása PWM-ben és ezel elérthető fényjáték. Igaz az eredeti ötlet szerint egy AVR volt használva és a szofi C ben volt megirva, de éreztem amagamat "anyira felnőtnek" hogy átirjam PIC-re és BASIC-ban. De sikerült bebizonyitani hogy nem igy van és bátran közé is tetem . Na de azt hiszem aki volt kezdő az megérti. Mindenesetre egy jó kis gyakorlási lehetőség volt. Szerencse hogy it ilyen jó fejek vanak és van kedvük magyarázni.

Ha még továbra is igénylitek hogy felrakjam a rajzot és a többit akkor jelezzétek. Ilyet sem csináltam még, de megerőltetem magamt és a gyakorlás nem árt

További jó elfoglaltságot és sok sikert! !!!

Potyo is pontosan megírta mit KÉNE tenned, de ezt konzekvensen nem érted meg! Nem sokat segít, ha a BCF/BSF helyett a kiolvasást te magad végzed el kézzel, ugyanúgy hibás értéket fogsz visszaírni! Nem szabad olvasni, hacsak direkt tudni nem akarod egy láb állapotát.

Köszi neked is! bocsi hogy előbb csak Potyónak köszöntem meg.

Nagyon jó kis chip az a maga helyén.

Gyanús, hogy valamelyik analóg periféria nincs kikapcsolva. Bár ekkor elvileg nulláznia kellene a többi lábat, ha csak egy lábat módosítasz, de azért nézd meg.


Ez csak akkor segítene, ha a láb kapacitívan van túlterhelve, és akkor is csak bizonyos kapacitás alatt, mert ezzel csak azt éred el, hogy nem egymásután következő Q2 és Q4 ciklusban lesz a port olvasva és írva, hanem több idő telik el közöttük. De a probléma, hogy a port olvasva van, továbbra is fennáll. Ezért ha segédváltozót használsz, akkor abba sosem másolod be a port aktuális állapotát, hanem a változóban használod a BCF/BSF utasításokat, majd azután a komplett változót írod ki a portra. De ha a környező áramkör jól van megtervezve és kivitelezve, akkor erre nincs szükség 12F675 esetén.



Mutasd meg a kapcsolási rajzot és a kódot, az alapján el tudunk indulni.

Köszi T68m!

A megoldást Kiolvasás-Müvelet-Visszairás már próbáltam, de nem szült eredményt. Azt hiszem ezt már leiirtam. Bocs az ismétlésért ha igy van. Másik PIC-nél, úgy mint a 16F-es sorozat eddig nem volt ilyen gondom. Nem is volt igazán kedvem ekkorát visszalépni, de hát amikor a havernak kell akkor az ember belekényszeriti magát olyasmibe is amibe nem kellene. A program készen van és a debuggerren azt mutatja hogy minden ok. A véktozókat ugy lépteti ahogyan kell és a müveleteknek megfelelően változnak. Csak amikor "élesben" kezdtem tesztelni akkor ért meglepetés. Sokat böngésztem az adtlapot, de vagy elsiklottam a megoldás felett, vagy nincs is benne.
Azért kösz!

Ati

az is egy szívás picnél (de potyo mindjárt megmagyarázza, hogy ez pont hasznos tulajdonság), hogy

1. csak egyszerre lehet állítani az egy porton lévő összes lábat, a bsf és a bcf is ezt csinálja, valójában byte műveletek, olvasnak egy byte-ot, egy bitet szoftveresen átállítanak, majd visszaírják a byte-ot

2. a beolvasott értékek a láb valódi állapotát mutatják, nem azt, amit te be előzőleg beállítottál rajta. Tehát egy bsf vagy bcf-el simán átállíthatsz olyan lábakat is, amiket nem akarsz.

Megoldás, sosem közvetlenül az IO regiszteren kell a műveletet végezni, hanem egy munkaregiszteren, majd annak az eredményét rámásolni a kívánt IO regiszterre.

Hát ha segítek másnak is.....
Elpukkant az ICD2-m. Némi keresgélés után
DG411DY-t a Hqvideo-ban (Bp. XIII. Kerekes u. 25.),
SSOP tokos 74AHC125-öt és 126-ot pedig a Kontel-nél (IV. Munkásotthon u. 39.) találtam. A 3 tok összesen nincs 500Ft. . . . .

Üdv minden kedves fórumozónak!

Ismét egy buta kérdés de hátha valakinek van hasonló gondja-tapasztalata.
A cimben emlitett MCU val foglalkozom. Tudom hogy nagyon buta meg minden rosz... de a feltételek között szerepel hogy ezzel kell megoldani a kapcsolást. Mármost, minden láb kimenetnek van konfigolva (kivéve az MCLR ami hardverilag nem lehet kimenet ) és a gondok akkor kezdődnek amikor egyesével akarom ki vagy bekapcsolni a lábakat, kimeneteket. Akár melyik lábat viszem magasra mind magasra vállt, vagy akár melyiket kapcsolom ki mind kikapcsol. Probáltam a mottót: kiolvasom a portot, eltárolom egy változóban, elvégzem a möveletet a változón és visszairom a változó értékét a port regiszterben. A végeredmény ugyanaz lett. Gondoltam, nem szereti ha direkt piszkálgatom a port regiszter bitjeit egyenként de a szájbarágós megoldás sem segitett közelebb jutni ahhoz amit el szeretnék érni.
Csináltam már kapcsolást ezzel a cuccal, de akkor simán tudtam követni mikor melyik lábon mi van és simám mindig irtam az egész portot az állapotnak megfelelően. Igy hidaltam át ezen gondot anno, de most más a helyzet mert a lábak lehetnek bármilyen állapotban amikor váltotztatnom kell valamelyik állapotát.
Végöl is egy mondatban abban szeretnék segitséget kérni, hogy miként tudnám egyesével átállitani a kimeneteket.

Előre is kösz és további jó elfoglaltságot és sok sikert!

Atila

Köszi Potyo a gyors válast!

Most teljesen megvilágosodtam Igazad van, a PINB0 elébb nullázva van és igy már teljesen érthető. Le a kalpappal a tapsztalatod előtt. egyszer majd én is megtanulom mindezt csak idő kérdése

További jó olfoglaltságot és szép időtöltést!

Menjünk lépésenként.
A PINB0 valahol definiálva van, hogy nulla az értéke. Az 1-et balra léptetjük nullaszor, tehát a zárójelben levő kifejezés értéke 1. Ezután bitenkénti negálást végzünk, vagyis minden bitet ellentétesre fordítunk, tehát az egyenlőségjel mellett jobbról 254 áll. Ezután kiolvassuk a PORTB-t, bitenként AND kapcsolatba hozzuk a 254-el, majd az eredményt visszaírjuk a PORTB-re. Vagyis tulajdonképpen a B0 lábat nulláztuk vele, a többihez pedig nem nyúltunk. És mindezt csak akkor hajtjuk végre, ha a counter értéke egyenlő nullával.

Ha a counter változó értéke nullával egyenlő, akkor a PORTB-n a PIN0-t alacsony szintre billenti.

Üdv minden kedves fórumozónak!

Néhány napja és jó sok órája próbálkozom megfejeteni egy C-ben irt programot. Úgy látszik nem vagyok elég jártas ebben a nyelvben és bevillant a kiségő ami megvilágositott. Hát itt vannak akik szeretnek problémákat megoldani.

Ezt a sort kellene leforditani, vagyis megmagyarázni:

IF (counter==0) PORTB &= ~ (1<<PINB0);

A feltétel elejét értem csak az nem értem utána hogy mit is csinál, vagyis mit tölt be a PORTB-be. Jó lenne ha ezt elmagyaráznátok. Előre is kösz mindenkinek !
Sok sikert a további problémamegoldásban!

Atila

1. "az oké, hogy égetõprogrammal tudom kiolvasni, de ezt hol tudom megnézni?"

ebből nekem nem az jött le, hogy "Õ nem azt kérdezte, hanem azt, hogy tudja az eeprom területet megnézni."

az eeprom terület egész más. Ha ott lenne az oszkár érték, akkor sem movlw, sem retlw-vel nem lehet olvasni a harvard architektúra miatt. Na, meg egyébként is minek programból olvasni, ha eleve az égetővel ki lehet olvasni???

TEHÁT A KOLLEGA NEM A GYÁRI OSZKÁR, HANEM A PROGRAMJA ÁLTAL GENERÁLT KALIBRÁCIÓS ÉRTÉKRE KIVÁNCSI, LÁSD 2. PONT!!!
(ja, ha valaki nem tudja egzakt módon megfogalmazni óhajt, arról - nyilván - a válaszoló tehet)

2. amire helyeslően bólogattál, az pedig nem a kalibrált érték kiolvasása, hanem az oszkár beállítása a GYÁRI (tehát nem a programja által) kalibrált értékre! Ha neki gyári érték kiolvasásra van szüksége, akkor azt az égető programmal tudja megcsinálni. A belinkelt program pedig a 0-ás eeprom címre teszi a kalibrált értéket, így az közvetlenül NEM használható fel!!! A belinkelt programot át kell írni, hogy a megszerzett érték használható legyen vagy olyan égető kell, ami tudja olvasni az eepromot! Továbbá a kalibráló program által adott értéket át kell alalkítani retlw formára!!!

3. "Ehhez a regiszterhez egyszer kell hozzányúlni - induláskor -, inkább az olyasmi legyen a bank0-ban, amit gyakran kell elérni. "
Ügyes mellémagyarázat volt arra, ha eredetileg az oszkár a bank0-ban van, akkor azt miért kell átpakolni máshova. Nyilván még nem hallottál a kompatibilitás szóról.

4. "Igen, mert így pászol az elõzõ kódhoz, hogy a CALL után visszaadja a vezérlést. Amúgy meg miért lenne jobb a movlw, mint a retlw? "
Kompatiblitás. Ugye, még mindig nem érted ezt a kifejezést?

5. "Helyesbítenék: a baseline sorozatnál mutat az utolsó helyre, a mid-range és nagyobb teljesítményû sorozatoknál pedig a 0 helyre. "
Ja, nyilván ez is a kompatibilitás jegyében van.

6. a példád pedig annyira sántít, hogy nem kifejezés. Mitől kéne egy nagyobb teljesítményű cpu regisztereit átpakolászni? Mitől kéne a reset vektort máshová állítani? Ezekre válaszolj, ha tudsz! A nagyobb teljesítményű processzorok a megnövelt utasításhosszt követelnék meg, hogy a megnövekedett adat és programcímek is beleférjenek, és ne kelljen lapozgatni, stb. Na, ez már bonyolult volt a MC-nek. Helyette inkább a regisztereket pakolászta át, hogy ne fusson az egyik program a másik uC-n. Ezek a tények.

7. az hogy te (vagy más) annak a híve vagy, hogy minden a legnagyobb rendben és ennek érdekében a tényeket is letagadod, a letagadhatatlant, pedig megmagyarázod, na, arról nem tehetek.

Hagyjátok már abba, vicc az egész! Holnap megmentem ezt a drága eszközt és beszámolok az élményeinről.
"Okos legyé' fiam, ne ostoba"

Ő nem azt kérdezte, hanem azt, hogy tudja az eeprom területet megnézni. De egyébként is csak annyiban kitüntetett hely, hogy a gyári kalibrálás után oda beírják az ott kapott kalibrációs értéket. Az égetők meg elvileg tudják, hogy onnan először ki kell olvasni, ami ott van, majd visszaírni. De ezt nem nagyon szokták tudni a nem gyári égetők.

Ami pontosan az, amit csinálni kell.

Ehhez a regiszterhez egyszer kell hozzányúlni - induláskor -, inkább az olyasmi legyen a bank0-ban, amit gyakran kell elérni.
Igen, mert így pászol az előző kódhoz, hogy a CALL után visszaadja a vezérlést. Amúgy meg miért lenne jobb a movlw, mint a retlw?
Helyesbítenék: a baseline sorozatnál mutat az utolsó helyre, a mid-range és nagyobb teljesítményű sorozatoknál pedig a 0 helyre.

Miért gyártja a bmw a kisebb motorokba a dugattyút kisebb átmérőjű csapszeggel, mint a nagyobb motorokba való dugattyúkat, amikor így nem lehet a kettőt összeházasítani? Persze ne vegyük tekintetbe, hogy más a hengerfurat, más a löket, stb. most ragaszkodjuk ehhez az egy adathoz. Nem érzed, hogy egy kicsit túlzásba viszed a cirkuszolást? Amíg nem jelentél meg ebben a témában, addig az egyetlen nagy téma volt a fórumon, amiben nem ment cirkusz. Amióta megjelentél, azóta csak a kötözködésed megy. Emiatt ment el innen watt is, és emiatt megyünk el lassan mindannyian.

most ezzel mit akarsz mondani?

az oszkár helye, a 12f-nél az utolsó flash programhely, nem? $3ff

és - persze - a leírásban is ez van:
bsf STATUS, RP0 ;Bank 1
call 3FFh ;Get the cal value
movwf OSCCAL ;Calibrate
bcf STATUS, RP0 ;Bank 0

ennél a csipnél - a kompatibilitást ismét figyelmen kívül hagyva - nem a

1. az oszkár nem a bank0-ban van
2. az oszkár értéke nem movlw, hanem retlw-vel van felírva
3. na, és persze a reset vektor is ennek megfelelően az egyik csipnél 0, a másiknál pedig az utolsó helyre mutat.
(majd Potyo elvtársi útmutatást ad, hogy miért jó nekünk ez a változatosság. Pl. hogy ugyanaz a program még forrás szinten se legyen jó a két csipre)

Már belenéztem, le is mentettem magamnak (ICD2-vel nemis lehet kalibrálni).

T68m, lehet, hogy mégse akkora hülyeség az oszcillátor kalibrációs regiszterét a RAM-ba tenni

Nem írja külön, az egész memóriát kilistázza 0x0000 tól 0x03FF ig. de így már meg fogom találni, köszi. (érdemes belekukkantani az általam linkelt asm kódba, jókis progi, ha épp nincs kéznél pickit vagy icd...

szerk: bocs, hülyeséget írok, közben észrevettem. külön megvan az eeprom.

0x2100 az EEPROM kezdőcíme a mid range chipeknél, de az égetőprogramok külön szokták az EEPROM területet mutatni, kezelni. Winpic800-at nem ismerem, nézz szét benne, hátha rátalálsz. Ha nem, nézz valami másik égetőprogramot. Nem tudom, melyik lenne jó, én csak a párhuzamos égetőhöz valókat ismerem a Pickit2 és ICD2 mellett.

Sajna most nem olyan helyen vagok, ahol van pickit2, viszont egy JDM et összahákoltam gyorsan próbapanelra, olvassa, írja a pic-et. az oké, hogy égetőprogrammal tudom kiolvasni, de ezt hol tudom megnézni? winpic800at használtam most épp, ebben hol van ez? melyik cím az eeprom első címe?

sőt, 12f-nél kalibrálni is lehet a pickit2-vel. Nem kell hozzá külön progi.