Miért nem olvasod le a programozási specifikációját???
A 16C5x programozási specifikációja szerint az utasítás kódokat 12 vezetéken párhuzamosan kell beadni ill kiolvasni. Ezenkívül a Vpp vezérlőjelen 100mA áramot kell biztosítani.

Kössz, akkor nem kukkantok bele.
Méghogy 12 eres kommunikáció.

Nem 12 eres a kommunikáció, hanem csak az adatvonalak száma 12....
Persze mindent meg lehet csinálni...

Egy rossz adatlap miatt, ami 28KB-t írt. Valóban ez csak 16 KB-s. Wundebár. Öröm bódottá

16C54-58 ig meg se mukkant nekem szokványos rákapcsolódással.
Te most fejlesztettél 1 családot és a C sekből 1 partot ?
Ha gondolod érdemes lenne kipróbálnom a tieddel
felhozom a pinyóból és újra nekiesek,
esetleg a panelről is leveszem hátha az bezavar.
Volt már, hogy a PGC és PGDnek való pin és még 2 láb egybe volt kötve.

Sajnos az én pickit2 firmware 2.50.22 és a PICkit 2.63.12 kezelő program verzión nem lesz a pincédben.
16C5x titok két apró panelben van. Az egyiket maga a Microchip ajánlotta az ICD2 -höz a kezdeteknél. TB017
A másik, a PICkit2 vonalait alakítja át 14 bites párhuzamos felületté. MCP23017.

42 családnál és 1464 típusnál járok.

Megoldás: Programtárméret * (bit / memóriahely) / (byte -ban levő bitek száma):
16384 * 14 / 8 = 28672.

jó chip a pincébe alszik.
42 család 1464 part nem semmi. Gratulációm
Én itt 700 alatt látom ami ez felett van azt tudtad ellenőrizni is ?
Csak nem szereztél be ennyi különböző chipet.
Átküldeném a progomat megnéznéd nem akad e ki annyitól
illetve nem indul e lassan.

A PICkit2 verzióm az eszközleíró tekintetében nem kompatibilis a 2.61 verzióval.

A te PICkit 2.63.12 PC softod
a datból másképp dolgozik mint a 2.60 és 2.61.
Namost, ha piacra dobod a majd 1500 típusos dat fájlt
e régebbi verziókkal valami nem olyan lesz mint a tieddel.
Vagy hogy kell érteni ?

Közben nézegettem az MPLAB IDE v8.92 nél a pk2 állományait.
Nos ott is van egy dat fájl családok nélküli a típusok tömbjében
kevesebb adat van, mintha csak a scriptre hivatkozások vannak,
configmask/Blank uint16 itt nincs is.
Viszont, ami a legfeltűnőbb a script tömb. Itt az uint16 értékek alsó bytejai vannak,
azaz nincsenek AA BB 00 hexák. Az uint16 felső 8 bitje mi célra is szolgál ? (nem 00-FF ig vannak)
És ha már itt tartunk a mi dat fájlunkból lehetne e generálni
ide vontakozó állomány(oka)t. Esetleg itt hex eket is kellene csinálni vajon,hogy
a készletünk az MPlab-ból is jól működjön ?

Épp meghírdettem eladásra az egyik PIC prg.ozómat és szembesültem, hogy a jelenlegi
fájlanyagaim szerint a 16C711 et a pk2 és 3 nem is tudja, így meg kell tartanom a 16C sek miatt.
Apropo. ha csak nem az 1464esed már tartalmazza.

A PICkit 2.63.12 módosított program, ami módosított dat állományt használ.
Az MpLab 8 -nál nem alkalmazható az állomány módosítása újabb típusokra való kiferjesztésre.

A dat szerkezetében van némi változás ?
Tudnál mutatni példát a 2.63 asnak szánt anyagból
mondjuk valami régebbi is jó csak megnézés céljából ?
Kössz
Egyébként, a 2.63.12 az tovább adhatós ?
google 1 deka használható találatot se látok.

Nosza aki nagyon ráér és élményt szeretne megélni
nem kell mást tenni mint elejétől átfutni átolvasgatni
a topicot. Eddig, akivel beszélgettem ilyesmiről azt véste a fejembe,
hogy jó szakember ilyen téren vagy hardver vagy szoftver szemléletű
és olyan aki mindkettőben teljes mélységben toppon van az szinte kizárt.
Eddig így voltam ezzel, de ahogy ezt a fejlesztést újra olvasgatom
azt kell látnom, hogy te hardveresen és szoftveresen is komoly tudással rendelkezel,
tehát akkor mégse úgyvan, ahogy a fejembe vésték ezt.
Persze feltenném a kérdést milyen sulijaid voltak és ezek mennyire passzoltak össze
ezzel és mennyi volt ezekből a saját tapasztalatokból szerzett tudás ?
A PC soft feltuningolásához rendelkezésedre állt forrásanyag ? or disassembler technic

2014.decemberében és januárban is eszméletlenül felpörgött az élet itt az izgalom hatása megvolt és ilyet tényleg jó olvasni.
Lehet egyszer a code protect re is valami bekattan.

Nem tudom miért, de állandóan kérdések merülnek fel bennem.
A módosított dat dolgot meglehetett volna oldani esetleg oly módon is,
hogy a programod felhasználja a megszokott dat fájl rendszert,
viszont egy luxus kategóriás végtelenségig fejleszthető (nevezzem most .dat2 )
adat állományt azokra a típusokra használhatnád, melyeket nem lehetne megoldani
a natur dat fájllal ?
Vagy eleve 2 külön exe a megszokott dat állományos és a luxusdatos miatt.
Ha a dat fájlt tartalomszerkezetileg módosítottad véleményem szerint
a nevét is kellene kicsit módosítani.

És még 1.
Írtad, hogy ha többen nekiesnének és használnák már a legfejletteb PK2 det
az özönlött hibajelentést nem tudnád lekezelni.
Milyen hibákra tarthatnál esélyt? eszközmunkák közbeni/valami elfüstölhetne
Mármint, hogy a tesztelésnél keletkezhetne kár is ?
Nem tudom miért, de én bíznék, hogy amit leteszteltél az működik is.
Akik programoznak tudják is tényleg van olyan, hogy akkor, amikor valamit
anno megcsinált tényleg működött is, de a továbbfejlesztés
a bővítés esetenként előidézhet olyat, hogy amit valamiért fejlesztett
az ott jó is, de még vissza kell menni korábbi fejlesztési területre ott is
szükségleltetik beavatkozás. És ettől ne dilizzen be az a valami. Ez a nem semmi.

ha a két MPlabot nézem a v8.92 es nekem barátibb útmutatóbb és a X IPE
bugyutább olyan lassú futású nyelven íródottnak tűnik nem repül.

Végső kérdés:
hardvered szoftvered tekintsem terméknek piacra kerülésében
mit tudnál, mint infót mondani. Most pénz nem pénz mindegy, akinek ez kell mit mondanál
mikor ?

Sajnos ennél összetettebb a helyzet:
A 18F2550 program memóriájából csak 24k használható a PICkit2 firmware -je számára, mert 8k -t elvisz a bootloader. Már rég eljutottam arra a pontra, hogy betelt ez a tartomány. Sajnos rengeteg típus kezeléséhez további funkciókat kellett (kell) beletennem. Az új funkciókhoz a helyet csak azzal tudom előteremteni, ha a már meglevő rutinokat optimalizálom, átírom. Most ott tartok, hogy a script engine -t kellett átírnom, hogy helyet csináljak. Ez viszont egyáltalán nem biztosítja azt, hogy ami eddig kész volt és jól működött, az továbbra is jól fog működni. Javában tart az újboli tesztelés.
Sajnos az év végi időszak nagyon sűrű, talán az év elején több időm lesz.

Viszont ha te döntheted el, hogy
ebben fejlesztett dobozban milyen mcu dolgozzon,
például egy Xprog programozóban leledzik ATMEGA64A
nem nevezhető drágának és vezérelhető pinek tengere van.
Nyílván az más programnyelv de lehet fejlesztésre nem görbítene
akadályt egy ideig. Vagy ha már 18F2550
maradjunk ennél mondjuk, ha lenne benne ebből több darab is.
1 a szervezés előkészítések mit ad tovább és melyik másik
mcut fogja megdolgoztatni akár szimultánban szervezetten
futhatna 3 18F2550 a bonyolultabb vagy helyigényes dolgok miatt.
de akkor nemdebár még beletehetnél még mást is. (lásd 16C5x 7x)
Ezt persze könnyen mondom, de ez munkában iszonyatos meló.
Feláldozás erről nekem is eszembe jut anno bizonyos eszközt
tunigoltam és a többnyelvűséget áldoztam fel hogy legyen jókora
hely arra, hogy az eszközt lehessen bővíteni tudásban. De a többnyelvűség
úgy maradt meg, hogy a fejlesztett szoft fájlt bármilyen nyelvre tudtam generálni,
de a menüben való nyelv átállításnak löttek így. Viszont a pácientura örült, hogy
okosabb és adatgazdagabb lett. Attól, hogy valaminek leállítják a szoftfejlesztését
még esetleg továbbvihető. Ezt gépi kódban kellett megoldanom nemhogy assembler
meg C+ meg forrásanyagok 2mega bin és jónapot kívánok. Ilyenből nem tudnék elképzelni
2 -3 at sem, mert leketyeg az ember élete a feltérképezésekben, meg mire eredményt ér el.
Még 1 hardver ötlet:
Előre mondom luxusról való lemondással jár.
A printer portos csatlakozással építeni hardvert
és a 0/1 jelfeszültségeket kimenetenként potival kellene doku szerint beállítani
ahhoz az eszközhöz, melyet csatlakoztatni szeretnénk.
Itt kimenet lenne 8 és bemenet 5 melyből 1 fordított értékkel jön.
Maga a PC prog csinálna meg mindent a jelvezérlés terén.
Nekem a laptop 2.4Mhz és magas priorításban
1secundum ot 1000000 bontásban mér az egyik progom
ekkor jelmozgásokat figyel másra nincs idő.
Macerás PIC típust szerinted így könnyedén meg lehetne oldani ?
Mondjuk én párosítottam FTDI USBtoRS232x2 vel is, ha
stabil tempós kommunikáció kell. Ha adott eszköz az általam
adott órajellel működik akkor az LPT portot vezérlem, ha
más akkor soros.




tegyük fel más módon PIC

Bocs, nem olvastam végig a teljes topikot nem tudom, hogy épül fel a pickit2 szoftveresen de mi lenne ha lecserélnéd a bootloadert?
Emlékeim szerint egy kiherélt usb-hides bootloader belefér 2k szóba (4k flash). Ezt meg tudod tenni úgy, hogy az applikáció szoftvernek egy másik bootloadert töltesz le, majd azzal frissíted az eredetit. A letöltött applikáció része az új bootloader, azt átmásolja a flash megfelelő részére, majd minden alkalommal beleugrik. Ezzel nyernél egy kevés helyet. (belépési vektorokat persze meg kell tartani)

Illetve, ha a bootloaderben lévő usb stack-et el lehetne érni az applikációból (kiajánlani), akkor az applikációba nem kellene, hogy benne legyen megint. Persze ekkor le kell fixálni jó pár változó/függvény helyét vagy mutatókat használni.
Ez nem biztos, hogy működik erős optimalizáció mellett mert a fordító nem minden argumentumot a stack-en ad át, de biztos van valami pragma direktíva amivel meg lehet kötni a hívási konvenciót. Vagy esetleg az applikáció hivatkozhatna a bootloaderre mint előfordított komponensre.

Véleményem szerint abból a 8k ból így 6-7k-t fel lehetne "szabadítani", és talán gyorsabban megvan mint újraírni/tesztelni kész és működő részeket.

Csak két idézet:
Firmware:

Kezelő program:

AtMega, AtXMega kizárva.

Egy eredeti bootloaderrel programozott kontroller nem fogja tudni frissíteni a programot. A kódvédelem az első 8k -ra van bekapcsolva a "gyári" PICkit2 -ben.

Namost akkor megint felvetődik 1 kérdés.
E topicból egyértelmúen az jön le, hogy az általad végzett tuningolások
soft+hard szerint a gyári PK2 hardver a te szoftoddal kevesebb típust kezelne.
Ragaszkodsz a 18F2550-hez, de kevés a hely.
Amit a script motornál spórolni tudsz azt a keveset milyen hamar fogod kinőni.
Ha gyárival nem mondható az összes típusra kompatibilisnek,
akkor te nem oldhatsz meg másként dolgokat ebben a harverben, hogy ne legyenek problémák.
A csapatod nem tudom mit szólna ehhez ők is ragaszkodnának,
hogy centizve legyen a memória a plafonhoz ?
Olvastam Braf tag mély szakértelemmel írt javaslatát,
de ha azzal is időt töltenél el pár hónap pár év és a nyert hely újra telítődik,
akkor nem jobb, ha mielőbb egy hosszabb távú hardver lenne a megoldás.
mcu kból van a piacon, ha Atmega nem jó(Xprog PIC12C509A t tudja)
még lehet böngészni Motorola/Freescale;ST;Texas;Infineon ....... stb
Ötletek percenként jönnek:
hardver ... 2 áramköri egységes panel 2 USB vel 1 PC proghoz
1.USB a gyári PICkit2 megegyező áramköri egység
2.USB tuningolt változat melyben a helyet nem tudod megtelíteni
a programod a típus kiválasztásakor jelezné a csatlakozási helyet.
vagy 1 USB vel, de át lehetne kapcsolni az áramkört.
Most haladunk az év vége felé, ha teheted gondolkodj a jó megoldáson
és hozz egy jó döntést.

Ötleteteket megfontolom.....
A továbbfejlesztés célja a lehető legtöbb Microchip termék programozása volt. Más gyártóét a licensz feltétel kizárja. Nem szerettem volta PICkit3 -at csinálni, ami majdnem minden típusváltáskor újraprogramozza magát. Ilyet már csinált a Microchip...
Természetesen bármilyen kontrollerrel lehetne univerzális programozót csinálni, de ez a topik méghicsak a PICkit2 továbbfejlesztéséről szól.
Az ötletek megvalósításához sok sikert kívánok. Várom a fejleményeket.

Egy szempontot még a figyelmedbe ajánlanék. A programozható típusokat architektúra alapján csoportosítva lehetne egy 8-16 és egy 16-32 bites változatot kialakítani.

Meg kell állapítanom, hogy tényleg nem olvastátok a PICkit2 forrását...
A PICkit2 programjában nincs semilyen típusspecifikus adat, eljárás tárolva. Egy "virtuális gépet" hoztak létre, amit a un. scriptek segítségével lehet működtetni. Egy típus programozása előtt a szükséges scripteket a programozó / fejlesztő IDE letölni a PICkit2 RAM -jába. Ezeket végrahajtva olvassa ki az eszközazonosítót, a programtár stb. tartalmát és írja be a programot, adatot, felhasználói azonosítókat, stb. A scriptek utasításai és a típusok - scriptek összerendelése a Pk2DeviceFile.dat állományban van leírva.
Így nem sok érteme lenne a különböző változatok létrehozásának.

Gondolom a config is le van védve akkor. Ez így sajnos akkor bukó, kiéve ha nincs a delikvensnek egy másik programozó eszköze is.
USB stack kiajánlása még működhet.

Az írásvédelem csak teljes törléssel oldható fel. Ahhoz, hogy a külső programozót csatlakoztasd, ki kell nyitni a PICkit2 házát. Inkább görcsölök még a program rövidítésén.

A héten sikerült vennem 16F18855 -öt.

Olvasgatom a dsPIC33EP64GS502 és a dsPIC33EP16GS202 programozási leírását és találtam benne néhány gyöngyszemet:
(A pontok a dsPIC33EP64GS502 leírásából vannak.)
1. A 3.9 szerint az OTP tartomány ugyan úgy írható, mint a felhasználói program memória. A 3.7 szerint a program memóriába 24 bites utasítások írhatók. A 3.12 szerint az OTP terület ugyan úgy olvasható, mint a felhasználói program memória - azaz 24 bites értékeket lehet kiolvasni. A Table 3-10 programja csak az alsó 16 bitet olvassa ki. Miért?
2. A 2.5 memória térképében a Table 2-3 szerint a konfigurációs regiszterek címei 4 -gyel oszthatók. A 3.8 leírása szerint csak dupla szavas írással lehet programozni őket. A Table 3-7 eljárása A W0 .. W3 regiszterekbe betölti a két konfigurációs regiszter 24 -24 bitjét és egy dupla szavas írással beírja őket. Ekkor a második konfigurációs regiszter tartalma 4 -gyel osztva 2 maradékot adó címre kerül. Miért?
3. A Table 6-1 szerint a Programming Executive READC parancs a konfigurációs regiszterek alsó 8 bitjét olvassa ki. Miért?
4. Miért nem szerepel a Programming Executive parancsai között az inaktív partíció törlése?

Sziasztok. Pickit2-nél nem lehet a "configuration" beállítást valahogy elmenteni? Sorozatban új fájl beolvasással programozok, de a config mindnél ugyanaz, és minden fájlbeolvasás után újra kell pötyögni.
Köszönöm.

Már elég régóta az az ajánlás, hogy a hex állományban benne kell lennie a konfigurációs regiszter beállításának is.
Megoldás:
Ha sorozatban ugyan azt a hex állományt programozod be sok példányban: Olvasd be a hex állományt, állítsd be a konfigurációs regiszetreket és mentsd ki (File / Export) egy másik hex állományba. A további példányoknál már a kimentett hex állományt olvasd be, benne lesznek a konfigurációs beállítások is.
Ha csak a konfigurációs beállítás azonos: Válaszd ki a típust vagy ismertesd fel. Állítsd be a konfigurációs regiszetreket és mentsd ki (File / Export). Szövegszerkesztővel töröld a hex állományból a program, adat EEPRom, user ID tartalmat. A megmaradt sorokkal cseréld le az eredeti hex állományok utolsó sorát.

A módosított verzióban össze lehet fűzni hex állományokat. Pl. program hex betöltése után lehetőség van egy másik a konfigurációs regiszetrek beállítását tartalmazó hex betöltésére.

Köszönöm mégegyszer. Ma Te vagy a mentőangyalom.

Hali!
A programozó fülét is meg kell huzigálni hogy a configot tegye bele a forrásba, a fordító progi meg beleteszi a hexába. Akkor tuti jó a konfig úgy ahogy a programmoló elképzelte, és nem kell vele a gyártásban mókolni, nem felejtődik el a code protect stb.
Gyors megoldásnak meg mint Hp41C javasolt.