Много относително зададен въпрос
на теб какъв ти е потока данни(скорост,обем...)

Ами много грубо сметнато 13канала*16бита*4кХз = 832кбита, чисти данни, без нищо служебно. Това е непрекъснат поток, т.е. пусната системата работи примерно 1 час без прекъсване - текат си на екрана данните и се схраняват на диска.

Цецо, това е доста трансфер... моите екперименти (18F4550) че тоз PIC едва ли ще се справи с тази скорост
FTDI - изключено...
За USB - май ще ти трябва HI-SPEED

Козата си сака пръч!

Може би едно разумно решение ще е нещо с повече RAM за буфер и/или Ethernet контролер. Това ще се справи дори и под W XP. Забавянето едва ли ще е повече от няколко секунди, една SRAM 512k*8 ще поеме 5 секунди проспано време, а не струва баща си и майка си. А по-бърза връзка от LAN засега няма ( от лесно достъпните ). Лошото е, че на мога да ти дам конкретен жокер, не съм се ровил в тази материя.

Разбрах го де му е проблема на FTDI с потока. Като се препълни хардуерния му буфер тогава се омазва. А аз си мислех че е от страна на PC-to. Четох пак pdf-a но не виждам как да проверя дали не е пълен. Цецо погледни го ако искаш и ти ако намериш начин да се проверява това ще стане работата. Засега постигнах стабилно работещ поток на 600кбита.

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

Много куцо

SPEED

Мда, ама не. Според тая таблица и Low Speed би трябвало да ми върши работа, а ти ме убеждаваш че и Full Speed няма да ме огрее, та да гледам към High Speed.

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

Мрежата е решение. Само дето пропуснах да отбележа, че се нуждая и от галванична изолация, което просто не виждам друг начин освен да стане през UART.

Продължавам да си мисля, че едно FULL SPEED устройство би трябвало да се справи с прост трансфер от около 1,5Мбита. Е май няма да е FTDI, най-малкото защото никой не знае какво става във вътрешните му буфери.

Но при всички положения, остава проблема с бозата.

@Цецо, не си прав.
"Мрежата е решение. Само дето пропуснах да отбележа, че се нуждая и от галванична изолация, което просто не виждам друг начин освен да стане през UART."
С мрежа се прави разкошна галванична изолация - там са само 2 трафчета, като тези дето са в защитите от гръм по LAN-а. Лошото е, че не знам как стои въпросът със сертифицирането им. Но все някъде се продават и сертифицирани.

Е нали знаеш с какво си вадя хляба. Едва ли мрежовите трафчета са сертифицирани за някакви си 4 киловолта. Оптрони му е майката. То така или иначе отиваме на два контролера. Един да обслужва АЦП-то и един дето да обслужва връзка с ПЦ. Между двете високоскоростен UART. А дали ще е мрежа или USB? Знам ли? За начало мисля да го пусна с FTDI с орязан брой канали/честота та да се уверя че аналоговата част работи, защото честно казано трансфера все някак ще стане, ама усилвателя не е никак прост.

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

Цецо - сорри ама не съм прочел правилно 832кбита - помислих че е кило байта - става с USB full
Значи 832кбита са приблизително 84 кило байта - PIC 18F4550 ще ти свърши работа както и добре обмисленo FTDI paralell

TheWizard каква е разликата в случая между паралелния и серииния режим на FTDI. Проблема идва като се препълни хардуерния му буфер статуса на които и в двата режима не може да се види. Сега пак гледах за паралелния режим но и там не виждам начин да провериш дали буфера му е пълен. Или съм пропуснал нещо?

Никола, абе по принцип CTS сигнала не върши ли точно това? Щото май точно това му беше идеята. Кат е 0 пращам, иначе си трая. Логичното би било, препълването (по скоро напълването) на буфера, да забранява трансфера. Нали това е смисъла на Handshake-a. Друг е въпроса защо този буфер се препълва - дали защото FTDI не съумява да препрати данните, или защото бозата отказва да ги поеме, или защото има грешки по линята и се препредават. Апрпопо, какъв тип трансфер използва FTDI - Isochronious или Bulk?

Ще ме насочиш ли къде в пдф-а е написано това за CTS-a да го разгледам по внимателно.
А за типа на трансфера е bulk + timer. значи системата с timet-а е че ако заредиш в буфера по малко от дължината на bulk-a след изтичане времеинтервала на таимера пакета се праща като се допълва до дължината на булка а в последствие това което е допълнено до пълен пакет при приемането се отрязва.

Хм, къде го пише?

Ами никъде, той дата шеета на тоя чип е доста оскъден. Извадих го от контекста. Но пише че подържа Hardware Handshake. Тъй като тоя чип се води че предлага пълна емулация на модемен интерфейс, то CTS (Clear To Send)сигнала би трябвало да прави точно това - когато чипа/PC не е в готовност да приема данни, чрез този сигнал забранява модема. Обратното също би трябвало да е валидно, чрез RTS микроконтролера би трябвало да може да сигнализира на PC-то, че не може да преглътне (това обаче мен не ми е болка). Заблудил съм се че пише, тъй като работя с един чип който е горе долу същото, но върху IRDA. И там CTS - а сигнализира точно това - вътрешните буфери (или тези в ПЦ-то) не могат да поемат повече - СПРИ.
Интересно е да се види дали ако види зор с данните чипа клати тоя пин. Би следвало да се случва и когато не изпразниш буфера в ПЦ-то, оттам ще се напълни и тоя в чипа и би трябвало да сигнализира чрез CTS=1. Аз поне така бих го направил, ако проектирам такив чип, тъпо е да няма индикация.
За съжаление нямам познания в програмирането под Windows, за да пробвам тая ситуация. Човека който ми пишеше хвана за Канада. Новия още не е съвсем в час.

Навсякъде говоря за FT232BM, да не стане грешка.

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