Sony fényképezőgép. A munkahelyen 4 gép közül egyiknél sem akarta felismerni a PC. Aztán rájöttem hogy a hátsó USB-k közül van olyan amelyikbe felismeri.
MIO P560 PDA. Sem az itthoni sem a munkahelyi gépemen nem akarta felismerni a PC. Rádugtam egy hátsó USB-re és rögtön létre jött a kapcsolat. Aztán meg a hosszabbító vezetékek is gátolhatják a kapcsolatot.
Szóval még a gyári eszközöknél is vannak problémák.

Azt próbáld meg, hogy bedugod. Aztán amikor az eszközkelőben látszik hogy ismeretlen eszköz, akkor az ott uninstallálod. És ezek után újra próbálkozol a rádugással. A PICkit2 nemhiszem hogy bezavar, más a PID-je biztosan.

Egyébként lehet az előlapi meg a hátlapi portok közt különbség. Nekem például a gépemen külön Host vezérlő van az előlapi és a hátlapihoz is. Sőt igazából kb 6db USB Host vezérlő meg root hub van benne. Mondjuk ha jól emlékszem nálam egyformák, de lehet hogy van ahol nem és ezért egyikkel működik másikkal nem.

Na jó de mindkét gépen hibásak lennének a portok? Egyébként a demoboardhoz kapott dokumentációban azt írja hogy egy 3.3V-ra felhúzó ellenállás különbözteti meg a High/Low Speed-et én viszont a gyári demo boardon nem látok ilyet. Lehet ez a baj?
Ráadásul ha rádugom a Pickti2 tail-t úgy. hogy a demoboard van bedugva usb-re a pickit2 tail meg csak ugy 'lóg', akkor meg rögtön felismeri az eszközt, hogy HID vagy CDC és máris megy.

Szia.
18f14k50-el foglalkozom én is USB-n. Prímán megy.
Nekem is csinálta ezeket.
Kell egy kondenzátor ~0.1µF a, Vusb (aszem 17láb) és 0V (Gnd, Vss ahogy nevezzük). Nem árthat még egy 1µF 5V(ha öt voltról megy) és 0V közé. D+ vagy D- és Vusb-re nem kell fel ellenállás mert a microchip firmware-ei használják a belső felhúzó ellenállást. Ha d+ és d- drótok a helyükön vannak, bent van a két kondi nagyon stabilan el kell induljon.
MCLR lábat fel kell húzni 5Vra 10k ellenállattal, és egy kapcsolóval testre. Arra is figyelj, hogy a próbaprogramok úgy vannak gyárilag konfigolva, hogy a USB HID bootloadert használják, amit nagyon ajánlok. nem kell tökörészni pickit2-vel sem.
Ha nem megy kérdezz.
Üdv, G,

szerk. u.i.: esetleg oscillátorra a 12MHz-s quartzra még a két 22pF es kondik a 0Vra. Próbaképp volt hogy nem raktam be, ment úgy is. De azért az kell...

Jól látom az adatlapban, hogy a 14k50 sem tudja előállítani a belső órajelből is a (full speed) USB-hez szükséges órajelet? Kizárólag 12MHz-es külső kvarccal lehet használni az USB-t?

Nem néztem az adatlapot, de az USB szabvány elég nagy pontosságot követel meg az órajelnél (valami 10kHz maximális eltérés rémlik, ha 20MHz-es kvarcot használsz, vagyis 0,5 ezrelék), a belső oszcillátor pedig csak néhány százalék pontosságú.

Közben megnéztem az adatlapot, elvileg a pirossal jelzett útvonalon mehetne az USB a belső oszcillátorról, de szerintem hibás a rajz, és össze van cserélve a Low Speed USB és a High Speed USB felirat, illetve az nemis High Speed, hanem Full Speed kellene, hogy legyen.

Na még egyszer megnéztem, és most már úgy tűnik, hogy mégsincs összecserélve a felirat. Viszont továbbra is úgy tűnik, hogy nem lehet, mivel a Full Speed-hez 48MHz kell, a belső oszcillátorból meg vagy 32 vagy 64MHz-et lehet előállítani a PLL-el. Gondolom erre jutottál te is. Szerintem az előbb említett pontosság miatt nincs lehetőség a belső oszcillátorról Full Speed USB-re.

De hogy miért vették ki azt, hogy 4, 8, 12, 16, 20, 24MHz-es kvarc bármelyikével lehetne járatni, és a PLL előtt egy előosztóval választanánk a kvarcot, azt nem értem én sem.

De az nem jó, mert 48MHz kell a full speed USB-hez, ha meg a 8MHz megy a 4x-ező PLL-re, akkor csak 32MHz alakul ki. Valahogy nem áll nekem össze ez az egész, hogy mi értelme van az ilyen oszcifelépítésnek, ha nem lehet a belső órajelről hajtani az USB-t.

Egyébként a 18F67J50 család belső oszcijának olyan a felépítése, hogy azzal lehet kvarc nélkül 48MHz-et adni az USB-nek (mintha ezt az adatlapja is kiemelné), régebben vettem is ilyen PIC-et, hogy majd kipróbálom, csak időm nincs soha semmire...

Mellesleg éppen arra lettem volna kíváncsi, hogy a gyakorlatban vajon mennyire használható a belső oszciról működő USB, és valamiért úgy emlékeztem, hogy a 14k50-nél ez megoldható. De az adatlap ebben teljesen elbizonytalanított. Az, hogy a specifikáció mit mond, és hogy a gyakorlatban mi mennyire működik jól, nem mindig van szinkronban. Amellett, hogy igazad van a megkívánt pontossággal kapcsolatban, gondolj bele, hogy az FT232RL is működik kvarc nélkül, tapasztalatom szerint nagyon megbízhatóan.

Az én olvasatomban ez úgy vala, hogy a 16MHz belső osc, 8MHz-re osztottja tud menni a 4x pllbe amiből lesz a 32MHZ ami nem jó.
12MHZ külső Q.-t tudsz négyszerezni 48MHz-re. Ami meg már jó lesz.
Ez egy kis láb számú IC. Ez tény. Ha sok láb kell, keress másik IC-t. Az Osc az kell Oscnak.
Szerintem... :gumicsirke:

Ezt a low - full - high dolgot ezt tényleg jól elbták.
High speed USB-re mivel tudnék fejleszteni?
Köszi,G,

Szerintem meg pont a kis lábszám miatt lenne igenis értelme annak, hogy a belső oszciról meg lehessen oldani az USB órajelet. Pl. csinálhatnál vele egy egér- vagy billentyűzetillesztő, vagy akár soros porti kütyüt, amikhez igazán nem kell a sok láb, viszont a kvarc elég zavaró, hogy ott lifeg az egyébként majdnem nulla alkatrészigényű cuccban.

Pont ezeket meg is csináltam vele. Egy "egérhez" nem is kell több láb. Billzethez lehet kellhet több láb.
Van benne ráció amit mondasz. De mit tehetünk... ez van ezt lehet szeretni.

Az adatlap elég egyértelműen fogalmaz: "Because of timing requirements imposed by the USB specifications, the Primary External Oscillator is required for the USB module." Vagyis az USB specifikáció időzítési követelményei miatt az elsődleges külső oszcillátort kell használni. A belső oszcillátor stabilitása nyilván nem felel meg a követelményeknek.

Azt is írja az adatlap, hogy Full Speed-hez csak 12 vagy 48 MHz-es órajel jöhet számításba (fix 4x PLL, vagy anélkül). Ezt csinálhatták volna másképp is, de így történt...

Például a Cypress Hi-speed USB illesztőivel. (egy PIC18 amúgy is gyenge legény a max. 480 Mbit/s adatáramlási sebességhez)

Szia!
gamer egerek, webkamerák, fényképezőgépek, pendriveok, memkari olvasók, fullspeed vagy highspeed csatlakoznak?
Azok kábé filléres alkatrészek. Ezek tudnak 480Mibitps-t?

Az egérnek - akármilyen - bőven elég a Low Speed is, de általában Full Speed-esek szerintem. Ha mégis Hi-Speed-es, akkor az sima parasztvakítás. A többi cucc Hi-Speed-es, mert a Full-Speed kevés nekik, de a Hi-Speed-et viszont nem tudják kihasználni. Pendrive, memóriakártya, fényképező tud 10-15MBps-t, ami 100-150Mbps. Esetleg a kártyaolvasó tud többet, ha több kártyát egyszerre macerálsz vele.

Nem az árról van szó, hanem a PIC18-at, ami 12MIPS-et tud (elméletben), azt le lehet folytani még a Full-Speed-el is (kb. 1MBps körüli adatfolyam), nem származna semmi előnye a Hi-Speed-ből. Hi-Speed-hez nagyobb teljesítményű kontroller kell, talán egy PIC24H-val már lenne értelme, de inkább csak valamelyik PIC32-vel a Microchip termékei közül.

Az 1-2 gigás Kingston pendrive biztosan High speed, mert 10 Mbyte/s sebességgel olvas, az pedig legalább 80 Mbit/s, tehát többszöröse a Full speed-nek.

Hát annyit nem. A 480 az egy elvi felső határ. A Western Digital USB diszkem már közelebb jár hozzá (~ 200 Mbit/s) de nem tudom, mi van beépítve.

Jóreggelt Uraim!
Köszönöm a válaszokat.
No hát nekem is ezek lettek volna a tippeim és hálás vagyok az leigazolásokért.
Tehát "otthoni" körülmények közt, ne dédelhessek olyan álmokat, hogy "hobbi" alkatrészekből komolyabb sebességet elérek.

Üdv, G,

Hi Srácok!

PIC18F2550-el szeretnék egy kicsit széthekkelt USB kommunikációt megvalósítani.
Alapvetően CDC-re gondoltam és ha jól szűrtem le a korábbi hozzászólásokat a kapcsolódási ciklus után a kapcsolat fennmarad, csak az USB kiszolgáló függvényeket kell pollolni, hogy átmenjenek az adatok a PC fele.
Mivel nem olvastam minden hozzászólást nem tudom biztosan, hogy nem volt-e már ilyen kérdés, de nekem az lenne a kérdésem, hogy szerintetek meg lehetne-e csinálni úgy, hogy egy saját Send() föggvényben adni át az adatot és egyből le is kezeltetni a kiszolgáló rutinokkal amit kell és kb ugyan ezt Get()-re is valami hasonló módon, bár nyilván itt azért kell a rendszereresség, hogy a PC felől real-time-nak tűnjön a parancs küldése.

Előre is köszi a válaszokat!

Üdv:
N

Próbáld ki. Nekem nem jut semmi bizonyíték eszembe, amiért nem lehetne megcsinálni így. Valami azért rémlik, hogy ahhoz, hogy egy adatküldés adatai átmenjenek, ahhoz többször kell meghívni az USB kezelő rutint, de ez nem biztos, lehet, hogy valahol máshol olvastam.

Szerintem amennyire lehet real time. Legalábbis úgy működik hogy betolod egy bufferbe az adatot, és amint lehet az ki is küldődik. Az csak egy dolog hogy meg kell hívni az usb kommunikációt intéző függvényeket, mert hát valahogy ki kell küldeni ténylegesen. Vagy ha nem erre gondolsz akkor nem értem hogy mit szeretnél. Mondjuk emlékeim szerint elég érezhető a késés a küldés és a PC oldalon az adat megjelenése között, igaz az lehet hogy a PC-s szoftveren műlik.

Arra gondolok, hogy ugye itt úgy megy a kommunikáció az alap példában, hogy vannak a saját, lehetőség szerint nem blokkoló függvényeid, amikkel lapaesetben generálod az adatokat, és ezek itt kerülnek bele az usb tárba, amit majd az usb kezelő rutin kiküld.

Nekem konkrétan a kódom egy szenzort vezérlene illetve egészen pontosan egy szenzorhálózat egy node-ját. A hálózat rádiós és van mindenféle állapotgép benne és egy protokoll a rádióra. Namost úgy szeretném megoldani, hogy lehetőség szerint én irányítsam, hogy mikor akarok küldeni illetve fogadni és ne a blokkolódástól függjön. A kódom alapvetően ciklikus lesz persze és nem fog percekre beakadni, de jó lenne, ha tudnám egy sima perifériaként kezelni az usb-t, mint egy rendes soros vonal. --> ha akarok írok rá és néha lekérdezem, hogy jött-e valami.
Ellenben nem tudom, hogy pl a kapcsolatfelépítés után a sie fenntartja-e a kapcsolatot és nem lesz-e timeout, ha nem hyvom meg mondjuk 2 másodpercig az usbtasks függvényt.

Ja igen, az adat nem sok, néhányszor 10kbyte, és az is elosztva.

Úgy emlékszem, hogy az enumeráció után a kapcsolat nem akadt le, ha nem hívogattam az USBTasks() függvényt. Legalábbis a windows eszközkezelőből nem tűnt el a cucc. A SIE elintézi a kapcsolatfenntartást hardvertből, ahhoz nem kell a processzortól semmi.

Ez volna a lényeg. Mert akkor ha egyszer összeakasztottam, akkor már tőlem függ, hogy mikor küldök illetve fogadok, maximum lesz 1 pár másodperc késleltetés.. Ilyen az élet

Köszönöm szépen Srácok!

Másodperc nagyságrendűnek nem szabad lennie a késésnek. A Full Speed USB 1ms-os időszeleteket használ.

nekem nem kell full speed
legyen percenként 100 byte és sokat mondtam

Hát használhatsz low speed-et is, de a gyári programok azthiszem mind full speed-re vannak csinálva (bár ha minden igaz, csak egy bit beállításán múlik a SIE konfigurációs regiszterében, illetve a konfig biteknél a SIE órajelképzésénél kell pár bitet átállítani).



Nem muszáj adatot vinná át, de az usb host akkor is 1ms időnként szólítja meg a chipedet.

Ennyire nem akarom babrálni, kevés az idő
Azt fogom tenni, hogy felhúzok egy timert és max 1 ms-onkánt meghívom a timer interruptra az usb kiszolgáló rutint. Így mindenki boldog lesz.
Már csak az a kérdésem, hogy jól gondolom-e, hogy az interruptok úgy máködnek, hogy ha két azonos szintű interrupt kiváltó oka egyszerre, vagy egyik a másik kiszolgálása alatt teljesül, akkor a másik sem veszik el, hanem implementálástól függően az első kiszolgálása után a második kiszolgálására ugrik. Legfeljebb az interruptból való kilépés után ismét visszalép, és kiszolgálja azt is.

Ez a bitektől függ. Az interrupt egyflag bitet állít be. Ha nem törlöd a flag bitet akkor megmarad és később rá tudsz nézni újra.

A flegeket, csak a megfelelő lekezelő rutinban törlöm. De akkor jól gondoltam. Néha nem teljesen egyértelműek az adatlapok. Köszi