Fórum témák

» Több friss téma
Fórum » PIC - USB - PC projekt
 
Témaindító: JohnyBravo, idő: Szept 26, 2006
Lapozás: OK   54 / 55
(#) shirke hozzászólása Máj 6, 2018 /
 
Sziasztok!

Egy dspic33ep256mu806-os uC-vel szórakozok és az volna a cél, hogy CDC-vel adatokat küldjek a PC felé. Viszont időnként egy-egy bájt elveszik és az adatok nem abban a formátumban érkeznek meg ahogy küldtem. Az adatokat viszonylag sűrűn 40-100ms -onként kellene kiolvasnom és előfordulhat hogy 4kB-os pakkokat kellene továbbítani.
Találkoztatok már hasonlóval, tudnátok adni valami tanácsot, hogy az adatok ne vesszenek el és sorrendhelyesen érkezzenek meg?
Fordítónak CCS C-t használok.

Üdv!
(#) Elektro.on válasza shirke hozzászólására (») Máj 6, 2018 /
 
Szia!
Én 18F14K50 -el használtam USB -t MikroPascal környezetben. De én nem játszottam CDC -vel. Inkább USB HID mellett döntöttem. Nem kell drivert telepíteni, egy adatom sem veszett el 12 megabit/sec. Másik nagy előnye, hogy a felhasználónak nem kell port számot választania csatlakozáskor. Meg lehet úgy írni, hogy autómatikusan csatlakozzon a program az eszközhöz.
Lehet, hogy neked is egyszerűbb lenne ez a megoldás.
A hozzászólás módosítva: Máj 6, 2018
(#) Hp41C válasza shirke hozzászólására (») Máj 7, 2018 /
 
Idézet:
„... Viszont időnként egy-egy bájt elveszik...”

Ráfutáskor (ha a következő adat beérkezéséig nem olvassuk ki az előzőt / nem marad hely az UART fifo -jában) a hibát le kell kezelni, az UART egységet ki kell kapcsolni és vissza, a hibás karaktert el kell dobni. Lehet, hogy azon a típuson van már egyszerűbb módszer is.
Másrészt az UART vételt megszakításosan kezelni, a lehető legrövidebb kóddal. a hibákat lekezelni, az adatokat egy megfelelő méretű pufferbe helyezni. Az adást is egy pufferrel kell megoldani.
Kellően nagy pufferekkel a 64 ms alatt menne a 4k (64*64) byte átvitele.
Rendesen működik a Microchip CDC drivere (Win12 64-bit alatt is) egy 16F1455 -tel.
A hozzászólás módosítva: Máj 7, 2018
(#) icserny válasza Elektro.on hozzászólására (») Máj 7, 2018 /
 
USB HID estén 64 bájt/1 ms a maximális adatátviteli sebesség. Shirke kollégának pedig ennél több kellene (akár 4 kB/40 ms, ha jól értettem). USB CDC-vel sem egyszerű ezt megoldani, mert biztosítani kellene, hogy az 1 ms-os keretekbe egynél több 64 bájtos csomag kerüljön bele.

Nem akarok hülyeséget írni, de azt hiszem, hogy a kívánt sebesség a standard usbser.sys meghajtón alapuló kommunikációval nem fog menni. Az FTDI, Prolific vagy SiLabs eszközök is saját meghajtót használnak a nagyobb átviteli sebesség biztosítására. Microchip eszközöknél bulk módban a Winlib vagy usblib adja a legnagyobb teljesítményt (az MLA tartalmaz mintapéldákat hozzá), de az már nem USB CDC mód.
A hozzászólás módosítva: Máj 7, 2018
(#) Elektro.on válasza icserny hozzászólására (») Máj 7, 2018 /
 
Hát látod, igazad van. Nem számoltam utána.
Amúgy valóban a Bulk mód gyorsabb lehet a sima 64 Byte/1ms nél. De ezzel még nem próbálkoztam.
(#) shirke hozzászólása Máj 7, 2018 /
 
Igazából 40 kbájt/s-os sebesség elég, csak bufferelés miatt kell sok adatot kuldeni, ha nem olvasom ki sűrűn.
Viszont tegnap felfedeztem, hogy valahonnan a soros terninálon érkezik még 7 bájt, és az az érzésem hogy ez borítja meg a beérkező bájtok sorrendjét. Aztán felfedeztem hogy ha folyamatosan küld egy-egy bájtot, nem pedig mondjuk egy beérkező karakterre válaszol a uC akkor nem piszkít bele azzal a 7 bájttal.
Van ötletetek hogy ez minek tudható be?
(#) Hp41C válasza shirke hozzászólására (») Máj 7, 2018 /
 
Milyen táviratoknál jelentkezik a hiba? Sorvégjel (CR, LF) probléma is lehet.
(#) shirke válasza Hp41C hozzászólására (») Máj 9, 2018 /
 
Teljesen random. Mindig az a karakter előtt amit külden akartam és 0x32 körüli értékek.
tudtok javasolni valami USB analizátor programot amivel leellenőrizhetem hogy milyen úton érkeznek ezek?
(#) Hp41C válasza shirke hozzászólására (») Máj 9, 2018 /
 
Lehet, hogy a probléma abból jön, hogy a PASCAL a string 0. elemében a string hosszát tárolja?
(#) shirke válasza Hp41C hozzászólására (») Máj 9, 2018 /
 
C-ban programozom, CCS C és elvileg annak a driverét használom, bár ezek szerint helytelenül
(#) Hp41C válasza shirke hozzászólására (») Máj 10, 2018 /
 
A PASCAL tárolja a string hosszát, a C végjelet (\0) használ.
(#) matheattila válasza shirke hozzászólására (») Máj 14, 2018 / 3
 
Kissé megkésve de lehet még hasznos lesz. Én az USBlyzer nevű progit használtam néhány évvel ezelőtt eszköz azonosítására, descriptor lekérdezésére...
(#) cs_gabor hozzászólása Júl 23, 2019 /
 
Szeretném megkérdezni, PIC24-ből készített CDC eszköz esetén szükséges valamilyen driver a Windows-ra, vagy felismeri automatikusan mint pl. HID vagy MSD esetén?
Köszönöm a válaszokat előre is.
(#) pipi válasza cs_gabor hozzászólására (») Júl 23, 2019 /
 
(#) Elektro.on válasza cs_gabor hozzászólására (») Júl 24, 2019 /
 
A CDC az egy virtuális soros port, kell driver.
A HID hoz nem kell driver.
(#) cs_gabor hozzászólása Júl 24, 2019 /
 
Értem, köszönöm az információkat.
A megadott linken azt írják: "The CDC driver itself is built into Windows. The INF file just tells Windows to use it." vagyis magyarra fordítva (google...) A CDC-meghajtó maga a Windows-ba van beépítve. Az INF fájl csak azt mondja a Windows-nak, hogy használja. Erről lehet valamit tudni, hogyan épül fel az inf fájl, illetve PIC esetében mit kell tartalmaznia?
(#) pipi válasza cs_gabor hozzászólására (») Júl 24, 2019 /
 
Azt is olvastad ugye hogy melyik win-ben van benne...
A Microchip oldaláról ha letöltöd az app. libeket abban szerintem benne van. Az inf fájl sima text fájl, belenézegethetsz, de nem akarod szerkeszteni.... Benne van az usb vid/pid azonosító, és hogy a használathoz milyen driverek, dll fájlok kellenek, ne írd át a programodban ezeket...
---
használd a Válasz gombot...
A hozzászólás módosítva: Júl 24, 2019
(#) Hp41C válasza cs_gabor hozzászólására (») Júl 24, 2019 /
 
(#) cs_gabor válasza pipi hozzászólására (») Júl 24, 2019 /
 
Idézet:
„Azt is olvastad ugye hogy melyik win-ben van benne...”
Másodszorra igen... Tehát Win7, 8 esetén szükséges a telepítés. Első körben nem akarom szerkesztgetni, bár most, hogy említetted, jó lenne (ha lehetne) átnevezni a COM portok listában a vélhetően valamilyen "usb-seria com port" névűről az általam illeszteni kíván eszköz nevére, de ennyire nem akarok előre szaladni...
(#) cs_gabor válasza Hp41C hozzászólására (») Júl 24, 2019 /
 
Köszönöm a linket.
(#) pipi válasza cs_gabor hozzászólására (») Júl 24, 2019 /
 
Két helyen "kell" átírni, a forrásszövegedben adhatod meg, hogy mikor először feldugod, mit írjon ki, másodszor az inf-ben, hogy az eszközkezelőben hogy látszódjon (emlékeim szerint).
(#) Elektro.on válasza cs_gabor hozzászólására (») Júl 24, 2019 /
 
Nem gondolkodtál azon, hogy CDC helyett HID -at használj?
Én pár hónapja készítettem a kolégáknak olyan eszközt, ami ha USB -n rá van dugva a gépre és fut a programja PC -n , autómatikusan csatlakoznak egymáshoz.
A hozzászólás módosítva: Júl 24, 2019
(#) Elektro.on válasza cs_gabor hozzászólására (») Júl 25, 2019 /
 
És egy kis olvasnivaló a PC oldali HID megoldáshoz.

Bővebben: Link
(#) cs_gabor válasza pipi hozzászólására (») Júl 25, 2019 /
 
Igen, ez jó ötletnek tűnik, délelőtt az inf állománynál megpróbáltam, és valóban azon a néven látszik a telepítést követően
A forrásszöveg alatt mit értesz pontosan?
(#) cs_gabor válasza Elektro.on hozzászólására (») Júl 25, 2019 /
 
Idézet:
„CDC helyett HID”

Első körben nekem is ez jutott eszembe, de aztán tovább olvasva (itt a fórumokban is írják) derült ki még időben, hogy 64kB/s a max. sebesség. Commodore Amiga és PC között szeretnék egy a soros porton elérhető kb. max. 11kB/s-nál gyorsabb és a mai kornak megfelelőbb USB-n keresztül működő fájl-transzfert és jó volna minél nagyobb (akár 150-200kB/s) sebességet elérni.
A hozzászólás módosítva: Júl 25, 2019
(#) Elektro.on válasza cs_gabor hozzászólására (») Júl 25, 2019 /
 
De azzal tisztában vagy , hogy itt az a "B" nem bit hanem Byte ? (12Mbit)
Gyakorlatilag 1ms időközönként küld oda 64Byte adatot (64*8bit) és ugyan annyit vissza.
Ennyit a soros portból nem hozol ki. Ezen kívül ami még ott van és én nem próbáltam a HID Bulk Transfer módja.
(#) Hp41C válasza Elektro.on hozzászólására (») Júl 25, 2019 /
 
Az USB CDC osztály nem Interrupt hanem Bulk transfer móddal működik. A sebességet már az fogja korlátozni, hogy az átviendő adatot a PIC milyen gyorsan tudja beírni a bufferekbe...
Bővebben: Link
(#) cs_gabor válasza Elektro.on hozzászólására (») Júl 25, 2019 /
 
Igen, 64 Byte * 1000, így számoltam a 64kByte/s-ot. Nem rossz, jóval magasabb már ez az érték is mint a 11kByte/s de nem tudom a soros-párhuzamos átalakítással mennyit veszítek, mennyit lassít az átvitelen ezért gondoltam minél nagyobb sebességre.
HID Bluk módról nem hallottam, körülnézek, köszönöm.
(#) Elektro.on válasza Hp41C hozzászólására (») Júl 25, 2019 /
 
Hmm. Ez most elgondolkodtat. Bár szerintem az esetében az Amiga és a PC közt ez neccesen fog ennyivel menni.
Ennek ellenére én maradok a HID -nál mert a sebessége nekem bőven elég, és talán felhasználó barátabb. Megoldhatom a hardware és a software autómatikus csatlakozását. Nincs driver telepítés és portválasztás.

De azért megnézegetem mit lehet ebből kihozni. Igazság szerint én egyből a HID -al kezdtem, CDC kimaradt.
(#) cs_gabor válasza Hp41C hozzászólására (») Júl 25, 2019 /
 
Jelenleg egy PIC24FJ256GB106-ossal próbálkozom, első körben ESP8266-os illesztés volt tervben (és alapvetően működik is) emiatt 29,4912MHz-en járatom, a soros kommunikáció 921600-en ment (próbaként 1,8432MHz-et is próbáltam, sikeresen) így szoftveresen megszakításból bírta az RX regisztert tárolni a SRAM-ba, de sok utasítás nem fér bele ha másodpercenként 92160-szor meghívódik. Sajnos a típus kiválasztásakor nem néztem, hogy ebben van-e DMA és természetesen nincs, pedig nyilván segítene, hiszen az ellenoldal (Amiga clockport )PMP-n keresztüli kiszolgálását is szoftveresen tudom így megoldani. Az USB mellett szólna a WiFi-vel szemben a kisebb latency és, ha jól olvastam az USB támogatva van DMA-val ebben a chipben is.
Következő: »»   54 / 55
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu