A PIC-es SW-re gondoltam. De itt az utóbbiakat olvasva már nem igazán tudok semmi biztosat mondani.

Nem kell kisérletezni, 2 tranzisztor megy 4 ellenállás a konverter. Tesztnek megteszi.
Rajzot is adjak? Bővebben: Link

Egy pár dolgot azért érdemes előtte beállítani ( trigger, felvétel hossza, mintavétel sebessége, esetleg csatornák neve, kódolása ). Írtam választ a leveledre !

Köszi, akkor még nem adom fel
Később kipróbálom, csak lássuk a logikai analizátor adta infókat.

kissi: köszi, most olvasom.

Akkor bocs, én valahol elvesztettem a fonalat, még a PL2303 USB-TTL konverternél vagyok elmaradva.

No Uraim, végre sikerült beállítanom az analizátort.
Nem olyan rossz az eredmény és ki is jön az az idő amit számolok.
Összességében a PC mikor kitolja az adatot, akkor esetenként attól függően PIC éppen milyen ciklusban van, el telhet akár 0-6 milisec ami persze sok is lehet, de összességében, ha ezt ki is küszöbölném, akkor is az eredményen csak 1mp-et javítana.
Meg azt sem értem, hogy PIC mi a francot vacakol ennyit, holott semmi nincs benne, csak egy feltétel, azt meg nem hiszem el, hogy ennyi idő lenne neki kiértékelni. Régen rossz lenne.
Bár most nézem, hogy van benn egy buffer törlés is, lehet annak be is tudható az az 0-tól 6ms.

Nem szabad elfelejteni hogy jelenleg a 900 byte/s körüli adatsebességről beszélek.
Jelenleg is így fut le a program.

Csatoltam a kommunikáció készített logikai felvételt, egy képet a legfontosabb részéről, és magát a PC-s programot ami már írja az átviteli sebességet.

ui: nagy probléma, hogy PC átlagosan 1ms-onként küldi az adatot, ami nagy gond..
Gyakorlatilag 1byte/ms vagy is 16356 byte == 16356ms-al ez ez egyenlő 16,3mperccel, amihez még rájön az a kevesebb mint 2mp amit PIC tököl és ki is jön a 18mp.
Szörnyen lassan küldi PC a jelet..

Szia
Így este nekem most nem áll össze a kép.
Amit levettem eddig:
Kommunikáció USB-n keresztül egy szimulált RS 232 porton keresztül megy 115 kBps-en, azaz hozzávetőleg 10 kByte/sec, ami egy nagyságrenddel nagyobb, mint amit mértél.
Notebookon ennek a háromszorosa volt, ezért szerintem a PIC nem fékez
Nem használsz hw handshaket és xon xoff protokollt, csomagban vársz 64 byteot utána csinálsz valamit, ami gondolom szintén elég gyors.
A PC most nem vár semmire nyomja (nyomná) ami a csövön kifér ugye? Akkor a PIC nem fékezhet, mert a PC nem vár semmit sem szoftverben sem HW-ben.
Ceteum censeo: próbáld ki natív RS232-n, Ha nincs PC-n a szoftverben valami ami a PIC-re vár, akkor az adáshoz nem kell a PIC-sem. A PC gátlástalanul kinyomja a biteket, azok a nirvánába mennek és ennyi.
Ja és az RS232 a -12Von adja a logikai magas szintet, de usane adaptere (és minden ennél komolyabb is) elvégzi az invertálást.

P.S.
Amit pedig az analizátor képen látok a a következő:
Mivel a bitidő 115 k-nál 8,68 mikrosec, a TX sorban minen pálcika minimum egy byte. Minden byte között hosszú idő telik el, saccra a byteidő 10-szerese, ott veszted el az időt. Annak oka meg szerintem a PC-n belül ill. a soros-USB-soros kommunikációban van.
Ceterum censeo .... ahogy írtam

Van egy natív COM port az asztali PC-ében, de tegnap nem sikerült működést kipréselnem belőle.
Megnézem milyen alkatrészeim vannak és újra megpróbálom, már az illesztéssel.
Mint ahogyan a képen illetve az analizátor felvételén látszik a PC oldallal van a gond.
PIC szerintem elég jól adja a jelet, nyilván itt még majd az a 0-6ms még tovább fog növekedni, ha a végleges memória író rutin is a helyére kerül.

Az egyetlen amit nem értek és sajnos ezt tényleg csak egy natív COM port-al lehet kipróbálni, hogy miért nem akar gyorsabban működni az adapter.
Már mindent állogattam amit lehetett, és persze 3 különböző gépen is kipróbáltam.
Ha 115200-tól lejjebb vettem akkor lassabb volt, de ha feljebb, mert van még egy lépcső akkor nem jelentett változást és hozta ezt a 9600 körüli Baud Rate-t.
Sürgősen ki kell találnom mi a nyavalya akadályozza nekem a gyors átvitelt.

A program bájtonként ad, vagy valamekkora blokkot küld?
Minél nagyobb, ami még elfér a PIC memóriájában, jó lehet.

Bojtánkét adja az adatot.
De ha blokkokat küldök ki, akkor sem fog 10szer gyorsabban menni nem?
A PC feléről igazából mindegy mekkora Blokkokat küldök ki, szerintem?
Ha abból indulok ki, hogy PC egy string-et, hogy küldi ki, akkor az is byte-onként történik, csak a PC egy paranccsal kiteszi a bufferébe, majd onnan küldi ki PIC-nek.
Nem hiszem, hogy ez segítene, ettől független ki lehet próbálni, de a maximális átvitelhez ez a lépés csak egy szőrszálnak tűnik.

A PIC részéről azt hiszem most jelen pillanatban maximum 251byte-ot tudok engedélyezni.
E főlőt már nem fér bele a memóriába, ha csak nem módosítok a linker fájlon.
De ebben az esetben is csak max a 2szerese, tehát úgy 500byte-ot tud bufferelni egyszerre.
De kissi javaslatára maximáltam 64byte-os csomagokra, hogy ha hiba van könnyen vissza tudjon ugrani és ismételni.
És ha jól rémlik Hp41C is említette, hogy a PC is 64Byte-os csomagokban tud küldeni, bár ezt lehet rosszul értettem.

Szervusz!
Bocsi a belevauért, én is most ismerkedem a PIC-ekkel, de azért valamikor tanultam némi programozást. Figyelem a heroikus küzdelmedet, okulok belőle.

Azt azért jó tudni, hogy minél kisebb adatot küldesz át, a fogadó oldalon annál többször kell lefuttatni a lekezelő rutint. Ami, ha megszakítás is, de növeli a gépidő igényt és a lekezelésre fordított időt. Nem véletlenül találták ki a hosszú adatcsomagos átvitelt, adatkezelést máshol is. Mert ugyanannyi a szöszmötölés a hozzáfordulás, regiszterváltás byte-onként, mint hosszabb blokkonként, viszont nem mindegy hogy ez minden byte-nál megtörténik, vagy csak mondjuk 64 byte-onként egyszer.

Az a memset meg tök fölösleges. C-ben egy sor, de gépi kódban baromi fölösleges proci-idő pazarlás. Kezeld a blokkodat flag-gel (érvényes adat jelzése) és mutatóval, hosszjelzővel. És csak azt a memóriarekesz-mennyiséget kezeld így, amiben érvényes adat van, a többivel ne törődj. Nem kell leradírozni, nem papír az

Javaslom, hogy kicsit az algoritmizálást nézd át, hogy minden műveletre szükség van-e akkor, amikor és annyiszor, ahányszor. És egy utasítást csak akkor adj ki, ha akkor és ott kell. Ne máshol. Ezt alaposan a fejembe verték anno.

Köszönöm az észrevételed.
Nos a program csak azért ilyen mert tesztelési fázisban van, ezen még sok munka lesz, nem ez lesz a végleges formája, most csak az USART és az adatátvitelre koncentrálok, hogy az legyen patent, utána már lehet szöszölni a minél jobb idő kicsikarásával és a legegyszerűbb kóddal.
Egyelőre az a gond, hogy a beállított átvitel alig a 10%-ával pörög a cucc (átviteli sebesség).

Az adat küldés hiba kezelése miatt most 64byte-ra szűkítettem.
PC byte-onként küldi az adatot, de mint írtam feljebb a string-es példát, kb szerintem tök mindegy, mert ez nem lassíthatna be, legalább is nem ennyire.
De ki fogom próbálni, hátha tényleg ez a gond, bár akkor meg azt nem értem, hogy a másik gépen miért is szaladt fel 3szorosára az átvitel, a másik két gépen meg ugyan azt produkálja..

A memset-el való törlés fog kelleni, mert az adat vége lehet, hogy nem lesz pont 64byte, és emiatt a program hibásan kezelheti.
De ha nem 64byte a hossza akkor csak bejárással fogom tudni ellenőrizni, hogy van e benne adat és ha van benne akkor mennyi.
PIC szempontjából ez lényeges, mert az adatok végső helye egy memóriában lesz.
Bár persze ezen lehetne vitatkozni mert kapásból több ellenőrzés is eszembe jutott mint például, elsőnek átküldöm az adat hosszát és azt figyelem...stb

Tehát minden sallangot kerülök most és csak azzal törődöm, hogy miért ilyen lassú az átvitel.
De most utána nézek a PC-s programnak, hogy mi van ha adatblokkokat küldök ki, bár azt még egyelőre nem tudom hogy fogom megoldani, mert az, hogy elsőnek egy erre alkalmas bufferbe töltsem az adatot majd azt kiírni USART-ra az + PC-s ciklusidő veszteség lesz, minden 64byte áttöltése.
Mert ügye az adat az egyben van és elsőnek át kell töltenem egy másik bufferbe amit teljes egészben kiírhatok.

5v esetében hogy alakul a kapcsolás?
Nincs 3.3v-om, vagy számít ez valamit?

Üdv!

Nagyon nem szeretnék bele folyni a dologba, de ha ennyi baj van ezzel az adapterrel, akkor tedd be a fiók mélyére (jó lesz ez még valamire címszóval) és vegyél olyat amin biztosan eredeti FTDI illesztő végzi a dolgát. Ezt a programból a saját driverével (is) tudod kezelni, nem pedig (csak) a soros port komponensen keresztül. Így biztosan gyorsabb működést tudnál elérni.

Bővebben: FTDI

No, akkor a perifériakezelésbe is bele kéne ásnod magad, hogy is működik egy soros port.
Ugyanis ehhez kell igazítani a programot, nem a portot kéne erőszakolgatni. Ha a port a betöltött adatblokkal önállóan dolgozik (ezért van a portvezérlő), akkor hagyni kell, dolgozzon a maga módján, a beállított sebességgel. Eléggé önálló áramkör, nem kell processzoridő neki (ezért van a portvezérlő).

Tehát a lényeg, hogy egy átlátható algoritmust készíts el, egy folyamatábrát, ami pontosan azokat a lépéseket tartalmazza, amik szükségesek, tehát az alkalmazott hardverhez és képességeihez illeszkedik. Ezt hiányolom. Csak írod a programot, de jó koncepció nélkül. És az nem mentség, hogy csak "teszt". A teszt eredményének egy használható, a rendszerbe illeszkedő(!) elemnek kell lennie. Ez így, ahogy csinálod, csak vaklászás. Nem látod át, mi is történik valójában. És azt se tudod megszervezni így, hogy mi is történjen. Nem tudod a valós feladat igényeihez illeszteni.

Ez a feladatvázolás és eszközkezelési szervezés a lényeg, a kódolásnak ebből kell kiindulnia. Nem fordítva, hogy írok valami kódot egy zavaros elképzelés alapján, aztán reszelgetem....

Tehát most az a cél, hogy egy adatátviteli gépezetet hozz létre, amit a főprogramod, mint egy szerszámot, használhat, kommunikálhat vele, de mint entitás, megáll a lábán. Indítod, dolgozik, a másik oldalon meg ott az adat és aztán azzal azt csinálsz, amit akarsz.

Ha változó lehet az adathossz, az nem probléma, hanem egy eset, amit le kell tudni kezelni, ha szükséges. Rugalmasság! Leprogramozható, csak ehhez kell egy protokoll, amit meg kell tudnod tervezni. Sok-sok "mi van akkor, ha...?" kérdést kell feltenni és beilleszteni az algoritmusba. természetesen, nem feledve a feladat jellegét, tehát a kivételkezelés tényleg csak kivétel esetében történjen... Blokkokra szabdalás, küldés, majd a fogadó oldalon megnézni, hogy a blokk tényleg akkora-e, amekkora kell, ha nem (jellemzően az átvitel végén, mert nem számíthatsz arra, hogy mindig az adattömb mérete és a blokkméret hányadosa egész számot ad ki), akkor aszerint lekezelni a végét.
Lehetséges olyan megoldás, hogy a protokoll elején átküldöd az adatfolyam hosszát (össz byte, legyen mondjuk 32 biten ábrázolva előjel nélkül, 4 gigáig is elmehet)) és a kiszámított maradék hosszát (ami a blokkhosszal való osztás alapján áll elő) esetleg a várható össz blokkmennyiséget. Ez az első lépés, ebből a PIC tudni fogja, mire számítson. Nem sok idő ez. Aztán indulhat az átvitel, mivel megszabtad a folyamatot, így mindig tudni fogja mindkét oldal, hol tart a folyamatban. Aztán a PIC dolga az adatok pakolása. Mivel szándékod szerint a PIC is visszadumál, nagyon szép kézben tartható átvitelt valósíthatsz meg, mert a PC oldalon sem az agyatlan tölcsérbe töltés folyik, hanem oda tud a PC oldal is figyelni.
Arra figyelj, hogy a két oldal csak a saját dolgával törődjön, saját feladatát végezze és a "beszélgetés", folyamatvezérlés csak a szükséges esetben és módon történjen meg - protokoll!
Amit csak lehet, a PC csináljon. A PIC szorítkozzon arra, hogy vissza csak "OK - nem OK" jeleket küldjön, persze ebbe is lehet infót csomagolni, de csak annyit, amennyit kell (protokoll!). Jusson ideje a PIC-nek arra, hogy lehet más feladata is, pl. a fogadott adatok elhelyezése. Ne "éheztesd ki" a PIC-et a szabadidejéből!

A PC-t ne féltsd, nem az a szűk keresztmetszet. Jóval nagyobb kapacitással rendelkezik, mint a PIC.

Tehát: algoritmizálás, protokoll, hardverismeret... Utána lehet kódolni...

Kiemelném ezt, mert ez egy használható algoritmus nélkül esélytelen!
Mert nem tudod biztosítani, hogy az egyszerűsítés a kívánt eredményt hozza (ugyanaz a folyamat történik a "bitfaragás" után is?).
Ha jó az algoritmus, az már egy fél egyszerűsítés!

Upd: az egyszerűsítés csak arra szorítkozhat, hogy a lehetőségekből kihagyod azokat, amik nem fordulhatnak elő (pl. más adapter használata, emiatti képesség-változás lekezelése, tehát az univerzalitás csökkentése, tipizálás). Ha jó az algoritmusod, akkor azon nem nagyon van mit csökkenteni. Nem hagyhatod el a lábat, hogy kisebb legyen az egyén, ha az a feladat, hogy fusson - bár a kézen járás is haladás, csak lassú lesz ...

Szép a leírásod és komolynak is tűnik, csak egyet felejtesz el, azt hogy ez hobbi és nem vért izzadni egy-egy projekten, és főleg nem arról, szól ki mit ért is mit nem, hiszen azért teszem fel a kérdéseket mert nem értem a működést és hogy olyanoktól akik értik és együtt szeretjük ezt a hobbit segítséget kérjek, és ha tudnak segítséget adjanak.
Nem az a célom, hogy a portok lépéseit és magát az adatátvitelt minél pontosabban megismerjem, hanem hogy a hobbi iránti kíváncsiság, a megoldás elérése, ennek útján szerzett jó tapasztalat és persze nem utolsó sorban a tanulás és a végkifejletet örömmel tudjam hasznosítani.
Elhiszem, hogy szükséges lenne mind arra amit írsz, de ahhoz hogy az ember valamitől jól érezze magát és élvezze amit csinál annak nem erről kellene szólni amit írsz. (Persze ez nem is zárja ki, hogy jó tudni)
Ha ez egy munka vagy megélhetés lenne, akkor minden szavaddal egyetértenék, bár akkor is másként fogalmaztam volna.
Ha azt kéred, mutassam meg a PC-s program azon részét ami az adatküldést végzi és abba találsz hibát és ennek javítására teszel javaslatot, vagy segítesz a megfelelő kód megírásában, azt meg fogom köszönni és együtt örülőnk, hogy hú de jó, ez is megoldódott, de egy kioktatással nem segítesz max leégetsz a többiek előtt (más is vérszemet kap és csatlakozik a kioktatáshoz) és elveszed kedvem az egésztől.
Amúgy ez is szép teljesítmény egy hobbistától, hogy semmilyen előképzés nélkül neki áll egy PC-s program megírásához és persze egy hardver fejlesztéséhez illetve program megírásához. Szóval ha segíteni akarsz azt szívesen fogadom és mások is, de ha csak a kioktatás, szemrehányás a cél akkor köszönöm, de elkerülném őket..

Bizonyára igazad van mindenben, de az adatátviteli sebességet ennyire drasztikusan szerintem nem befolyásolja az én ismeretem illetve a programom esetleges hibája, hiányossága.
Annyira alap mind kettő program amennyire csak lehet, nincs benne semmi szóval a sebességnek meg kell lennie. Ameddig nincs meg legalább megközelítőleg addig felesleges ilyen magaslatokban gondolkodnom.
Mind említettem mindent ki fogok próbálni és remélhetőleg az egyre szűkített keresztmetszet megmutatja, hogy ki vagy mi korlátozza le a sebességet.

Nem a PC küldi lassan a jelet, hanem a PC programod. Dobd ki! Valószínűleg karakterenként indít USB blokkműveletet, amit 1 ms-onként tud eljátszani. A Microchip AN1310-es mintapéldájában található programletöltő és terminál alkalmazás pl. nekem jól szuperált a PICula projektben (CP2102 USB-TTL konverterrel). A Microchip MLA USB szekciójában az USB Device CDC mintapéldák mellett is vannak kiindulási alapként használható PC mintaalkalmazások.

De akkor egy másik gépen meg miért produkál 3szoros sebességet ugyan az a program?
Most nézek utána, hogy miképpen tudok kiküldeni egyszerre 64byte-ot, de úgy látom csak string-ként lehet.

Nem értettél meg. És amit tanultam, mint módszertant, ami minden programozáshoz jó, azt osztottam meg veled, megspórolva neked egy csomó töprengést, hogy mit kezdj a helyzettel...

Most hobbiból izzadsz vért... megéri? Nem megcsinálni szeretnéd jól, hanem vakarózni rajta? Nem értem.
És nem kioktattalak. Pár szempontot kiemeltem és merészeltem felkiáltójelet használni - mert fontosak. Honnan tudod, hogy a mostani megoldásod javítható egyáltalán? Vagy hogy keresel szűk keresztmetszetet, ha nincs kézben tartva a folyamat a te fejedben, átlátva, hogy minek kell történnie és mikor?
(Ha megbántottalak, nem volt szándékos. Nézd, ejtőernyőztem is hobbiból, magam örömére, és ott sem volt olyan, hogy az alapokat hanyagoljuk, csak próbálkozunk, mert ott a tévesztésnek súlyosabb kilátása volt, mint hogy nincs meg a "sebesség". Az volt rendesen. És az oktató se finomkodott... Nem szeretett temetésre járni, ki érti...)

Csak azt nem értem, miért vársz segítséget, ha nem akarod felhasználni? És nem fogom helyetted leprogramozni, mert akkor már nem hobbi lenne... Pláne, hogy te is meg tudod csinálni, eddig is eljutottál valameddig, csak elvesztél a részletekben. Nem nézem le az erőfeszítésedet, csakhogy az alapok hiányoznak (mindenki így kezdi).

Persze, hobbi, de az áramkört nem érdekli, ki nyúl hozzá, az ugyanúgy viselkedik egy hobbista és egy profi esetében is. Bármelyikük hibázik, ugyanaz lesz az eredmény. Nincs "hobbipróbálkozás-tűrő" megoldás, vagy "beginner-beállítás", mint egy játékprogramban. Sajnálom.

Inkább lépj vissza kályhához, kezd el úgy, ahogy minden programozást kezdeni kell: az algoritmizáláshoz. A sebesség nem jön magától. Erre senki se hívta fel a figyelmedet, viszont több olyan segítséget láttam, amit kaptál, amik azért nem vezettek eredményre, mert ezek a segítségek egy egész más alapokból indultak ki és az alapvető problémát nem kezelhették.

Hidd el, szurkolok neked, sőt, ha sikeres és pöpec megoldásra jutsz, akár cikket is összedobhatsz belőle, mert egy nagyon fontos feladat megoldásait tartalmazhatja. És tied a dicsőség. Megdolgozol érte, megérdemled. Nem irigylem el, hidd el. Sőt, még tanulni se szégyen számomra, tőled.

Elviseli az 5V-ot, de pl ez talán jobban átlátható számodra. Bővebben: Link
De ha rákeresel rengeteg rajzot találsz rengeteg féle tranyóval, pnp-npn megoldással stb.. Ami megy 3.3V-al az megy 5V-al is.

Én többet tanulok tőletek, ezért vagyok itt.
Nem vagyok már 20éves nehezen fog az agyam, persze nem lehet erre sem ráhúzni semmit.
Most próbálkozom a 64byte kiküldésén, de úgy látom csak string-ként küldi ki az adatot, és már az első kiküldésénél elszáll az egész.

Minden infót próbálok értékelni és felhasználni, de nem könnyű.
Egyelőre nem izzadok vért, bár tény, hogy már 1 hete csak ezzel foglalkozom.
Szépen fogok vele haladni, csak meg kell találnom a helyes utat, ami már szerintem megvan, de valamit még nem veszek észre.
És azt sem értem miért van az egyik gépen 3szoros gyorsulás a másikon meg nem...
Ezért olyan nehéz most eldöntenem, hogy az alap programom rossz (értem itt a byte-onkénti adatküldést) vagy az adapter szívat. Gondolom mind kettő.

usane: köszi, útobihoz biztosan van alkatrészem itthon.

Hidd el, amit megtanulsz itt, az másnak is jól jön! Erről szól az oldal. Ismétlem: nincs különbség a profik feladata és a hobbista feladata között, ha ugyanazt szeretnék megcsinálni. Ne nézd le a képességeidet, én se vagyok húszéves, de szívesen tanulok. Csakhogy a kisördögről és a lakóhelyéről sem feledkezem meg... És egy nagyon fontos részlet a módszer, ahogy hozzányúlunk a feladathoz. Különben Murphy bácsi jót kacag. "Mérd mikrométerrel, jelöld krétával, vágd baltával"

Leírtam, hogy a nagyobb adagokban való adatmozgatást célszerű használni, a hardverek kialakításával is szeretik ezt támogatni. Használd ki, ha rendelkezésre áll. Nem véletlenül találták ki, és nem hobbisták... De mi is használhatjuk, nem tiltja semmi.
Addig menj felfele a lehetőségek mentén, amit még mindkét oldal, a PC és PIC is támogat.

Gép és gép között van különbség, hiába papolnak a kompatibilitásról... De nem hinném, hogy a te vasadból ne lehetne többet kihozni.
Azt azért jó tudni, hogy a soros portok feszültségszintjei sem egyformák, pedig elvileg szabvány írja elő. És jó kérdés, hogy az adaptered mit kezd ezzel.

Aztán láttam olyat is, hogy elég volt a tápellátást más hálózati fázisról adni egy USB-re kötött eszköznek (dugasztápon át) és a host gépnek (PC) és szép fagyizás volt az eredmény... Ugye, a potenciálkülönbség és az általa kapacitív úton szépen átvitt zaj. Amint ugyanabba a hosszabbítóba dugtam a két ketyerét, mindjárt simán működött. De egyből gyanakodtam, mert olvasmányaim alapján tudtam, hogy ilyesmire figyelni kell.
Nálad ilyen nem állhatott fenn a különböző gépek esetében?

Utolsó kérdésedre a válasz nem, mert egy ugyan azon gépről táplálom az adaptert és a Hardvert is mint amin a program és a kommunikáció fut.
PC-s programban otthon vagy? Csharp 1012-ben írogatom a profit, de a teljes buffer kiírása nehézségekbe ütközik. Ezúttal biztosan tudom, hogy én vagyok gyenge láncszem.

Sajnos a kérdezett programnyelvet nem ismerem.

A bájtonkénti küldés/visszajelzéssel nem is fogsz nagy sebességet elérni (legalább is USB-soros átalakítóval), mert ahogy azt már mondták páran előttem 1ms ütemezéssel működnek az USB adatcsomagok, ezért az elméleti maximumod is csak 1kbájt/sec lesz. Szerintem használj akár 128bájtos buffert, és ha a bufferben van már legalább 64 bájt szabad hely, akkor szólj vissza a PC-s programnak, hogy küldheti a következő 64 bájtos csomagot.

Igen, közben rájöttem, hogy ez lesz az egyik gond.
Már gyorsult kicsit a dolog, de még PC-én kezelnem kell az adat végén lévő 64byte-tól kisebb maradékot.

64byte-s bufferrel elég nagy növekedést értem el.
Azt hittem ez nem számít, de nagyot tévedtem, lehet ez volt a gond és ezek szerint a PC-s programom volt a hibás mint ahogyan azt többen is említették.
Nyilván, ha emelem a buffer-t akkor még gyorsabb lehet.
Úgy számolom ha 2 szeresére emelem a buffert, akkor majdnem elérem a 115200 Baud Rate beállítást.

Helosztok.
18F4550 ben elvileg van hardveres szorzó. Ha én c18 ban összeszorzok két számot, akkor a fordító ki fogja használni ez a lehetőséget alapból, vagy valahogy külön be kell kapcsolni? Vagy esetleg saját szorzó rutint kell írni?