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!

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.

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.

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.

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.

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?

Milyen táviratoknál jelentkezik a hiba? Sorvégjel (CR, LF) probléma is lehet.

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?

Lehet, hogy a probléma abból jön, hogy a PASCAL a string 0. elemében a string hosszát tárolja?

C-ban programozom, CCS C és elvileg annak a driverét használom, bár ezek szerint helytelenül

A PASCAL tárolja a string hosszát, a C végjelet (\0) használ.

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...

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.

Hátha ez segít

A CDC az egy virtuális soros port, kell driver.
A HID hoz nem kell driver.

É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?

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...

Így keresd!

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...

Köszönöm a linket.

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).

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.

És egy kis olvasnivaló a PC oldali HID megoldáshoz.

Bővebben: Link

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?

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.

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.

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

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.

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.

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.