Egyébként szabvány szerint a HID tranzakció során másodpercenként kb. 1,18 MByte küldhető el. Más kérdés, hogy ezt a kontroller képes-e megvalósítani vagy sem.

Igen, de amit linkeltem cikket, az tuti tudja a 64kByte/sec-et, mert én is megcsináltam. :yes:

Revideálnom kell magamat, amikor az előző hozzászólásban HID tranzakciót írtam, akkor interrupt tranzakcióra gondoltam. Bulk transzferrel valamelyest érdemes vigyázni szerintem, mert ha több eszköz is csatlakozik a buszra, akkor a bulk transzfernek van a legkisebb prioritása, tehát ha a buszon nincs interrupt vagy control transfer akkor küldi csak el a bulk adatokat. Szerintem több endpoint használatával el lehet érni a nagyobb átviteli sebességet, mert a legtöbb időt a bufferek töltögetése viszi el, bár firmware szinten ennek nem néztem még mélyebben utána.

Tudom, én is csináltam már HID classes interrupt transzferes kommunikációt, én csak azt mondtam, hogy a szabvány ennél nagyobb adatátvitelt is tud.

16 biteseken DMA-val foglalkozott mar valaki? Azzal nem lehet a USB buffert gyorsabban feltolteni?

Bár konkrétan a kérdés tárgyával nem foglalkoztam, de szerintem addig nem lehet vagy nem szerencsés piszkálni a buffereket ameddig az átvitel véget nem ér, de lehet, hogy nem lenne vele gond. Amikor a tranzakció véget ér, akkor meg már szerintem késő elkezdeni pakolgatni a bufferbe. Ha több végpont van, akkor csak a végponthoz tartozó adatokat kell átadni az USB átvitelt megvalósító függvénynek (EP, buffer*, buffer méret), és nem kell a buffer feltöltésével időt veszíteni. Természetesen a bufferek töltögetését a DMA már nyugodtan végezheti, így a főprogramnak sem csak az adatok mozgatásával kell foglalkoznia, mellette tud más feladatokat is ellátni.

Sziasztok!
Korábban már használtam USB-t 18F4550-el, de most PIC32-vel szeretném használni. Csináltam egy kis áramkört PIC32MX795F512L-es PIM-el, PicKit 3-al programozom és rendben működik. Kipróbáltam az Microchip-es gyári mintaprogramokat, de amikor bedugom a gépbe az USB-t, akkor semmi sem történik egyik programmal sem, a gép nem érzékeli az új eszközt. Mi lehet a probléma?
Az USB-s rész kapcsolását csatoltam.

Esetleg hasonlítsd össze a PIC32 Ethernet Starter Kit kapcsolási rajzával.

A PIM alatt a MA320003 modult érted? Hol kaptál hozzá 1,27 mm-es lábtávolságú tüskesort?

Én nem látok különbséget, és máshol is ezt a kapcsolást láttam.
Igen, az MA320003-at értem. Lomex-nél van, de nem olcsó. (850-10-025-10-001101 a száma annak amit én használtam)
(Mondjuk lehet, hogy nem a precíziósat kellett volna megvenni. Csak az utolsó talán fél miliméteren érintkezik. De rendesen érintkezik, szóval nem ez a probléma.)

Én is ezzel a proc.-al (PIC32...) és USB-vel küzdök, nekem sem szólal meg. Ha jutottál valamire, válaszolj légysz.

Helló mindenkinek!
Abban szeretném kérni a segítséget, hogy usb-ről lpt-re átalakító ic-nél (FT245BL) a kimeneteit hova kellene kötni a 25 pólusú csatlakozóba?
(gondolok a képen látható RD, WR, _TXE, _RXF, WREN lábakra) Van egy LPT-s pic programozó, ahhoz kellene az átalakítás.
Bocsánat, ha nem egészen ide illő a kérdés.
Köszi a segítségeket előre is.

Ne fecséreld rá az időt, nem fog működni! Keress rá, miért nem! Vegyél egy PCI-os LPT kártyát, megéri, vagy építs egy PK2-t, esetleg vegyél(mert nem sokkal drágább, mint az LPT kártya...)!

PK2-m már van,pont a Te clone-odat csináltam meg.
És a Chip is megvan (FT245BL). És Úgy gondoltam, hogy, ha működik a chip, akkor máshoz is lehetne használni. Pl Lcd-hez.
Viszont az FT- adatlapjából nem tudom kibogarászni gyér angoltudásom miatt, hogy ezek a lábak a 25-ös lpt melyik tüskéire mennek. Pl az ACK, Busy...
Vagy ezek a lábak nem is alkalmasak hogy ezeket az lps-s lábakat úgymond helyettesítsék?
Köszi

Hidd el, diszkrét vezérlésre nem alkalmasak az USB-s átalakítók, csak adatátvitelre, aminek a belső üteme nem a te kezedben van.

Ahogy én látom ez a chip nem az LPT portra való bekötésre lett kitalálva, azaz nincs értelme úgy gondolkodni, hogy melyik láb a lehet az ACK. Ezeket mikrokontrollerekre szánták. Az említett lábaikon megjelenő jelek a FIFO puffer állapotait jelzik vissza ill. fogadják a kontroller visszajelzéseit a kézfogásos kommunikációhoz. Az adatlapban benne van melyik mire való, mikor jelenik meg rajtuk az információ. (8. oldal) Bővebben: Link

Ah, ezt nem hallom örömmel.
Mihez kezdjek akkor ezzel a chip-pel?
Esetleg HD44780-hoz valahogyan...?

Nem tudom milyen ütemmel lehet az adat vonalon az értékeket megváltoztatni, de működni működhet, csak lehet nagyon lassú lesz, illetve bonyodalmak lehetnek az időzítésekkel bizonyos helyzetekben. Egyenként kéne adatokat kivinni, viszont akkor 1kHz körüli lesz az órajel. Persze, lehet, hogy tévedek! A 8 vezeték 4bites módban elég lehet a vezérléshez.

Viszont akkor maga a program is változtatásra szorul, hogy a 8 biten menjen minden.
És mondjuk a mellékelt áramkört rá lehet varázsolni a chipre? Anélkül, hogy a vezérlő programban minimális( olyan, amit egy mezei ember is képes véghezvinni) változtatás legyen. Ráadásul itt csak négy láb van kihasználva.

Én nem bíznék benne, hogy rá lehet varázsolni...

Én is úgy gondolom, hogy nem. Jobban jársz egy PCI-os kártyával, feltéve hogy a program, amit használni akarsz ismeri a felső címeket is(EC00 stb...).

Bármit rá lehet kötni, de előbb annak nézz utána, hogy PC oldalról milyen programmal tudod kezelni ezt a chip-et!

A gyártó honlapján ugyanis olyan meghajtókat látok, amelyek PC oldalon vagy virtuális soros portként kezelik a chip-edet, vagy pedig kapsz egy DLL-t, amit meghívhatsz a programodból. Tudomásom szerint egyiknek sincs köze LPT porthoz, ezért az LPT portra alapozó alkalmazói programokat elfelejtheted!

Jogos, erre nem is godnoltam, pedig igazad van, ez COM-ként jelenik meg az eszközkezelőben!

Sajna a program, csak az alsóbb 0x378, 0x278, 0x3BC címeket tudja kezelni.
Ugyebár ez végett elfeledhetem a PCI-os kártyát.
Az nem lehet esetleg, hogy a kezelőproginak a PRINTIO.SYS -jében átírnánk valamit? Tudom, hogy nem ílyen egyszerű a dolog, de hátha mégis.

Az lehetne megoldás, hogy a pc oldalon szoftveresen egy lpt-t lát, és a rá kiküldött adatoknak megfelelően a másik oldalt az eszköz és az FT chip között egy pic átkonvertálja az adatokat a nyolc biten küldhető formába? Oda-vissza.
Persze ehez a pc oldalon is át kellene egy proginak "forgatni" az adatokat.

Vagy talán van egyszerübb megoldás is? persze a PCI-os kártyán kívül...

Köszi

Szerintem nincs jó megoldás akkor.

Ha van egy PK2-őd, akkor mit is akarsz tulajdonképpen?
Az FTDI chip-el USB-ről egy mikrovezérlővel tudsz fogadni adatokat, ha már benne van a pic-ben, azt csinálsz, amit akarsz. Mit szeretnél?

Bocs, Auf-nak küldtem...

Azt a Flasher kábelt szerettem volna rátenni. Na meg van több ketyerém ami lpt-ről menne. És a gépben nincs lpt.
Mivel kaptam ezt a chip-et, gondoltam jó lesz a kábel, ezekhez az eszközökhöz.
Egyébként arra gondoltam, hogy a program ami kezeli az lpt, egy virtuális lpt-re írna, amit egy másik program kiküld a chippel létrehozott átalakítóra.
Viszont, azt az egy bemenetet, nem lehetne áthelyezni egy másikra a data bitekből? A vezérlő forráskód nélkül, gondolom lehetetlen átírni.
Sajnos nem vagyok jártas a pc programozásban, és nem tudom, mi az oka annak, hogy ez az eszköz lpt-ről megy.

Az a gond, hogy a ketyerék többnyire az LPT port-ot nem csak adatátvitelre használják (mármint a data vonalakat) hanem pl. egyes biteket egyenként billentenek ki vagy be, ezzel vezérelve mindenféle dolgokat. Te viszont csak komplett byte-ot tudsz átvinni usb-n, ezért kell az FTDI chip után egy intelligens eszköz.

Egyébként. ha gondolod, skype-on folytathatjuk, úgy hatékonyabb.

Hi! ewery Bandy

Engem is érdekel a probléma, mostanában építgetem az n-edik égetőt, a( JDM nem működött, az LPT-s olvas, bizonytalan, és nem ír, rméljük lessz jobb is) végcélom 1 UDB-s égető, találtam a neten 1 komplettet dokumentációval, hozzá való több oprendszeres programmal. Egyszerűen építhető, nem kell hozzá + FTDI az USB-re.
A http://usbpicprog.org/ oldalon elérhető.
Viszont 1 nagy hiányosságát látok nem találtam ICD lehetőséget a SW-ben.
Lehet, hogy érdemesebb volna 1 ICD2 Kónt építeni!?

Tyo

Szia!
PICkit2 klónt építsd meg!