Да поддържа isocronous трансфер ама няма драивер с които да работи в тоя режим.
Деиствително има такава емулация и работи, Flow Control се води и трябва да се разреши за да тръгне,има си команда в dll-a. Направих го така, проверявам си нивото на RTS и спря да се омазва като се препълни буфера . Но резултатите не са добри. Успях да направя поток 350000бит/сек на връзка 1000000
и 380000бит/с на връзка 2000000.
След като няма особенно значение това че вдигам двоино честотата на връзката с процесора означава че това е максимума.
Това е само полезната информация,служебната не я включвам в сметките.
Имам формат <1byte start> < 2 byte ID package > < 256 byte data > <2 byte control sum >
Самия flow controll и той ползва някакъв трафик явно щото с него трансфера е по малък.

Чат пат допуска и грешки да кажем в на 10 минути 5-6 грешки.
Това е максимума които може да се изсмуче с dll-a.

Спопед мен за твоята цел е неподходящ тоя чип. Поне не и с със стандартните драивери.

Всъщност може да ползваш един трик да намалиш необходимия ти пакет. Правиш пакет по големичък да кажем към 512 баита. в началото на пакета предаваш пълната стоиност на всичките ацп - та а след това до края на пакета предваш в няклоко бита само насъпилата промяна от предишното замерване. Така може да смъкнеш необходимия трансфер доста но то пак е в зависимос доколко бързо се променят измерваните сигнали ако в периода межфу 2 замервания промяната може да се опише в 4 битова стоиност при 10 битова стоиност това ти смъква необходимия поток над 2 пъти.

Мерси Никола, това беше полезен тест. И идеята ти е добра и преди мислех върху това да пращам само разлика, но не ми беше хрумвало да сетвам базата в началото на пакет. При 4 Khz честота на семплиране измененията в 512 байта данни (от 16 канала) може и да са само в младшата част. Трябва да го проверя. Като тръгне усилвателя ще го знам това.

Цецо, можеш да предаващ не най-младшите, ами само някои по-средни битова, а най-малките 1-2 .. няколко да ги игнорираш. Това е с особена сила за сигма-дялка ADC. Там тези битове изобщо не са верни, обикновено ги слагат само от куртоазия.

Абе ясно ми е че шикалкавят най дребните. Ама нали се води че правим 16 битов модул, някаква спецификация трябва да покрия, не върви да ги отрежа и да викам - ами те и без това не ви трябват.

Имаш късмет Цецо.
Последните експерименти са 1,3Мбита/сек полезна информация. Съвсем стабилна работа,ето сега съм го пуснал на една малка машина на 600Мхз и трансфера си върви и аз си човъркам по компа пускам разни програмки товаря го.
По едно време бях пусмал едим рар архив да се прави и бях отворил заедно с това и един документ с акробата и поне 3-4 минути бях хванал страницата и я размотавах по екрана,един баит не пропусна гадината.
USART-a е на 2Мбода. значи ако го пуснеш в паралелен режим FTDI ще може да вдигне още поне 30 процента.
Оказха се няколко проблема.
1 Значи бях инсталирал драиверите дето си вървят с M-PROG абе работи си всичко ама понякога грешки при голям поток се омазва. Качих тия от саита последна версия и се пооправи положението малко. Но MPROG не работи .
2-ро FTDI се дразни от 4м китаиски USB кабел. Сложих марков /вероятно пак китаиски ама за 14 лева / и скороста скочи над 2 пъти и на мощната машина на 3 ГХз почна да работи като кукличка. Но на 600 негахерца на всяка секунда по една грешка поне.
3.Оказа се че нещо съм направил предаването от ATmegata много неоптимално и като го оправих да пуска нова стоиност в USART-a веднага след като се вдигне флага че е готово предаването се дигна още малко скороста.
4.В dll-a има команда за големината на буфера които ползва, слагаш на 16к/0к и всичко заспива и на малката машина.
това 16к експериментално го определих дори на малко повече се омазва страшно,под 10к пак прави грешки. Out буфера един господ го знае за какво е но e по добре не се променят нещата ако слагаш друга стоиност различна от 0 ,само към по зле се променят нещата.
Буфера в които прехвърляш приетите данни /когато четеш/ не знам защо но при по малко от 64к се омазва програмата понякога. Предимно като е натоварен с нещо друго процесора.

Не знам от коя от всичките промени но накрая Flow Control не дава признаци че съществува и последните експерименти дето ги описах са правени без него тоест връзката е по 2 жички само.

Тоя проблем с MPROG и dll го имах и аз преди време със старите драйвери, ама при мене не беше поток и се усираше и на малки пакети с големи скорости, освен това има още една опция за времето за опресняване на буфера на FTDI - FT_SetTimeOuts, при мене има ефект при по-високи скорости.

То не е точно време за опресняване, но него по начало съм го сложил 2мс и не съм го пипал. За проба го бях увеличил по едно време но нямаше ефект. То има значение като работиш с къси пакети най вече.

Мерси, мерси.

Три години по-късно...
http://www.ftdichip.com/Products/FT2232H.htm
...порасна му работата на тоя FTDI.

Ей малък дзвер е това.

Само що в тоя избушен корпус бе.... Вече няма да е любимец на направи си сам гилдията.

The FT2232H is available in Pb-free (RoHS compliant) 64-pin LQFP and QFN packages.

Ядва се, бе!

е ако има паяк убаво. Щото на картинката видях един убавец с термална площадка отдоле....

На Електрониката като ги питах казаха, че първите мостри ще ги има след Нова година... да видим

Е то реално нуждата от такива чипове като цяло е малка. Обикновенно който гони high-speed търси директно интегрирано решение към шината защото това чудо, без яко DMA си е просто безумие.