Majd ha már végre elkészül a teljes kapcsolás és program, akkor egy erre alkalmas Flash memóriába fogja tölteni a fogadott adatot.
De addig csak szabadon fut és ezzel tesztelem az átviteli sebességet.

Tehát a kiszolgáló rutin nem csinál mást, csak számolja a megszakításokat és a hibákat.

Ha 115200 Baud Rate átvitel meglenne már nem is lenne bajom, mert ekkor már másfél perc alatt átküldene egy 1Mb-os adathalmazt.

40 MHz: A 18F442 -nél ez a maximális órajel az adatlap szerint.
115200: A PC soros portjának sebesség maximuma. USB - Soros átalakítónál megeshet, hogy be lehet állítani magasabb sebességet is. A Bulk átvitel max 64k byte/sec körüli az átviteli sebesség maximuma. E fölé menni csak több EndPoint alkalmázásával lehetséges.

Adott, vagy mond valamit az USBview?

Csak azt hozta, amit vártam. 64 byte a bulk átvitel csomagmérete. Ehhez igazodik a programod táviratmérete.

És ez jó vagy rossz nekem?

Ha a Bulk packet hossza nagyobb lenne, mint 64 byte, akkor nagyobb csomagokat lehetett volna küldeni...

Az motoszkál a fejemben, hogy meg kellene nézni, hol veszik el az a sok idő. A PIC reagál-e lassan, vagy a PC?
Magyarul: a PIC által küldött nyugtázásra vár sokat a PC, vagy esetleg a nyugtázás, és a következő, PC által küldött adatcsomag között telik el több idő?

Hp41C-nek is megy..
Most nem értek valamit..
Pontról pontra megpróbálom összeszedni, hogyan is van, mert Hp41C bejegyzése a 64 byte csomagküldéssel kapcsolatban megzavart.
A PC egyszerre csak 1bytot tud küldeni, nem?
Vagy többet is ki tud küldeni?
Ha ki is tudna küldeni egyszerre többet PIC akkor sem tudja fogadni csak egyesével nem?

Nos a PC jelen esetben 1bájtot küld egyszerre a PIC-nek.
PIC érzékeli és beindul a megszakítás, amely semmi mást nem csinál, csak eltárolja egy 64bytos bufferbe az adatot és növel egy változót.
Beérkezik a 64 byte, PC leáll és vár PIC-re.
PIC jelenleg nem csinál semmit, de ha beérkezett a 64byte adat azt a PIC főprogram figyeli és ha a feltétel teljesül nullázza a változókat és kiküldi a jelet a PC-ének.
PC ismét elkezdi kiküldeni a 64Byte-ot egyesével, és ez ismétlődik ameddig át nem jön a teljes adathossz.
A PIC hardveresen kezeli az USART-ot, tehát elvileg maximális sebességgel kellene mennie.


PIC főprogram jelenleg csak azt dönti le, hogy az adat ami érkezik az 64byte e.
Egyetlen változót ellenőrit, így: if(datasize==64){datasize=0;}else{hiba változó növelése}
Szóval elvileg PIC nem foghatja vissza az adatfolyamot ennyire..

Azért zavarhat be Hp41C, mert gondolom nem ismered teljesen az USB-t, a gép egyszerre nem 1 byte-ot küld, ha csomag szempontból nézzük az USB-t. Hanem mindig 64 byte-os tömbökbe(csomagokba) küldi az adatot.

De nem teljesen értek egyet Hp41C-vel mert fs(15Mb/s) USB-n 1-2 másodperc maximummal át kéne menjen az adat (8Mb) csomagmérettől függetlenül (persze,ha nagyobb lenne gyorsabb lehetne de itt nem kéne hiba legyen).

A konverterben 256 byte-os buffer van ezt "ő" ahogy adat érkezik be is írja a bufferbe (ez biztos, hogy gyorsan történik). Utána már a PIC-en műlik, hogy tudja e fogadni az adatokat rendesen, véleményem szerint a software-ben lesz a bibi.

A PC -s program minden byte -ra meghívja a serialport send metódusát. A hívások zöme csak egy bufferbe tárolja a kiírt értéket és visszatér. Ha tényleges átvitelre kerül sor a kiszolgáló kideríti, hogy melyik portra, milyen úton kell kiküldeni. USB serial átalakítóról van szó. Az USB host a kapcsolódáskor kideríti a beolvasott leíró alapján melyik eszköz milyen adatpontokat kezel, milyen módon, milyen időzítéssel. Jelen esetben egy USB - CDC eszköz Bulk Endopoint párjáról van szó. Amikor a USB host kezelő érzékeli, hogy erre az illesztőre küldtek adatot, egy adacsomagot (akkorát, amekkora a packet méret, de nem biztos, hogy "teli" van) küld az eszköznek, az eszköz érzékeli, hogy a kimeneti adatpontjára érkezett adat, átveszi, beírja egy saját bufferbe és elkezdi kiküldeni a beállított sebességgel a soros illesztőjén. Ha közben jön adat, vagy átveszi és beírja a bufferbe, ha van még szabad hely, vagy nem veszi át. Az utóbbi esetben az USB host megismétli a küldést.
Visszafelé is hasonló a helyzet: A soros vonalon vett karakterek egy bufferbe kerülnek, ha a USB kommunikáció állapota lehetővé teszi, egy adagot átküld a host -nak a bemeneti endpoint -ról. A host egy bufferbe teszi a kapott adatokat. Ha érkezett adat, jelzi a serialport objectumnak. A jelzés hatására a vett (és még az azóta vett) karakterek átkerülnek a soros vonal vételi bufferébe, ahonnan egyesével ki lehet olvasni.

USB - CDC eszközzel az 1Mbyte elméletileg 1,048,576 / 64,000 = 16.38 másodperc alatt vihető át (egy pár endpointtal).

cross51-nek is megy.
Köszi srácok a kimerítő választ.
cross51: melyik SW-re gondolsz?
A PIC-ére vagy a PC-s re?
Mind kettőből kivettem minden sallangot, azon kívül amit leírtam feljebb (PIC 64byte-os csomagokban fogadja az adatot minden csomag végén kiküld PIC egy visszajelzést PC-ének és PC küldi a következő csomagot és ez ismétlődik)
PC meg csak kiszolgálja de minden sallang nélkül.

Következő kérdésem lenne.
Elképzelhető, hogy a gépem USB portjával van valami gebasz?
Gondolok itt arra, hogy egy hibás driver vagy hardveresen lassú.
Egy MacBook Air gépem van amin Bootcamp-al megy a Win7 64Bit.
Azért kérdezem ezt, mert az imént kipróbáltam asszony gépével a dolgot és bár nem maximum, de majd 2.5szer gyorsabban ment az adatátvitel.
Az is Win7 64Bit, annyi különbséggel, hogy PC nem pedig MAC.
Az ő gépén a 16356byte-os adathosszt 8mp alatt küldte át.
A 131072byte adathosszt pedig 58mp alatt.
Az előbbi 2044byte/s az utóbbi 2260byte/s ami már azért sokkal jobb eredmény mint az előzőleg mért 900körüli átviteli sebesség.

De még azért ez is nagyban eltér az eredetileg is 10Kbyte-os adatátvitelhez képest.
Valami itt nagyon nem stimmel.
De mi?

Szia
Abból, amit olvastam, én az oprendszer-USB-RS232 szakaszra gyanakszom
A Prolific féle megoldás már engem is őrülésbe kergetett, egy műholdvevő soros portját egyszerűen nem volt hajlandó rendesen kezelni. Aztán a natív RS232 porton hirtelen meg működött.
Nincs lehetőséged natív RS232 (hardveres, nem USB-n keresztül) géppel tesztelni?
Szerintem, ha maradsz az USB kommunikációnál (ebbe beleértem a Prolific USB-RS232 adaptert) akkor inkább lépj kompletten USB-re, Nem egyszerű, de nem hiszem, hogy átviteli sebesség gondod lesz.

Lehet, hogy nem vagyok teljesen képbe : akkor most már nem szimuláció, hanem tényleg hardveresen megy az összeköttetés ( USB-soros átalakítóról írsz !?) ? Ha igen, akkor miért nem nézed meg a logikai analizátorral, hogy mi megy ki ?

Igen, most már ténylegesen hardveres éles tesztről beszélünk.
És azért nem nézem meg mert felesleges.
Nem az adatokkal van a baj, hanem a sebességgel.
És nem értem miért korlátoz le, és hogy egyáltalán mi az ami lekorlátoz.
Erősen gyanakszom az USB adapterre.

Pár hozzászólással ezelőtt:

Péter: Az illesztő eredeti? melyik?

szerk: Vagy saját építés?

Linkeltem feljebb egy képet róla.
Elvileg eredeti, de mára már minden az, vagy ha nem az, akkor nem Kínai..

Erősen gyanakszom az USB adapterre. És ezt miért nem méred meg ?! A beszélgetést úgy értettem arról szól, hogy nem érted, miért ilyen kicsi a sebesség... Ha megnézed, akkor látod, hogy a PC milyen gyorsan küld, a PIC milyen gyorsan reagál, hol "lustálkodik" a progi !

Ja értem mire gondolsz.
Minden bizonnyal vagy a Driver vagy az adapter lesz a ludas, ez már szinte biztos.
Másik gépen 3szoros sebesség növekedést értem el.
Most megnézem egy másik gépen és ha minden igaz akkor lesz rajta COM port is.

Úgy is lehet !

Meg tudod mérni a PIC mennyit vár a nyugta elküldése, és a következő beérkező karakter között?
Arra már nem emlékszem, hogy milyen számítógépen, milyen USART használatánál, de az adás és vétel közötti váltás komoly időveszteséget okozott. Ezért feszegetem a várakozás idejét.
Ha sejtésem beigazolódik, akkor PC adás blokkméretét kellene megnövelni, akkorára, ami még elfér a PIC-ben. Egy próba erejéig egy több memóriával bíró kontrollerrel nem tudsz egy próbát csinálni? Ellenőrizni kellene, de egy PIX18FK4x22 durván lábkompatibilis is lehet a mostanival.

Idézet:
„Meg tudod mérni a PIC mennyit vár a nyugta elküldése, és a következő beérkező karakter között?”

Ezt javasoltam neki, de másik gépen fog próbálni !

Srácok, linkelek egy képet:Bővebben: Link
Itt jól olvasom, hogy maximum 3, vezetéket kell használnom PIC-hez, hogy működjön az adatátvitel?
2. Adat fogadás
3. Adat küldés
5. GND

Jól gondolom?
Mert egyelőre zagyvaságokat ír illetve hibákat számol a PIC

kissi, nedudgi: le fogom mérni mert már engem is bosszant.
Egyelőre megpróbálnám kihagyni az adaptert, persze ha sikerül.

Három vezeték kell minimum.
Ugye, az RS232-TTL szintillesztés megvan?

Uhh, kell szintillesztő?
Nem csak natúr bekötöttem. Nincs szintillesztő..
Akkor még sem tudom kipróbálni..
Akkor ezért az értelmezhetetlen adat..

Az RS232 jelek a GND földpotenciálhoz képest +/- nnV feszültséget takarnak. Ez hardverfüggő, de lehet akár +/- 12V is!

Laptopnál előfordulhat, hogy nem ( ott tudtommal 0-5V-os rendszert is? használnak !), asztali PC-khez kell a szintillesztő, mert ott +/--os vonali jelszintek vannak ( de akár tranzisztorral is megoldható, bár a korrekt a MAX232 ! )!

Feladtam a kísérletet, marad az USB-s adapteres továbbra is.
Sajnos a nagy gépemen, is ugyan ezt a 900körüli átviteli sebességet produkálta.
Ha lejjebb vettem a Baud Rate-t akkor meg még kevesebbet.
Asszony notián meg 3szor jobbat hoz, 3000byte/s, furcsa ez az egész..
Nem lehet, hogy USB 1-2-3 közt vacillál az adapter?
Érthetetlen..
Most kell majd elővennem a loggert.
Megnézzük mi lesz belőle..

Nem tudom egyelőre használni ezt az analizátort.
Fingom nincs mit kell és, hogy indul el a felvétel..
Hogy vesz fel?
Megnyomom a start-ot és elindítom a PIC adatátvitelt?
Gondolom a tartományt be kell állítanom nem?

Nem kell szintillesztő, mivel ez nem RS-232 kimenetű.

A DB9 csatlakozó sugallja az RS-232 szintet. A zagyva karakterek ezt megerősítik.