Letöltöttem a pk2devicefile.dat filet itt
és megállapítottam hogy a kikeresési osztályzása
elszállt. gondolom más is észrevette

engedelmetekkel
újra építettem a családszerkezetet
PIC18F65K90 is benne van

pk2devicefile.zip

remélem megfelelő

egyébként érdekel
hogy ha újat kell valamiből dupplikálni a hozzávaló
korrekt adatokat honnan húzzátok le
Kössz

picit más
93Cxx microwire
találkoztam olyan panellal, ahol a DI és DO pinjei össze voltak kötve
viszont az itthon található összes eeprom
olvasó/író nál azt vettem észre,
hogy ha rajta hagyom a panelon
a chipet, akkor az írásnál sikertelen állapotot hoz létre
no erre én magam csináltam LPT portra minimális alkatrészből
hardvert és írtam pár este egy 93Cxx progit
persze egy jó editort terveztem hozzá
bármerre száguldhatunk az aktív kijelöléssel
akár a hexa akár az ascii sorokon
itt kijelölhetem (bepirosítja) <space> vagy beírhatom az értékeket
akár olvashatok gyorsan csak a kijelölteket vagy írhatom
csak ezeket. Lehet komplett törlés FF re, de lehet
bármilyen értékű az egész terület. Ha 16bites módba vagyok ott tetszőleges 16bites a kitöltés is.
Az is lehet, hogy az olvasott terület legyen a kijelölt(piros).
Checksumos munkánál pont jó lesz, mert a fálj korrekciójánál itt elég csak újra a type nál a sorra nyomni és teljesen azonos beállításnál már ott lesz
az írni kívánt anyag. szóval kihoztam belőle, amit gondoltam
szükséges kellék stab +5V táp LPT port
Ezzel ilyen esetben nem kell kiforrasztani
az eepromot írás miatt, mert nem zavarja a DI és DO lábak összekötése.
De a közelmúltban írtam MC908AZ60A ra eeprom és flash RW t
ehhez a flash írását nagyon nem akarta megcsinálni senki a programmerjébe
kifizethető árért tulajdonképp hosszas keresés után 300e Ft ig nem is találtam
se Kínából se máshonnan.
MC908AZ60 ra van olcsó, de az tök más reg címes csak eeprom olvasásig van hasonlóság
------------------------------------------------------------------------------------
Visszatérve kukkoljátok meg a mellékelt pickit2 eszköz fájlt

Most kipróbáltam és nálam nem száll el.
Nagyon nehezen érthető, amit írsz. Fordítót használtál?
Have You translated the post? Try in english.

Arról a fájlról beszélek aminek a hossza 197629byte
mellékelt txt Pickit2Scripts_PIC16F1618.txt

Jó lehet igazad van és nem nagyon számít a FamilyType. Gondoltam hogy ennek meg kellene egyezni a menük számával illetve az összesből való leválasztott csoportok számával. ( gondolom
legalábbis )

pid_1 Midrange/Standard és Midrange/NoDeviceId
pid_2 Midrange/1.8V Min ; Midrange/USB ; Enh.Midrange/1.8V Min
pid_5 a PIC18F_K és K80 nál van

De azért hol beszélhetnénk meg jobban ha nem itt?
Itt a sarkon a kocsmában talán mégse.
Véleményed szerint ezt hogy kell érteni "FamilyType" ?
Device families dupplikálásnál keletkezett listagond.
Kérdeztem, hogy eszköz bővítéskor hol érdemes megtalálni a pontos paramétereket?
Itt gondolva arra, hogy a Pickit 3 devdat ból esetleg nem lehetne-e kivenni gyorsba, ha valakinek kellene a pk2 re?



fordító....
átolvastam
nekem ez full érthető (mondjuk 10 éve semmit nem értettem volna belőle)
idézd a legérthetetlenebb részt

Ebben a hozzászólásomban linkelt PK2DeviceFile_1.62.14_mod6.zip 23475 byte hoszzú, benne a PK2DeviceFile_1.62.14_mod6.dat pedig 193187 byte. Ezzel nincs gondja a PICkit2 V2.62 -nek.
A Pk2DeviceFile Editornek van néhány hibája:
- Elrontja a család és part nevekben a (c) jelet (KEELOQ?? a KEELOQ©),
- Duplikálásnál a tömbös elemeknek (configblank, configmask, script) csak referenciáját másolja. Ha a másoltat módosítod, az eredeti is módosul.
Miért kellett egy családot duplikálni?
A PICkit2SourceGuidePCv2-61FWv2-32.pdf -ból:

Az eszköz bővítésekor a típus programozási leírásában lehet megtalálni az adatokat. Pl PIC16F1618 esetén itt.
Sajnos a PICkit3 eszközleíró állomány nem dokumentált.

figyelek figyelek
pontosítsunk KELLOQ után (c) copyright vagy (R)
igen láttam sztringet behelyettesít és mentéskor nem hozza elő
a loading szerinti re így ez elvész
a dupplikálásnál kellemetlenségek
mondjuk ezt azért észrevehette volna a készítője

A Scriptekről kérdeznék. Ezt is szoktál bővíteni ?
Ha Igen a script dupplikálása is kellemetlenséggel jár ?
Közben rákukkoltam a pk3 dat állományra és e kettőből
tárolt adat szempontból semmilyen hasonlóságot nem véltem felfedezni.
Így a pk3-ból nem lehetne egy gombnyomásra full készletet legyártani a pk2-re.

A script struktúrában a tényleges script adatok egy uint16 tömbben vannak, így rájuk is vonatkozik a Pk2deviceFileEditor hibája. Duplikáláskor csak a tömb referenciájának másolása történik meg. Ha közvetlenül a duplikálás után módosítjuk a másodpéldnyt, az eredeti is változni fog. A duplikálás után ki kell menteni az állományt és ismét beolvasni. Ekkor új hely foglalódik a másolt példánynak.

Értem.
Igen láttam a script valós állománya az uint16 os tömbben van
és hogy a méret korlátozott illetve maga ez az editor szerint le van korlátozva,
de lehetne ez hosszabb is.

Hátha tudod : Tulajdonképpen mi célt szolgál a SearchPriority értéke ?

pk2ed.zip
pk2_3.jpg

Töltsd le a PICkit2 V2.61 forrását. A kérdéseidre a válaszokat a csomagban levő PICkit2SourceGuidePCv2-61FWv2-32.pdf állományban megtalálod meg.
Script méretét az USB HID üzemet mérete korlátozza 63 byte-ban (64 byte-os üzemetben az első byte a script hossza).
SearchPriority: Azt program a legisebb SearchPriority értékkel rendelkező családdal kezdi a kontroller detektálást.

Sajnos elírtam: A DownLoad script parancs a 64 byte -ba beleteszi a parancskódot és a script sorszámást is. Így ez a szűk keresztmetszet. A letölthető script mérete így maximum 61 byte.

Sziasztok!
Arra gondoltam, hogy mivel elég sokan bővítették már a DeviceFile állományt a nekik szükséges típusokkal a Hp41C által közreadott V1.62.14mod6 változat óta, ezért jó volna aktualizálni és nyilvántartani mely fajtákkal bővült már idáig, hogy ha már egyszer valaki beletett egy típust, akkor másnak már ne kelljen ezzel bajlódni, ha neki is éppen erre a típusra van szüksége. A legutolsó naprakész változatot meg a fejlécben elérhetővé lehetne tenni egy listával együtt, ami tartalmazná az összes használható PIC típusát. Ha valaki bővítené egy új fajtával, akkor feltenné ide az oldalra, és akik rendelkeznek az adott típussal, azok letesztelhetnék a működését. Ezután ki lehetne tenni a fejlécbe a bővített és tesztelt állományt.

Igen, de hogy lehetne ezeket begyűjteni? Ilyenre szoktam használni azt a módszert,
amikor egy fájlt megnyitva szervezetten mappa szerkezetbe legyártja a mappákat és fájlokat.
És így több fájlt is meglehetne nyitni és feldúsulhat az adatbázis anélkül, hogy tudnánk
melyikbe ki mit írt be. Majd egy másik programmal legyártani a mappák anyagából a DAT állományt.
Az első része elkészítése nekem max 10 perc. De a begyűjtés sikerülne-e ?
Tulajdonképpen, ha valaki toppon van a pk2 script és egyéb,
akkor önnálóan olyan eszközt is felvehet a listára, ami még a pk3 ban sincs.
Ha már itt tartok láttam vannak olyan eszközök a pk2 ben,
ami a pk3 ban nincs is.

És még 1.
Amikor a MPLAB valamelyik softját használjuk ott hogy döl el hogy egy eszközt kiválasztunk
és hogy a PK2 kizöldül vagy piros marad ? Ha a Pickit2.60 asnél fejlesztett dat unk van
akkor azt az MPLAB nem fogja tudni ugye ?

A PICkit2 V2.61 megengedi, hogy az induláskor megadd az eszközleíró állomány nevét. Csak a PICkit2.ini -be be kell írni: SDAT: Y
A hagyományos és enhanced midrange típusokkal (kivéve a 16(L)F188xx és 18FxxK40) egyszekű a bővítés, a többiekhez már nem elegendő a devicefile módosítása.
Akármennyi típust adunk hozzá a PK2Devicefile.dat -hoz nem jelennek meg az MpLab -ban, mint kezelhető típusok. Programozni lehet őket a PICkit2 alkalmazással, de a nyomkövetés nem lesz lehetséges.

Hát én ehhez gyenge képességű vagyok. Most kezdtem el újra kínlódni a 16f1789-el.
Ha átírom a device id-t nem ismeri fel a programozó. A programtár méretét sikerült módosítanom. A config masknál nem tudom mire írjam át.
Most az van, hogy az írást sikeresnek jelzi. Ha ellenőrzöm 4000h-nál hibát jelez. Ha ezt azt állítgattam a programozón előfordult, hogy a verify is jó volt, de Ha kiolvasom a programtár tartalmát akkor ott is van adat, ahol nem kellene. Maga a progi pl. 3E30H-ig terjed. Ám utána is van mindenféle a memóriában.

Azta. A 4000h-tól kezdve még egyszer beleírja a progit.

Olyan eszközök, melyhez több ér vezérlése is szükséges,
de közben a pk2 támogatja,
hogyan kell rácsatlakozni ?
Kell hozzá még valami közbenső cuccos ?
Gondolok itt mondjuk a microwire 93C szériára
Jelvezérelt CS ; Clock ; Input ; output ; fix feszkósak Vss ; Vcc ; ORG (mondjuk
erről mi magunk is gondoskodhatunk, ha nincs panelen a 93c)

Igen, ötletet találsz a "PICkit 2 Readme.txt" állományban.

Sokáig fennmaradtál.... A 0x4000 - 0x7FFF tarományban a 0x0000 - 0x3FFF tarományt látod.
Ld. adatlap Figure 3-1:

Köszike ! Ez vicces. Na lényeg, hogy így jó lesz. Csak közben a vicces bekötésű 1117-es stabok is tettek rá egy lapáttal.

Lehetséges, hogy beillesztem a pk2 mappájába a PK2DeviceFile.dat 193187
fájlt, majd a pk2-t indítom nyomok ezt meg azt és ez a fájl megváltozik ?
Így 3al több script lesz
1 családdal több (enh.midrange min 1.8V )
és 1 PIC16F1618 hozzáadva az új családhoz.
Ezt beépített önépítő adatbázisból vagy letárolta az ő indítása alkalmával
a legnagyobb számú Numberfamilies/parts/scripts dat fájlt és ezt hozza vissza.
Valakinek 301 darab Scriptnél van több is?

A PICkit2 V2.61 nem tudja írni a Pk2DeviceFile.dat állományt. Az viszont előfordulhat, hogy azzal a beállítással indítod a programot, hogy indulánál ki lehessen választani az eszközleíró állományt. Először egy más nevű állományt választottál ki, másodszor már kiválasztás nélkül (vagy név szerint pontosan a Pk2DeviceFile.dat állomány kiválasztásávan) indítod. Esetleg fordítva.

Nálam még csak 2.60 as van erre is ez vonatkozik?
Én még a pk2 menükben sehol semmit nem változtattam.
Ha nincs dat és indítom gázos, tehát ezzel dolgozik bootoláskor,
dehogy változni tud a dat az tuti.

Ha a program memória 4000h-ig terjed, akkor az a fölötti tartomány minek ? Az ellenség megtévesztésére ? Vagy fizikailag nem is létezik ? Mi van ha egy 6000h terjedelmű programot akarok belegyömöszölni pl. Bocsi a buta kérdésekért, mondtam, hogy Marinéni vagyok a témához.

Ahogy 3CPO mondaná: Kérdezd meg a tervezőmet....

Miért akarnál a maximális programméret másfélszerese hosszúságú programot beleírni???
A programtár méretét kell jól beállítani. Ha a méret jól van beállítva, a program nem jeleníti meg a "felesleget" (ha nem jelent meg, nem is tudod módosítani), nem engedi meg, hogy oda betölts adatot, exportálj onnan adatot, stb.

A cimbitek miatt. Ezek darabszama a csaladon belul fix. Valamekkora tartomany ertelmezheto ezekkel, de mogotte nem all mindig ugyanakkora fizikai memoria. Ilyenkor a felso cimbitek nem funkcionalnak es az also cimbiteknek megfelelo tartomany latszik, hiszen azok stimmelnek.

Ti mire állítva olvasnátok ezt ?
CF745
Kössz

Idézet egy blog -ról:

PICkit2 2.61 -gyel nem megy az olvasása.

A pk3 esetleg mplab is kevés ehhez a tajvani klónhoz ?
Ez az 5x és 7x nem elég konkrét.
Miért ez lehetne PIC16C54-58 is ?

Bármelyik Scriptnél látni lehet hogy melyik family és melyik parts
melyik eleme ad rá hivatkozást. Van amikor teljesen más part scriptelem
ugyanazt a scriptet hívja meg.

előző hsz
Az insert fájlok bemutatják, hogy lehet két PK2DeviceFile.dat-ból
2 mozdulattal tetszőleges partot betenni az egyikből a másikba.
Forrás kijelöl a kép szerint klikk a cél oldalon tetszőleges parton állva a kép szerint klikk és ott lesz. Netto műveleti idő 20mp alatt. Ugyanígy script (a végére) is lehetséges
és family (a végére)