Mindenféleképpen érdemes lenne venned legalább egy Pickitet, de a 3-ast. Ha több pénzed van akkor ICD2-t vagy 3-at.
Én speciel ICD2-vel nyomom.

Esetleg tudsz segíteni hogy hol tudok ilyet be szerezni ?

ChipC@d

Az ICD2 már nem támogatott termék, ne ajánld kezdőknek.

Én a klónod építettem meg, tökéletesen működik

Az rendben van, hogy használod, én is az enyémet. Ha már megvan, akkor kidobni persze, hogy hülyeség lenne. De már én is vettem egy Pickit3-at mellé, mert a PIC32MX795F512L-t az ICD2 nem tudja kezelni. Ha valaki most akar építeni vagy venni égetőt, akkor nem érdemes ICD2-be beruháznia. Ha olcsón meg akarja úszni, akkor épít Pickit2-t. Ha kicsit többet szán rá, akkor meg Pickit 3 vagy ICD3.

Köszi az ötleteket akkor maradok az ICD3-nál
és egy kérdés
Mi a különbség a:
ICD3 + PICDEM 2 Plus és a
ICD3 + Explorer 16
között ?

Siess, jauár 5. -ig akció van:
Bővebben: Link
Bővebben: Link

Attól függ, mik a céljaid. Én azt mondom, hogy a PICkit2 megfelel a célra.
Szerk.: ha nem akarod utánépíteni, akkor is már 5-6ezer Ft-ért árulgatják.

A különbség a melléadott fejlesztői kártyákban van.

Túlzás lenne azt mondani, hogy a PICkit 2-n kívül ismerek mást, de: nem biztos, hogy elég, mégpedig azért, mert nemrég kezdtem el 18F14K22-t debugolni és 64 MHz-en nem sikerült a debug, 16 MHz-en igen. Még az MPLAB IDE is azt mondja, hogy nem 100% kompatibilis a két eszköz.

Persze megjegyzem, hogy más égetőt még soha nem használtam, tehát lehet, hogy nálam hozzáértőbb mégis azt vallja, hogy a PICkit 2 elég, én inkább a 3-at tanácsolnám.

Előre is elnézést, hogy ez nem a megfelelő topic, de valahol fel kell tennem a kérdésthozzá értőnek:

Ha vezetek egy 240VAC fázis sávot és egy 3,3VDC sávot egymás mellett egy NYÁK-on, akkor mekkora a minimális távolság, amit be kell tartanom a kettő mellet? És ha nem fázis, hanem nulla? És ha 48VAC vagy 48VDC? És 24VAC/DC? És 12V AC/DC? Minden esetben max 10A, ha ennek van jelentősége.

Másik hasonlóan fontos: az előbbi adatok mellé, 70 mikronos réz esetén, milyen széles sávok kellenek?

Tényleg bocsánat a hülye kérdésért, de a jövőben úgy szeretném tervezni a PIC-es NYÁKokat, hogy ezeket a paramétereket tiszteletben tartom.

Tudtommal hálózati feszültségnél a biztonságos távolságként 8mm-t szoktak megadni. Én egyébként úgy terveztem az ilyen panelt, hogy a nagyfeszültségű és a kisfeszültségű rész között végigvezettem egy védőföldre kötött fóliacsíkot, így elvileg az közelebb van, mint a kisfeszültségű részek, ha nagyon át akar ütni, akkor talán arra fog menni az áram. Azt, hogy fázis vagy nulla megy egy adott fóliacsíkon, azt valamilyen úton-módon tudod garantálni (pl. háromfázisú a cucc)? Mert ha nem, akkor a nullára is úgy kell tekintened, mintha fázis lenne.

Én annyira nem agyalnék a fólián, tennék mondjuk 2mm széles csíkot, és a nagyáramú szakaszokon a fóliára végig felforrasztanék 1,5-ös tömör vezetéket. Persze ha valami sorozatgyártmányról van szó, ott más lehet a helyzet.

Köszönöm válaszod, közben a szélességre találtam választ itt.

Minden tipped nagyon hasznos, de:
-Igen, sorozatgyártásról van szó és
-A sávjaim és a sávok közti hézagjaim is 10 mil-esek jelenleg.

A 10A-re már arra gondoltam, hogy feltöltöm ónnal a 2mm széles sávot, de a te réz ötleted mégjobb.

A 10 mil miatt és a panel mérete miatt (kb egy gyufásdoboz) nem tudok berakni 8 mm hézagot, viszont az álltalad ajánlott védőcsík, amit nullára kötök, az nagyon jó.

Maga az áramkör csak egy relét kapcsol ki-be és a relére azt kötnek, amit akarnak (általában 12VDC 500mA vagy 24VDC 500mA) a max terhelés, de a relé 250VAC 10A-es és nem szabhatom meg az ügyfélnek mit kössön rá. A relé 1 áramközös, tehát lehet, hogy a fázist köti rá, de lehet, hogy a nullát. Jelenleg földelés vagy hasonló nincs a panelen, hogyan csináljam a védősávot? Rakjam a Vss-re és azt kössem össze a hálózati áram földjével, vagy vezessem külön és a külön sávot vezessem a konnektor földelésébe?

Nos kipróbáltam. Ubuntu 10.04.3 64 bites rendszerre fel kell rakni az ia32-libs csomagot, anélkül nem volt hajlandó a telepítő elindulni, de persze semmi hibaüzenet nem volt, microchip fórumán írták, hogy kell. Ezután viszont egyből települt, sőt a C18 és C32 fordítók is next-next-finish módon felmentek.

Volt egy próba forráskód kéznél, csináltam egy új projektet pic32-re, bemásoltam a forrásfájl tartalmát az új projektbe, változtatás nélkül lefordult. Projekt létrehozásnál beállítottam a Pickit3-at égetőnek, fordítás után azonnal égette is, és a led villogott is. Viszont úgy tűnik, hogy sajnos beigazolódott a félelmünk, mert nekem az egész jóval lassúbbnak érződik, mint a "régi" mplab. "Nem az a baj a Javaval, hogy lassú, hanem az, hogy qrvalassú".

Azért elsőre nehezebb eligazodni a menűkben, de végülis mindent megtaláltam, amit kerestem. Ami viszont nagyon nem tetszik, hogy egy egyszerű Hold in reset-Release from reset művelet vagy 3-4 másodpercig tart, és közben 2-3 szor is reseteli a kontrollert, amit látok a kontrollerre kötött led villanásaiból. A régi mplabot Virtualbox alól futtatva szinte azonnal reagál a Hold in reset-release from reset parancsra, és nem villan többször a led. Szóval egyelőre ennyi, mostmár aludni kellene, majd holnap megpróbálok valami TCPIP gyári példakódot lefordítani.

A 10 mil. az 0,25mm. Amit remélem hogy nem a hál. vezetősáv és a kisfesz. vezetősáv között akarsz használni. Egyébként, ha a cuccot kereskedelmi forgalomba akarod hozni, akkor elég sok mindennek meg kell felelnie. (De ez nagyon nem az a téma.)

Köszi a két ünnep között meg látogatom őket és veszek egyet magamnak de szerintem akkor ICD3 lesz de majd még ott meg kérdezem melyiket ajánlják .

Jelenlegi áramkörömön kis és nagy feszültség között kb 15-20 mil lehet a távolság, mert többre nem futotta a panelen. De a jövőben tekintettel leszek rá, hogy ennyi nem lehet.

Ha nem tudsz rajta változtatni, akkor inkább el se készítsd. Ha beleset lesz belőle, akkor börtönbe kerülhetsz. (Ez csak jó tanács. És nem vicc.)

Köszönöm!
Szerintem kicsit drasztikus vagy, de nem szeretnék vitatkozni, mert hiszem, hogy meggyőződéssel írtad, amit írtál.

Mint említettem, szinte minden esetben 24V a maximum, ami átmegy az áramkörömön. Mivel nem tudok 8mm távolságot biztosítani kis és nagyfeszültség között, ezért a jövőben ki fogom hangsúlyozni, hogy nagyfeszültségben használata tilos. Tervezek majd egy másik modellt, ahol bőven meglesz a 8 mm és még a fentebb említett védősáv is, hogy az áram arra húzzon át extrém helyzet esetén.

Minden tanácsot köszönök.

Következő kérdés: Hogyan csináljam meg TUTIRA a túlfeszültség levezetést: biztosíték, varisztor, gázkisüléses cső, ...? Egyfázisú 240VAC-re gondolok itt és jó lenne, ha a kisfeszültségű köröm akkor se sérülne, ha a nagyfeszültségen másodlagos, vagy közvetlen villámcsapás következik be. Szintén jó lenne tudni, hogyan menthetem meg a kisfeszültségű körömet, ha abba a konnektorba, amiben a 12V-os trafó van, belecsapna az áldás. Itt a dolgok így néznek ki: Hálózat, Trafó, diódahíd, LM2576 és 7805, PIC

-> rózsafűzér keresztben !
Ez olyan hatalmas energia, hogy nem tudod elnyeletni meghibásodás nélkül, ha bekövetkezik !

Steve

Tegyél fel villamharítót a házadra

Pedig jobb lesz megszokni...

A 8 kb. hónap múlva megjelenő új típusokra már csak az MpLab X -et lehet majd fejleszteni...

Tényleg, elfelejtettem írni. Kipróbáltam a TCPIP Demo App projektet, újrafordítottam, változtatás nélkül fordult és beégetve működik is.

Viszont találtam egy hibát is. A weboldalokból fordítható illetve feltölthető image-t készítő MPFS2.jar nevű eszköz ugyan Javaban van írva, hogy minden platformon fusson, viszont a kimeneti könyvtár végére a saját eszétől odarak egy \ jelet, ami Linuxon nem jó, és ezért végül hibaüzenetet ad, hogy nem található a megadott mappa. Leszedtem a legújabb MAL csomagot, de a hiba abban is fennáll, úgyhogy végül virtuális xp-re raktam javat és onnan tudtam használni. Használhattam volna a régebbi csomagból a natív windows-os MPFS2.exe-t is, csak közben volt egy hiba a kódomban, és először azt hittem, hogy nem megfelelő a generált .c fájl az újabb stack-hez, ezért kisérleteztem az újabb MPFS2-vel.

Szia! Én még úgy el vagyok havazva, hogy még mindig nem tudtam megnézni amit küldtél! De itt is köszi, biztosan sokat segít majd!

Sziasztok !

PIC elektromos kérdésem lenne. PIC24FV32KA302 28 lábú picnél nem írja, de lehetséges hogy össze van kötve a VDD/Avdd és a VSS/Avss ? Műszerrel mérve szerintem össze van kötve. Adatlap nem ír erről semmit, csak hogy +- 0.3 ra térhetnek el egymástól, meg a lábkiosztásnál van sima vss, vdd meg még 1 lábpár vss/avss, vdd/avdd felirattal.

De ha össze vannak kötve, akkor szerintem nem lehet más feszre kapcsolni őket, mert kiéghet valami belül.

Szerettem volna külön tápról járatni az analóg részt, jól megszűrve, meg az analog Vss -t kicsit eltolni negatív irányba hogy ne legyen offset hibája az adc nek. De így szerintem ez nem megvalósítható.

Nem hiszem, hogy belül össze legyenek kötve, hiszen akkor minek lenne AVdd és Avss, akkor simán Vdd és Vss lenne. Inkább az van, hogy a belső PN átmenetek nem engedik meg, hogy +-0,3V-nál nagyobb feszültségre elmenjenek a Vdd-Vss lábaktól. Szóval direkt külön tápról nem birod járatni, főleg nem mehetsz ki a Vdd-Vss tartományból.

Az adatlapban is azt irja a kérdéses lábakra hogy: VSS/AVSS, VDD/AVDD. Innen eredt a gyanúm, hogy nem jutott hely a 28 lábú tokon külön táp lábnak hely.
Bár fura, hogy a 44 lábúnál is így írja. Viszont a PIN ek részletezésénél, meg simán csak avss, meg avdd van. Fene se érti ezt.

Műszerrel nézve 2k -s méréstartományban 1-et mutat a műszer a sima vss és a vss/avss láb között, szerinted ez nincs összekötve ?

Vdd és Vss tartományból ki lehet lépni 0.3V al szerintem mindkét irányba. Én legalábbis ezt olvasom ki az adatlapból. De lehet hagyom a táplábakat békén és a fesz referencia lábakkal oldom meg az offset gondot. ( amit még nem próbáltam ki, de úgy tudom van egy kis offset hiba minden pic adc nél, ha 0V a ref- , és 0V környékén akarunk mérni vele )

A Karácsonyra való tekintettel (bár már épp elmúlt) a fa alá teszek egy karakteres LCD kezelő függvényt amit elsősorban USB-s alkalmazásokhoz csináltam PIC18-hoz C18-as fordítóra. Az USB-s alkalmazásoknál az a lényeg, hogy nem lehet hosszabb ideig várakoztatni a programot mindenféle várakozásokkal, mert összeomolhat az USB kapcsolat. Ez 48MHz-es órajelnél (USB) 30usec időre tartja fel csak a program futását, igaz ilyenkor mindig csak 1 karaktert küld át az LCD-re ezért sűrűn kell hívogatni.
A lényeg az lcd.h és az lcd.c file-ban van. Saját projecthez elegendő ezt a két file-t átvinni a projectünkbe.
Használata:
1. projectünkhöz adjuk hozzá az "lcd.c" file-t
2. a programunkba "lcd.h"-t beinclude-olni.
3. Az lcd sorok számát és a sorhosszát lcd.h-ban beállítani
4. 4 vagy 8 bites üzemmód beállítása lcd.h-ban
5. lcd.h-ban az I/O lábakat bállítani (lábanként 2 definíciót kell: TRIS, LAT, valamint a D7-hez a PORT-ot is, bármelyik lábat bármire állíthatjuk, nincs korlát hogy pl.4 bites csoport legyen a D4-D7)
6. a projectünk inicializáló részén (induláskor egyszer) hívjuk meg az LcdInit() függvényt
7. a projectünk főprogramhurkában hívogassuk LcdUpdateChar() függvényt (ez 48MHz-es órajelnél nem igényel 30usec-nél több időt)
Ez mindig csak egy karaktert frissít a kijelzőn, ezért érdemes sűrűn hívogatni.
8. a projectünkben bármikor szabadon irkálhatunk az LcdText tömbbe. A frissítés során tartalma idővel át fog kerülni a kijelzőre. A tömbben levő #0 karaktert automatikusan szóközzel helyettesíti.

Demo-ként egy kis óra programot írtam (demo-ora.c) (azért demo, mert beállítani nem lehet az órát, meg a szökőévet sem ismeri)
Ha a demo-t lefordítod és nem HID bootloadert használsz előtte állítsd be a bootloaders.h -ban a megfelelő opciót, valamint a linker scriptet.
Sajnos a 8 bites módot és a 2x16 karakteresnél nagyobb kijelzőt nem tudtam kipróbálni, csak bízni tudok benne hogy működik. Ha mégsem kérlek jelezzétek. A 4x40 karakteres biztos nem működik, mert az két vezérlőt tartalmaz külön 'E' lábakkal (a DDRAM 7bites címe eleve nem is lenne elég a 160 karakterhez).
Ui. egy byte bitjeinek direkt hozzáféréséhez valami típuskényszerítéses módszert tudtok? Akkor lehetne kicsit normálisabb kód az LcdWrite függvényben. A maszkolós módszer nem tetszett mert nagyon bonyolult és hosszú kódot csinált belőle.

Ez remélem nem a túlcsordulás jelzése ?

Steve