Szia.
Ezen a téren már szét néztem. De, nem csak soros emulálásra lesz a jövőben szükségem, mert usb beviteli eszközt is szeretnék majd programozni. Emiatt szükséges az usb leírók megértése.
Túl sok infót erről nem találtam, amit meg igen nem voltak kielégítőek.
Remélem erre téved valaki, aki ebben már profi és részletezné mi miért van benne.
Valamint, 1 pic-el ha megoldható a usb soros emulálása akkor miért ne.
Megmondom őszintén, nem igazán értem hogy hol lehet demo programot találni mlab x ide-hez.

A PICkit3-as programozó program alatt mit értesz? Ha estleg erre gondoltál, működik az Mplab 8 és Mplab X alatt is.

Üdv!

MPLAB X -> IPE, vagy a PICkit 3 v3.10 nevű program (PK2 módba kapcsolja át ezzel). De ez utóbbi már archív állapotban van, én is csak akkor használom, ha valamiért megmakacsolja magát a PIC. Minden letölthető a Microchip honlapjáról.

Halli
A képen lévö ellenállást és nyomógombot felcserélem
Az nem probléma ha elöbb a nyomógom és utánna az ellenállás??

A PIC-et tisztán 5V-al hajtsd meg. Az ellenállást a gomb és a csomópont közé tedd be. Teheted a föld és a gomb közé is, lényeg hogy az 5V-ot ne direktbe húzd földre.

Vagy is akkor mindegy ) Mindegyikkel működik Köszi

Nem mert a képen a PIC 5V-jába is benne van az ellenállás.

De én ugy használnám az ellenállást gnd felé gomb 5 volt fele

Ahol a pic felé 'elfordul a vezeték'' az alá tedd az ellenállást.

Így van Ezt írtam.

Részemről nem az x-es környezetet ajánlanám hozzá. Én beszereztem egy ubw32-est, és egy archiv mla-t, abban a környezetben kicsit érthetőbb a lib szerkezet, és levolt a gond a mindenféle mechanikai problémáról (nem lehet kontakt hibázni, parazita jelenségek jeltorzításaiba belefutni, stb). De teljesen jó bármilyen mc devboard is. Amit nem javasolnék elsőre, az a saját kezű áramkör, leszámítva azt az esetet, hogy végtelen türelmed van a hibák keresésére (én büszke vagyok a türelmemre, de még én sem kockáztattam meg..), mert új dolgok tanulásához jobb, ha megvan minden extra kényelem. Penge dolgot hasítani ráérsz később is. Aztán ahogy érzed, de szóltam előre, spórolni drágább lesz

A bulk átvitel a könnyebbik eset, de a többi sem különbség, csak azokban idő-kötelezettséged is van. Dióhéjban a lib endpoint-ban modellezi a kapcsolatot. Az endpoint egy logikai adattároló, kvázi egy statikus változó, ami vagy csak kifelé tud adatot küldeni, vagy csak befelé tud adatot olvasni. Kétirányú endpoint nem létezik az usb protokollok világában. Amikor adatot küldesz kifelé, ráhívsz egy függvényre, ami megmondja neked, hogy az endpoint felkészült-e már további adatok kiküldésére. Ha még nem, akkor vársz. Ha már felkészült, szintén van rá függvény, amivel feltöltöd azt az adatot, amit ki akarsz küldeni, és utána megint csak egy másik függvényre hívsz rá, amivel "élesíted" azt az endpointot. Aztán a lekérdezővel újra vársz, míg felszabadul a buffer, hogy további adatot küldhess ki. Amikor befelé olvasol, akkor lekérdezed, van-e szabad adat az endpointon. Amíg nincs, addig vársz. Ha már van, kiolvashatod, és jelezheted, hogy az adatot átvetted, az endpoint fogadhatja a következő adatot. Kiírásnál a kiírás tart, ameddig tart, beolvasásnál az adat átvétele tart, ameddig tart. Nincsen időkényszer, de ha nem küldöd az adatot, vagy nem veszed át időben, a sebességed visszaesik. A "várakozás" természetesen aszinkron, a főciklusodnak pörögnie kell. Az usb alsó réteg jellemzően interrupt alapon működik, a felső réteg a főciklusból hívott állapotgépen keresztül. De be lehet állítani interrupt mentesre is, csak akkor istenbizony pörögjön a főciklusod, mert időzítési kötelezettségeid vannak a protocol felé.

Példákat találsz az mla-ban, bármelyiket is töltötted le 2012..3013 környékéről, az usb generic példa szerintem mindegyikben benne lesz. Nézd meg, milyen pic-ekhez van support, és annak alapján vásárolj, vagy építs hardvert. A 32mx családhoz egy tipp: azok egységesek ilyen szempontból, az 32MX2xx-től kezdve a 32MX7xx-ig teljesen mindegy, mire akad példa. Én az MX795-ösön használtam az MX460-as példáját, de szerintem egy dugaszpaneles MX250-esen is ugyanúgy fut el, csak a hw config-ban normálisan kell összekotorászni az #if-ek között, hogy mi honnét kerül be a főprogramba. Kicsit pucolni kell a projectet az elején. De az olyan, azt szokni kell.

8 bites környezetben ha jól rémlik, csak szimpla bufferes az usb sie, 32 bites környezetben dupla buffered van, ott jobb a sebesség. Ha az is számít, tudd, hogy cpu teljesítményben természetesen a méret a lényeg. A generic alap példa 64kbyte / sec sebességet biztosít, mert a millisec frame-ben csak egy csomagot küld, ami max 64 byte a bulk transfer esetében. 32-es pic-el azt akkor is eléred, ha pár egyebet is beletuszkolsz a stack-be, 8 bites pic-el akkor sem feltétlen, ha csak az fut.

Host oldal. Kezdő példának jobb a generic usb-t használni, számítógép oldalon van .net lib is hozzá, a c# vagy akármi nyelv, amelyik kényelmes, azt választod. A példák között én csak c#-re találtam supportot, de ha akarod, átírod másmilyen nyelvűre, have fun. Kezdésnek legyen csak egy nyúlfarknyi kicsi program (megcsiszolod a példa alapján), hogy pic felől bekapcsolás után alapiniteled az usb-t, és eldobsz a számítógép felé egyetlen rövidke üzenetet, amit számítógép oldalon kiírsz képernyőre. Aztán átírod a programot olyanra, hogy folyamatosan küldöd az üzenetet ciklusban. Aztán tovább fejleszted olyanra, hogy számítógép felől küldöd el azt az üzenetet, amit pic oldalról visszaküldesz (random adathalmazt küldj, amit ellenőrizz is). Mire az is működik, a kezdeti usb gyorstalpaló végére értél. Ha jó érzéked van az informatikához (és legyen), a többivel már biztosan boldogulsz további segítség nélkül is.

A legelején ha hw problémák már biztosan nincsenek, adj magadnak legalább egy hónapot a fentiek végigtaposására, nem kell minden apróság miatt azonnal a community-t nyüstölni. Van ott bőven elég doksi, olvasd végig, vannak példák, próbáld végig, és csak ha már minden kötél elszakadt, semmi sem működik, és kalapáccsal vernéd szét az egészet, elég akkor kérdezni. De egy hónapnyi hobby idő nagyon sok idő, bőven elég a fenti játékokhoz.

Pff bocsi mindenkitől a blogba illő méretért, ekkorára sikerül

csaba8702: Akkor, neked bőséggel elég lesz a PL2303 USB-s adapter vagy Chip.
Igazából egy COM portot csinál ami megoldja az USB és Soros porti átalakítást.
Ilyet használok én is és elég jó az adatátviteli sebesség.

cross51: Olyan programra amivel közvetlen tudom beírni a kész hex-et.
Mint a PICkit2.exe-ével.

eSDi: Igen erre gondoltam: "PICkit 3 v3.10"
Ez a legfrissebb?
Tudsz linket dobni a közvetlen letöltéshez? Nem találom.

Szia.
Én is ezen gondolkodok. Eléggé nehéz témakör ez a cdc és a leírók is. Én meg szeretnék haladni a projekttel. FS 232 is jó? És ugye közös oszcillátorról kell hajtani őket.?
Ha van mintaprogramod azt el küldhetnéd valamilyen fájlmegosztón.
köszi.

Ez és ez is.

De mint mondtam, archív már. Sosem lesz belőle újabb, az sem biztos, hogy ismeri azt a PIC-et amit beszereztél.

Amúgy ez az oldal, a képek alatt a "Download Archive" fül.

16F és 18F pic-ekre alternatív megoldás lehet az arduino panel (uno r3).
Én kb másfél órája dugdostam össze és elég jól működik. Debug sajnos nincs.

Kinek, mi a szimpatikus. Én már maradok a PIC-nél, mivel a Microchip megvette nem is olyan rég az Atmel-t. Kíváncsian várom mi lesz a jövő. Marad e külön-külön ezután is, vagy idővel integrálódnak az AVR-ek tulajdonságai a PIC-ekbe, aztán csendben eltűnnek?

csaba8702: Jó az FS232 is, de azt én nem ismerem.
De gondolom ugyan az mint a PL2303.
Nagyon egyszerű a bekötése, de külön kristály kell hozzá.
Aztán már csak az UART-ot kell beállítani és használni, minden más illesztést megold a PL2303, FS232.
A PC-é is mint COM port ként fogja látni és ott is soros portként kell kezelned.

eSDi: Köszönöm. Leálltak a frissítésével?
PIC32MX795F512L-et vettem, elvileg azt ismernie kellene nem?

A Microchipnek az Atmel teljes értékű piaci konkurens, és nem integrálandó minor technology. Olyan kategóriában céget felvásárolni kvázi mint a róka a tyúkolban. Hihetünk az ártatlanságában, de azért csak gondolkozzunk, vajon miért mehetett oda egyáltalán?

El kell felejteni. Egy PICkit2 -t (azt is csak részlegesen) hoz létre emulációval a PICkit3 -ból egy majd öt éves eszközleíróval (1.62.14) - minden hibájával együtt... Ráadásul az MpLab(X) -el való felváltott használata váltásonként firmware cserét igényel.
MpLAbX vagy az MpLabX IPE -t kell használni - jó sok türelemmel...

És firmware csere mint tudjuk memória írás ha nagyon sokat csinálják problémát okozhat.
Bár 10.000 szer firmware-t cserélni az jó móka

De, ha nem kedveli a kolléga az X-et akkor a telepítésnél beállítható, hogy csak az IPE-t rakja fel és ott mindig megfelelőek lesznek az eszközleírok.

Nana, MPLAB IDE-ot használok, de a simát, és nem szándékozom váltani.
Azzal akkor nem is fogom teljes értékűként használni?
Vagy ezt most nem értem.
Vettem egy PICkit3-at és gyakorlatilag kukázhatom is?
MPLAB X-re nem váltok.

De az MPLAB IDE-ből is lehet programozni én régóta nem használom (nekem nem tetszik az "öreg " felület) de emlékeim szerint abban is benne van a PICkit3 és az IDE-én keresztül is tudsz programozni, de ha ez a hex-es módszer kell mindenképpen írtam ott az IPE amihez nem muszáj felrakni az X-et.

Én mindig úgy használom, hogy megírom vakon a programot (persze, ha MPLAB-ról van szó) majd, a lefordított hex állomány PICkit2 program segítségével beírom a PIC-be.
Ugyan ezt szeretném, PIC32 esetében, PICkit3-al is megtenni.
MPLAB debugját nem igen használtam eddig, de lehet el kell kezdenem

Én mindig notepaddal írom a programokat, nem használok ide-t, de a pk3-hoz kell valami környezeti micsoda, amit kényelmesen megtalál, ha telepítve van az mplab ide, és a c32 is pampog, ha az nincs telepítve, szóval feltelepítem + otthagyom, c32-t is feltelepítem, és kimásolom a pk3cmd.exe-t a projectek könyvtárába külön (az elérési utakon megtalálja a dll-jeit saját magának). Fordítani lehet .bat file-al is, meg beégetni is. Én minden projectet így építettem az mx795-höz.

Van már arról bizonyosság, mi a fenéért kell mindig várni a pk3 használatánál legalább egy egész percet a kereken semmire? Továbbra sem tudom.. Előfordulhat, hogy minden alkalommal röptében firmware cserél, bármit is csinálunk vele?


Én az utolsó mplab ide környezetében fellelhető háttérrel használom a pk3cmd.exe-t, amit szintén ott találtam meg. Miért lenne muszáj az X-et használni? Fentebb 32mx a célpont, 32mz még nem került elő.

Én úgy látom, vagy most kezded el használni az X-et, vagy később . Mondjuk én is inkább a régit használom, de volt már olyan típusom, ami csak az újban volt benne.

Nincs benne a sima MPLAB IDE-ben a PIC32MX795F512L ?

Sajnos a legutóbbi MpLabX újabb firmware -t tölt a PICkit3 -ba, ami már nem kompatibilis a régi MpLab -ban. Lehet persze a régi MpLab -ban is használni, benne van a PIC32MX795F512L.

Pontosítva:
MpLAbX vagy az MpLabX IPE -t kell használni - jó sok türelemmel - a PICkit 3 v3.10 helyett amennyiban a grafikus felülethez ragaszkodsz.

Miért kell hozzá türelem? Elég gyorsan beírja. Firmware-t is csak családváltásnál cserél a PK3 emlékeim szerint bár a sima IDE-t már rég indítottam el, nem tudom akkor cserél-e. Nemrég volt egy projectem ahol egy pic18 és egy pic12 ment együtt egy nyákon, na az macerás volt egy kicsit amikor a soros átvitelen dolgoztam. Egyébként semmi gondom az X-el, szerintem a felülete is jobb mint a régi.
don_peter: Nem mondom, hogy állj át az X-re, de ha PIC32-t fejleszted akkor állj át.

Nálam csak az IPE indulása 20 .. 30 másodperc, eztán keresi a programozót. Ha a tápot is a PICkit3 -ból szeretnéd adni, akkor minden alkalommal Andvanced (jelszó) és a beállítás (nem jegyzi meg)...