Aha pont ezt olvastam most, akkor úgyérzem gyorsan elfejetem a jdm-et és társait Van amúgy egy p2-es gépem még a régmúltból, azon van valami esély hogy működne? Mert ha nem akkor a géppel együtt dobom ki őket... Végezetül te milyen égetőt ajállanál ami működik manapság?

Rászánhatnál egy kis időt és olvasgathatnál! Ez a topic is jó, és akár az oldalamon is találhatsz infókat.

Sziasztok!
Bátorkodtam egy új topicot nyitni, hogy egy program fejlesztésével ne itt zavarjunk.
Itt olvashatjátok: WPB égetőszoftver fejlesztése/tesztelése
Remélem sikerül életre kelteni a nem működő égetőket is! Előre is köszönöm a segítő tesztelők munkáját!

Sziasztok!

Készítettem egy icd2 klónt soros portra. Ment is rendesen, 16f690 12f629 12f508 uprocokat programoztam vele. Egyszer gondolt egyet, és a 12f508-at nem hajlandó felismerni. A 12f629-et progizza, visszaolvassa, de a 12f508-at nem. A kristály jó benne a tápfeszek megvannak, a PIC16F876A programja olvasható. Mi lehet a gond?

12F508 nem lett véletlenül belső oszcillátorra és MCLR letiltásra konfigurálva előtte?

Már többször programoztam ezt az ic-t és mindig belső oszcillátort használtam és internal mclr jelet, és mindig engedte ujraprogramozni. Az adatlap szerinti ezerszeres ujraprogramozást meg még biztosan nem értem el. Esetleg ez esetben máshogy kell progizni?

Inkább úgy kérdezem,hogy ha ez a config regiszter beállitás a gond, akkor megmenthető az ic, vagy kuka?

szaiasztok!

megépítettem a Egyszerű LPT égetőáramkör 2 (WLPT_Vpp_mini_v4), még elég kezdő vagyok, és egy kis segítség kellne hogy a icsp-re a 18f2550 es pic-t hogyan kell csatlakoztatni?

kell e valami ellenállás, kondi?
esetleg valaki egy rajzot, ha kell...

előre is köszönöm!
Sniper

Néhány dolgot nem szeretünk:
1. Ha nem használja valaki a keresőt.
2. Ha nem olvassa el a cikket rendesen.
3. Ha privátban szakmai kérdést tesz fel.
4. Ha kisbetűvel kezdi a mondatot.
5. Ha várja a sültgalambot, ahelyett, hogy olvasna.
Minden, ismétlem minden információ megvan a fórumon a cikkekben és az adatlapokban... Ha ez kevés, akkor nem jó hobbit választott a kérdező.

Utólag is elnézést kérek!

Valakinek sikerült már nem PICKIT2-vel megírni a 16F690-et? Elárulhatná, melyik rajz, ill. melyik progival. Már 2 PIC-et is próbáltam, de se nem ír, se nem olvas. Fel sem ismeri a PIC-et. Tait hardvert megtalálja, eddig jutottam. Köszönöm.

Milyen égetővel égeted és milyen programmal?
Nézz át ide is: Bővebben: Link

Próbáltam a WLPT Vpp mini v4 PIC programozót, innen a 3. Tait Classicot http://www.members.aon.at/electronics/pic/picpgm/hardware.html#TAIT...RAMMER
Meg ezekkel a progikkal: Winpic800, http://members.aon.at/electronics/pic/picpgm/index.html

Akkor most próbáld meg a belinkelt programmal is!

Sziasztok! Megépítettem Watt "WLPT Vpp mini v4 PIC programozó" - ját és működik is. Leteszteltem (pic16f871 és pic16f877-el) egy kész hex fájl-lal a verify is megy, visszaolvastattam tehát sikerült égetni. ( De csak az oshon 16f-el. Az Ic-prog-gal és winpic800-al meg se nyikkan pedig a winpic felismeria pic-eket. Na szóval a gond az, hogy van egy másik kész .hex fájlom és az oshon hibaüzenetet ír ki! "Input program file in Intel Hex format contains errors. Line number 1: Invalid 'checksum' field in the record. Sajnos a .hex fájlt nem tudom csatolni csak egy részét mert nem publikus, ez a .hex nem az én munkám. Az eleje így néz ki:

:020000040000FA
:020000002E28A8
:08000800D729820701340334FB
:100010000234063404340C340834093482070334BF

Valaki tudna segíteni?

Próbáld meg ezzel a progival Bővebben: Link

Ha a hex checksum sérült, akkor nem biztos, hogy működni fog a beégetés után! Töltsd le mégegyszer, vagy kérd el mégegyszer. Persze egy próbát megér, a WPB nem fog nyekeregni, mert egyelőre nincs benne ilyen irányú ellenőrzés, ezt a végére hagyom mindig...

Szerintem valami más lesz a probléma, mert ezekben a sorokban nincs checksum hiba! Az oshon 16f ismeri az Intel HEX32 formátumot? Legegyszerűbb, ha megpróbálkozol az első sor kitörlésével! Az ugyanis teljesen fölösleges oda...

Kéne neki!

Köszönöm a segítségeteket, de most meg már fel sem ismeri a winpic és a wpb. Valami gáz van a Hardware-rel meg lehet a hex-el is mert kitöröltem az első sort és a 205.-be talált valamit. Köszi mégegyszer! Átnézem az égetőt bár mondjuk a fesz-ek meg vannak rajta (Vdd 5V, Mclr 13.12V, Pgd 0,1 Pgc 0.1 (ha rá van dugva a párhuzamos portra)).

Miután kipróbáltad a WPB-t azóta nemismeri fel?

Kezdek aggódni, hogy van összefüggés, annak ellenére, hogy nálam nincs gond!

Aki WLPT_minit használ, az a PGD és a PGC vonalba az ICSP csatinál tegyen be egy-egy 270ohm-ot sorba a vonalakba. Lehet, hogy bizonyos konfigurációknál a kimenetet szembe lehet kapcsolni az égető kimenetével, ami a PGD, vagy PGC halálát okozhatja!
Igyekszem mindenhol ezt az infót terjeszteni, kérem ti is tegyétek ezt!

Azon töprengtem, hogy az elvi lehetőség ellenére miért nem történik meg az összes égetőnél ez a dolog, hiszen mind L szintet tesz ki a kimenetére alapból, ami gyakorlatilag rövidzárnak fele meg. Miért nem H szintet, ami minden égetőáramkörnél valamilyen felhúzó ellenállást jelent, így nem mehetne tönkre semmi!?
A kézi kapcoslású Vdd sem magyarázza a dolot, mert mindegyik égetőnél be lehet kapcsolni a Vdd-t külön és sokan ezt így is használják.

Azt kijelenthetem, hogy programkóddal PIC-et tönkre nem lehet tenni, tehát a szoftver nem okozhat ilyen hibát, csak elektronikai gond lehet. Én már a legetséges összes hibát elkövettem a fejlesztések alatt sok tucat PIC-el, de egyetlen egy sem ment tönkre eddig, pedig nekem sose volt soros ellenállás védelemnek a vonalakban.

A védelem ennek ellenére javasolható, és bele is fogom tenni a rajzokba, de meggyőződésem, hogy nem ettől ment tönkre a PIC, ha egyáltalán tönkre ment!

A beidézett sorokban jó checksum, így csak azt tudom elképzelni, hogy a sorok végén olyan karakterek vannak, amikre a progi nem számít (pl. unixos sorvég, csak 0A karakterrel), és emiatt hülyén számol.

De ez még csak nem is HEX32, az az első sor egy sima két nulla byteot tartalmazó bejegyzés a 0004 címre (ha nem tévedek).

Ez nem az egész hex, csak egy része, mert a kérdező szerint az egész az titkos.

A 04 a sor típusát jelenti itt a cím(0000) nem értelmezett. Az adatban található címet kellene 16bittel balra shiftelni, de mivel az is 0000, így ez sem érdekes jelen esetben.
02(két adat) 0000(normál esetben cím, itt semmi), 04(sor típusa=kiterjesztett lineáris cím), 0000(maga a cím, amit 16bittel balra kell shiftelni), FA(ellenőrző összeg)

Ok, rájöttem már, hogy a típus és a cím mezőket felcserélve néztem. Így valóban egy címrekord az első sor, és ha az Oshon ezt nem ismeri fel, akkor emiatt problémázhat. Igaz, hogy akkor viszont jó lenne, ha a hibaüzenet azt tartalmazná, ami a problémája a sorral, mert a checksum rendben van!

A kettőspont után a negyedik bájt a rekord típusa, s csak az I32HEX formátum engedi meg a 04 és 05-ös rekordot. Bővebben: Link

Már rájöttem, hogy igazatok van, csak mostanában nem "olvastam" hex file-t és hirtelen az volt bennem, hogy az első byte a hossz, a második a típus és a harmadik-negyedik a cím.