Szia!

Az első, a meghajtót is tartalmazó megoldás a megbízhatóbb. Ehhez hasonlóval programoztam éveken keresztül (még Dos és Window$ 3.1 alatt). Egy - két probléma szokott a párhuzamos portos programozókkal előjönni: - Az LPT port feszültség szintjei alacsonyabbak, mint évekkel ezelőtt, de a beépített meghajtó miatt ez az áramkör kevésbé érzékeny rá. - Az újabb window$ rendszerek nyomtatót keresnek a portokon...
A programozható eszközök száma nem túl nagy, csak az 5V-os példányokat fogja kezelni. De ezek között ott van a 18F2550, és segítségével meg tudsz majd építeni egy PicKit2 klónt...

Helló!

Inkább Ezt az égetőt ajánlom, ha már mindenképpen LPT-set akarsz. (amit linkeltél másodszorra az ennek az elődje, olvasd is el mindkét cikket, mert összetartoznak).
Aztán az égetőt Ezzel a programmal használd.

Mind az égetőt, és mind a programot Watt fórumtárs tervezte/készítette. Ezzel a programmal sokkal jobbak az esélyek hogy menni fog az égetés, mint akármilyen más programmal, de a problémát már HP41C leírta előttem.
Sokan mondják hogy más program nem égeti a PIC-be a programot, aztán ezzel a programmal sikerül elsőre (égető ugyanaz).

A program által támogatott PIC típusok:

Sziasztok!

A programozó programokról:
Itt az a probléma, hogy egy adott pillanatban (technológia - pc felépítés) mellett készül egy programozó kapcsolás és a hozzá tartozó program és azokat egy újabb konfigurációval szeretnénk működtetni. A paralell portos tervek kb. 10-15 évesek, ezalatt a PC-ből 3 generáció lement. A jelek előállításának időzítésével van a probléma. Az írások / olvasások közötti időt kellene betartani, ezzel kell a programozási jelalakot előállítani.
- Az LPT-re kapcsolódó programozók tervezésénél az ISA buszra kötött periféria írás - olvasás sebességét vették figyelembe (kb. 1us volt egy írási ill. olvasási ciklus hossza.) Az akkori fordító programok ms nagyságú időzítéseket tudtak kezelni (ld. Turbo Pascal / C delay függvénye), ezt használva a programozás csiga lassú. A másik megoldás pont az írás/olvasás időzítésének felhasználása volt: Két írás között meghatározott számú más (feleslegesnek látszó) periféri műveletet elvégezve kialakult a kívánt időzítés.
- Az ISA bus kifutott, jöttek az alaplapra integrált perifériák és a gyorsabb processzorok. Az írási / olvasási időre nincs semilyen adat, bőven lehet rövidebb mint 33 ns (>33MHz belső busz sebesség). A két írás és olvasás közötti idő, attól függ, hogy milyen sebességű a pc. Sajnos a mostanában írt programokra is eljön majd az idő, amikor a gépek túl gyorsak lesznek hozzájuk - ha még lesz rajtuk LPT port-.
A pontos időzítéseket olyan programozókkal lehet biztosítani, amiben kontroller van...

Igen ez igaz.
Viszont Watt pont ezt a gyorsaságot próbálta kiküszöbölni a programjában. Van is a programban egy csúszka amivel a programozás sebességét lehet állítani.

De igaz ami igaz, az LPT az idejétmúlt és lassú, és 1000-szer jobban megéri az USB-s PICKit2. Érdemes építeni/venni egy PK2-t.

Sajnos a perifériaműveletet nem lehet tudni, hogy pontosan mikor történik, de két parancs kiküldése közötti időt lehet us pontossággal időzíteni. Erre való a queryperformancecounter és a queryperformancefrequency nevezetű páros. Utóbbi mutatja, hogy mekkora sebességgel történik a belső hardveres számláló növelése, előbbi pedig a számláló pillanatnyi értékét adja vissza. Ha egy kis ciklus arra vár, hogy az előző értékhez képest adott mértékben emelkedjen a számláló értéke, akkor ezzel a kiküldések közötti idő minimális értékét be lehet állítani. Persze megszakítások elhúzhatják az időt, de ugye általában az a gond, hogy túl gyors az égetés, tehát a nyújtás nem probléma. EEPROM égetőben használtam ezeket, és processzortól függetlenül közel azonos égetési időket kaptam, pedig nem volt semmi utólagos állítás, csak a fentire támaszkodtam. Persze ha az égetőprogram úgy van megoldva, hogy for (i=0;i<1000;i++); akkor nagyobb sebességű processzoron rövidebb lesz a ciklus végrehajtási ideje, illetve egyéb más hardveres dolgok is beleszólnak, ez kétségtelen.

Én úgy vettem észre, hogy adatlapban előírt időzítéseket nem tartanak be, leginkább a szüneteket. Sok más programot is lehet lassítani elég nagy mértékben, az írás még sem működik, mert nem mindenre hat a lassító rutinjuk, legtöbbször csak az órajelre.
Összességében valóban a PC-k sebességében és az LPT portok eltérő kialakításában keresendő a hiba, de programozói hibák is tetézik a bajt, pedig ez egy alapvetően egyszerű programozási feladat.

Hozzátenném a listához, hogy közben a 16F84A is kezelhető.

Hello!

Először is köszönöm a válaszokat. Még az a kérdésem lenne hogy Watt programozójával semmilyen 12f -es PIC - et nem lehet programozni? Nekem leginkább PIC12F629 hez kellene mert elektromos dobókockát szeretnék építeni. A többi tipus ami kell nekem az benne van a listában.

Előre is köszi

Hello!
Próbálkoztam PIC-ről meghajtani motort (mobiltelefon rezgője) a kapcsolás szerint meg is építettem, de mikor bekapcsolom az áramkört, akkor a motor folyamatosan megy ahelyett hogy az alábbi kód szerint 2-szer impulzusszerűen menne. Valaki tudna segíteni, hogy esetleg a kapcsolás rossz, vagy a kód.
A motor elvileg mindkét irányban forog a polaritás változtatásával, nem tudom hogy ez számít-e esetleg a dióda bekötésnél. Segítségetek előre is köszönöm.

a kód amivel vezérlem:

void main() {
ANSEL = 0;
ANSELH = 0;
TRISC.F1 = 0x00; //motor kimenet
PORTC=0x00;

Delay_ms(5000);

PORTC.F1 = 1;
Delay_ms(300);
PORTC.F1 = 0;
Delay_ms(300);
PORTC.F1 = 1;
Delay_ms(300);
PORTC.F1 = 0;
Delay_ms(300);
}

Üdv!
A "TRISC.F1=0x00" parancsba nem kötött bele a fordító? Ugyanis bit szinten akarod módosítani a változót, de hexa értéket adsz neki.
Próbáld meg így:

Konfig bitek jól be vannak állítva? Kvarc berezeg? MCLR fel van húzva 5V-ra?
Amúgy így csak egy irányba tud forogni.

Nem kötött bele, de igazad van. Nem használok kvarcot, belsőt használok.
Nincs felhúzva az MCLR, fel kellene? Ha igen, miért kell felhúzni 5V-ra?
Tudom hogy egy irányban forog, most nem is szeretnék mást, csak hogy akkor működjön amikor kell.
A kapcsolás egyébkánt jó? Eredetileg nagyobb ellenállás volt bent (10k), de azzal el sem indult.

MCLR: Ha a konfig biteknél a funkciója "external"-ra van állítva, akkor azzal a lábbal tudod resetben tartani a PIC-et. Hogy beinduljon, 5V-ra kell húzni. Ha "internal"-ra van állítva, akkor nincs ilyen gond. (Bár ezt nem javaslom, lehet hogy csak én bénáztam vele, de 16F627-nél amikor internal-ra állítottam, nem tudtam utánna újraprogramozni. Talán akkor Low Voltage programming szükséges.(?) )
Kapcsolás: Jónak kell lennie, igaz én a hagyományos felállásban csináltam volna: Emitter a földre, Bázis ellenálláson át PIC-be, Collector pedig motorra, motor másik lába 5V-ra.

A progiddal kapcsolatban még annyi: a "delay_ms(5000);" utáni részt szándékosan nem tetted végtelen ciklusba?

Igen, ezt majd egy függvénybe fogom tenni, és azt hívom majd meg egy gombnyomásra.

Az MCLR-el kapcsolatban pedig, nem használtam még sosem ezt az internal/externalt és működtek a dolgok rendesen.
Kipróbáltam úgy hogy a motor nincs rákötve bekapcsoláskor, és csak 2 másodperc után kapcsolom rá (egy csatlakozóval), és akkor működik a két impulzus.
Viszont így nem jó nekem. :no:

Ha nem állítottál a MCLR-en, alapértelmezésként externálon van. Akkor viszont kell neki a felhúzó, nem tart sokáig beforrasztani egyet.
Az is valószínű, hogy a 22 Ohm-al nagyon leterheled a lábat, és nálad is az RMW hiba jelentkezik. Cseréld le legalább 300 Ohm-ra. Meg lehet próbálni, hogy nem bit szinten változtatsz értéket, hanem a teljes portot írod:

Köszi!
Most működik rendesen, az MCLR-hez ugyan nem tettem felhúzó ellenállást (a mikroC alapból pedig external-ra állítja, de mégis működik), de kicseréltem egy 330 ohmosra a motor előtti ellenállást és a programkódba pedig tettem egy olyan sort ami rögtön nullára állítja a kimenetet. Talán az volt a baj, hogy bekapcsoláskor hirtelen túl nagy áramot vett fel a motor és resetelte a PIC-et. Vagy nem tudom...

MCLR tönkre mehet felhúzó nélkül, és egyébként is kell oda, ha nem vagy biztos benne milyen módban van!

Rendben, beforrasztok egyet. De mekkora lenne ideális?

10 kOhm a szokásos érték. Akkor is kell felhúzás, ha MCLR internal módban van, mert akkor a láb digitális bemenet, amit nem illik lebegni hagyni.

Sziasztok!


Az szeretném kérdezni, hogy melyikkel járok jobban ha megveszem Pickit 2 vagy Pickit 3 ? Nem igazán vagyok otthon a témában.

Manapság már nem divat értelmes mondatokat írni?

Legyen PK2, olcsóbb is, kezdetnek jó lesz az.

Szia!

Ezt a kérdést sokan felteszik...

Érvek a PICKit3 mellett:
- Új fejlesztés, karbantartják - továbbfejlesztik,
- Több típust lehet vele programozni,
- Gyorsabb, a nyomkövetés kényelmesebb,

Érvek a PICKit3 ellen:
- A programjainak szolgáltatási szintje nem éri el a PICKit2 -éit,
- Kontroller család váltáskor a beépített kontrollert átprogramozza - a felhasznált kontroller garantást írhatósági száma alacsony,
- Ha az át programozás nem sikerül, a PICKit3 kontrollere csak egy másik ICSP kompatibilis (3.3V) programozóval éleszthető fel - amennyiben a programját előre kiolvastuk.

Érvek a PicKit2 mellett:
- Kiforrott fejlesztés,
- A programjainak szolgáltatási szintje meghaladja a PICKit3-éit.
- A teljes firmware -t nyilvánosságra hozta a gyártó, letölthető, frissíthető,
- Kontroller család váltásnál nem programozza át a belső kontrollert.

Érvek a PicKit2 ellen:
- Régebbi fejlesztés, nem tudhatjuk meddig tartják karban, meddig fejlesztik,
- Lassabb a programozás és a nyomonkövetés.
- Kevesebb fajta kontroller programozható vele.

Egyikkel sem lehetséges a 16Cxxx, 18Cyyy egyszer programozható kontrollerek programozása.

Köszi a választ.

MCP2200-vel találkozott már valaki? Próbálnám elindítani a konfigurációs programját, de vagy azt modja, hogy "Az alkalmazást nem sikerült elindítani, mert a konfigurációja helytelen.", vagy csak annyit mond, hogy "Error executing program!". Az eszem megáll az ilyen "informatív" hibaüzenetektől.

Egyébként magyar Windows XP + SP3 alatt próbálkozok, .NET 2.0 is van fenn (pl. Pickit2.exe miatt), és van fenn Visual 2005 C++ 2005 Express meg Windows Platform SDK is.

Sziasztok!

Remélem jól telt, telik a nyár mindenkinek.... Egy olyan problémával találtam szembe magam, amivel már egy ideje nem tudok mit kezdeni.
Most már zsinórban a 3. PIC-el történik ugyan az. 16F876A-t próbálok használni, de 3 különböző nyákon 3 különbőző céllal épített kapcsolásban a quartzos órajel nem akar elindúlni, addig a pillanatig, amíg az ujjomat hozzá nem érintem a quartz fém házához. Ha nem érek hozzá akkor lei is áll.
A szokásos elrendezésben van a 20Mhz-es cucc, kettő 22pF os kondival, amik a testre csatlakoznak. Nem értem hogy mi lehet a gond, mert 2 korábbi panelen ugyanebben az elrendezésben van a quartz, de tökéletesen működik.
Ha van valami ötletetek, kérlek osszátok meg velem...
Köszönöm!

The_Saint

Üdv újra

Nagyon jó hogy van ez a fórum Most, hogy leírtam neketek a problémát, azt hiszem közben rá is jöttem a megoldásra. Rosszul volt a CONFIG beállítva. Hiába quartz, de 20MHz-es és nem XT, hanem HS osc-t kellett beállítani neki..... Mosmár úgynéz ki, hogy megyeget!!!

Üdv
The_Saint

Ebben a topikban találtam olyan információt, ami az MCP2200 témakörben a .NET 2.0 konfigurálásával kapcsolatos, de az ott leírtakkal sem sikerült életre kelteni a Configuration Utility programot, úgyhogy végül a kukában landolt...

Sziasztok

Az mitől van, hogy ha tápod adok a nyáknak rajta a piccel az 10-ből egyszer nem kezdi a programot futtatni?

Miután a WDT ideje lejár és resetel utána indul.
POR 64ms
BOR 2V

Találkozott már ilyennel valaki?

Van néha, hogy külön reset áramkör szükséges, ha a tápfesz nem stabilizálódik kellő idő alatt a bekapcsolás után.

Milyen oszcillátorral? Nem lehet, hogy az nem indul?

Én ezt valószínűleg emelném (2,7 V-ra állítanám).