При 2.0
HI = 430Mb
FULL = 12Mb
LOW = 1.5Mb

При 1.1
FULL = ?? Mb
LOW = ?? Mb

Хищник - непрекъснат поток ли правиш на 3М, или мяташ пакети (пакетчета) на 3М с паузи между тях. Щото на мен ми трябва поток (1,5М).

Магьостник - няма разлика при FULL и LOW скоростите. Пак са си 12 и 1 Мбит. Предполагам че ти е ясно че това е максимална теоретична скорост. Отделно че почти няма истински HIGH чипове (2.0 съвместим не значи автоматично подръжка на HIGH).

А защо мерите максималната скорост на FTDI-то без контролер?

Контролера тук няма нищо общо,затова.
По принцип при непрекъснат поток трябва да има проверка от страна на приемника на приетото и при грешка приемника да каже на предавателя че е намерена гешка,в повечето случаи в протокола трябва да се предвиди в това съобщение за грешка да се укажев кои пакет е намерена. Значи пример за подобен протокол е
<ID на пакета><ControlSum на ID><n байта пакет><Control Sum на пакета>.................................................
В общия случаи сериината комуникация е относително бавна и не е необходимо да има време между пакетите за обработка на контролните суми.
Като не ти излезе при приемането някоя контролна сума връщаш грешка с IDto на последния вярно приет пакет за да започне предавателя наново от следващия пакет.
Така че в небходимата ти скорост на предаване трябва да се предвиди и предаването на тая допълнителна информация.

А някой можели да тества следната ситуациа за скорост
PC FTDI Controler

PC изпраща буфер(напр 64 байта) до контролер през FTDI-то,
като го приеме да го върне обратно - мах трансвер се търси в задачата

Имам функция ping в протокола си, току що пуснах един двупосочен, на 460.8Kbps в едно от устройствата си

Packets: 1000 Size: 64 bytes
OK: 1000 Bad: 0 Total: 1000
Time elapsed: 19,670 sec
Average Speed: 6,851 KB/s

Скоростта е сравнително ниска с тая която може да се получи ако не се обработваше целия пакет и от двете страни на връзката, но и това ме задоволява Резултата при 1 пакет 64 байта е 9.8KB/s В действителност има и още няколко байта които не броя (ID 2 байта, Size още 1, CS още 1, значи реално са 68 байта).

На мен препредаване при грешка не ми е нужно. Предполага се че връзката ще е качествена, достатъчно ми е да знам че има грешно предаден пакет, т.е някаква чексума ще имам. Много по критично ми е потока от данни да е непрекъснат във времето, т.е да нямам липсващи пакети. Като гледам чипа ще се справи, но шибания виндоуз ще прави много проблеми.

Ако ти върви постоянно поток от устроиството към компютъра имаш прекъсване на потока само при грешка което е много малко вероятно да стане,тоест ще се случва рядко. Ще имаш известно забавяне между момента в които изпращаш пакета и момента в които тои се получава. Но при всички положения потока ще е непрекъснат и няма да имаш загубени баитове.
По друг начин стои работата ако пращаш от компа тогава уинбозата може да направи задържане на предаването за известно време. Донякъде изход от положението е да не се оставя празен буфера за предаване които е реализиран в dll-kata. Тоест да натъпкваш нови данни за предаване преди да е изпратил предишните. Това го тествах на 2та компа дето са ми под ръка но това са бързи машини и са с XP SP2 не е много сигурно дали ще се държи така навсякъде. Но ако прекъсне за малко предаването,тоест буфера за предаване се изпразни,дори в същия момент да натъпчеш нови данни получаваш променливо времезакъснение което не можеш да го предвидиш колко ще е.

Потока е почти еднопосочен от устройството към компютъра. Притеснява ме ако бозата не намира време да изпразва буферите, да не се препълнят и да ми вдигне пина да чакам. Щото няма как да чакам.

100 процента непрекъснат поток на 1,5 мб без загуба на пакети като се компенсира вредното влияние на бозата която може да ти осигури разни закъснения до понякога и цяла секунда може да се осигури при връзка на 3 Мб и FTDI но за целта ще ти трябва доста рам в процесора с която да помниш примерно половин една секунда данни.
Ако ще ползваш подобен процесор с много външна рам мога да ти опиша алгоритъма и протокола.

Може да се реализира и с малък буфер да кажем 2 кб но вероятноста да загубиш пакет при грешка е доста голяма,зависи колко време ще мине от момента в които пращаш отговор че има грешно приет пакет с FT_Write или може с FT_SetDTR и момента в които тои в деиствителност ще бъде изпратен . Това време е много променливо и си мисля че на бавна машина или при много натоварен процесор би могло да стигне и до десети от секундата. Това време трябва да може да се покрие от буфера. Но ако не е особен проблем че някога в определен момент може да загубиш известно количество дата,като и програмата ти ще знае за загубването има и дори има опция да ти укаже колко баита са загубени можеш да го ползваш тоя метод. Ще ти го опиша ако се наложи.


Всъщност ако трябва да имаш 100 процената непрекъснат поток и се изключва възможноста да загубиш пакет и на 100Мб да ти е връзката все е тая. Проблема идва точно от момента в които намираш грешка и трябва да върнеш съобщение за грешка за да се препредадата данните. Това време от момента на командата до момента на изпращането и по usb е проблема и ако трябва да ползваш FTDI и неговите драйвери може да се реши само с много рам. Другия вариант ако е за нещо голямо и си струва е да намериш човек дето да ти напише драивер които да работи с по голям приоритет и да няма възможност за толкова големи закъснения.

Всичко зависи от това какви са ти точно изискванията. Грешка се получава доста рядко аз досега не съм има случаи на грешно приет пакет,но при непрекъснат поток не може да не се случва понякога.

Понеже лежа на кълката, че грешки се получават рядко, то на практика няма да се налага да връщам информация че има сбъркан пакет. Т.е Компютъра приема непрекъснат поток. Когато детектира грешка, достатъчно е да се знае че тая грешка съществува, и точно тези данни се изключват от обработката. Въпроса е потока да си тече. Ако се види че примерно повече от 0,5% от данните са кофти се прекратява работата и се бичи грешка - кофти връзка.

Абе става дума за едно многоканално 16 битово ацп с 4КХц честота на семплиране. Изчислил съм че само за данни, без служебна информация ще ми трябват около 1,2Мбит. С прилична доза презапас казвам 1,5.

Що не пробваш някакъв вид компресия и тогава да го предаваш , предполагам данните от ADC-то подлежат на някаква компресия.
Може да добавиш и корекция на грешки и тогава става още по добре.

С компресия надали ще получи повече от 2 пъти свиване пък и тои проблема не е в скороста на връзката а реално компресията увеличава скороста на връзката.

А щом може да си позволиш загубен пакет,направо нямаш проблем, това ще се случва много рядко.

аз бих го направил така
връзката на 3мб
в процесора 2 буфера по 128баита. почваш да четеш данни от ацпто в единия докато се напълни след което почваш да четеш данни в другия а първия го пускаш да се праща.
<старт баит > < 128byte data package > < 2 byte control sum or CRC8 >
тоест работиш с пинг понг буфер а тъи като скороста на пращане е 2 пъти по голяма от скороста на семплиране буфера няма начин да се препълни а и ще остане малко време между пакетите което ще спомогне да не се препълва буфера.
Даже и аз ще взема да направя един експеримент тия дни че ми стана интересно,може да добавя в протокола на Логическия анализатор и възможност за Поток

To Хишника:
18F550
първи стъпки
Микрочип Демо Драйвер ограничен на 64к баита/ сек
Сорс PIC = C
Сорс PC = Delphi
PING = 64 байта буфер)
трансвер = 16 кБайта/сек...

Експериментите продължават ..... :)

Мда, мерси за съветите.