Цецо имам лоши новини за теб.
Всичко е добре докато се работи с пакети. Но като става дума за непрекъснат поток работата се омазва. Оказа се че dll е много тромав.
Експериментирах с поток 1мб. Направих си тред в програмата които да се занимава единствено с проверка на пакетите и да праща съобщение при грешка. Но се оказва че се препълва някакъв буфер които ползва dll kata и трансфера се прекъсва за доста време през което FT_GetStatus, FT_Read връщат грешка.
Давах му и наи голям приоритет на треда но положението се пооправи съвсем малко. Забива селед минута две.
Явно трябва да се работи през FT-Win32 API Functions. Не си губи времето с dll-a.

Ами аз със програмирането под бозата не съм много наясно. Друг ще се занимава там. Но някакси усещам, че точно това ще се случи, просто бозата не е правена за такива дейности. От друга страна не може да няма начин. Ще пробваме.

Другата седмица към края ще имам време и ще го направя и с FT-Win32 API функциите и ще ти кажа дали става. Но като се ползва dll-a непрекъснат поток постигнах като свалих до 650кб и това на интел на 3GHz,не съм пробвал как е на по бавна машина.

Определено няма да се справи на бавна машина, със моя thread управление на LCD от Nokia гълтам 25% процесор като пращам на всеки 100мс пакети по 100KB на 3Mbps

През FT-Win32 API или през dll-ката работиш? Нещо тоя dll много тромв изглежда да е.

През DLL-a говоря, с API-то не съм пробвал, не вярвам да има особена разлика Встщност трябва да проверя и аз със поток, не вярвам да има някви проблеми. А едно време бях споменал че има 32KB буфер във FTDI драйвера, с това също трябва да се съобразявате като пишете потока. Още нещо, незнам точно как го правите, но според мен правилния начин е да изпращате някакъв пакет 32KB и докато се изпраща да проверявате дали е дошъл края на изпращането, след това да пращате следващия пакет

Не разбрах идеята ти. Как да провериш че предишния пакет е изпратен вече? имаш пред вид като получиш пакета да пратиш потвърждение че е получен ли?

Амиииии, какво да ви кажа за 18F_USB
max 800 кбайта/сек
ном 400 кбайта/сек

премерено така:

T = (Get System tyme in mSec)
FOR i = 0 to N
SEND(64 byte bulk buffer)
READ(64 byte bulk buffer)
ENDFOR
T = T - (Get System tyme in mSec)
Transfer = (i * 64) / T * 1000 Byte/Sec

--> to TheWizard

От кога прописа на BASIC ?

Беее не пиша на Базик бриа - тук са почудих как да обясна как съм мерил скороста, на Делфи е ехе-то
Това е "маг" алгоритъм :)

OK, много е хубаво че имаш такъв трансвер....айде кажи ми как ще обработиш 400KB/s с PIC

Говорим за истинско USB... а не за FTDI
При него(USB) мах пакета при булк трансвер за 1 таск е 64 байта
Обработваш си 64 байтовото пакетче а не големия пакет

Toва FTDI много ви бърка да знаете

Добре съм запознат с работата на USB, аз като го ползвам търся не толкова някакъв огромен трансфер, а нещо по-удобно от COM порта... Казах ти че съм за PIC18_USB-то, нямам време да се занимавам досега с него, подхванал съм USB-то на Atmel-ски ARM7....

Аз също не търся огромен транвер - просто издух ПИКа да видя как се държи и какви са му възможностите и се оказва че за нормална "по-удобно от COM порта" комуникация се справя...

Е аз търся баш огромен трансфер. Е огромен е според мойте разбирания. Какво ще ми препоръчате като алтернатива на ФТДИ. От към контролера не ме притеснява, но във писането на драйвери хич ме няма, а ФТДИ-то вървеше с доста голяма част от софтуера - готова.

Както казах вече имам 13 канално 16 битово АЦП на 4 кХз. Данните трябва да влизат в реално време в компютър, да се визуализират (едно към гьотере) и да се натрупват на диска.