Проблемы с обменом по USB... Опции

[Ostec]

Принимаю данные по USB используюя контроллер-USB FT232BM (www.ftdichip.com), но получаю рваный поток с пропадающими пакетами, пакет в данном случае - это озаглавленный мной блок данных.
Кто работал с этим подскажите как заставить его принимать данные без пропусков и потерь? С другой стороны загоняю в него данные со скорость 1.5 или 2 Мбит/сек.

[Vic]

К сожалению не могу Вам помочь, но по адресу http://www.efo.ru/doc/Ftdi/Ftdi.pl?640#11012005 очень много информации по данным микросхемам и статьи по применению, может окажется полезным.

[khach]

Принимаю данные по USB используюя контроллер-USB FT232BM (www.ftdichip.com), но получаю рваный поток с пропадающими пакетами, пакет в данном случае - это озаглавленный мной блок данных.
Кто работал с этим подскажите как заставить его принимать данные без пропусков и потерь? С другой стороны загоняю в него данные со скорость 1.5 или 2 Мбит/сек.

Это в какую сторону? Если из компа в устройство, то через какие драйвера работаете( виртуал СОМ или direct)? Если из устройства в комп, то что на линиях квитирования, как flow control отрабатываеться и какая длина пакета ( переполняеться ли внутренний буфер передачи микросхемы)? Каков битрейт порта? Справляеться ли с ним UART микропроцессора? Или это просто логическая петля? Тогда уреж осетра - в одну сторону с FTDI можно выжать 700килобайт в секунду, но в две- только килобайт 300. Это все скорости записи-чтения во внутренний буфер. Реально их можно получить только на FT245 при параллельной шине. И вообще, как в 232 можно запихнуть 2 Мбит/сек?

[Ostec]

Передаю данные по RS232 со скоростью 2 Мбит/сек в контроллер USB FT232BM, и далее хочу передать эти данные в комп. Передача осуществляется в одном направлении, от компа в FT232BM, никогда ничего не передается, flow control не применяется, посылка состоит из 10 байт (RS-232, 2 Мбит), потом пауза порядка половины посылки, посылка 10 байт, пауза и т.д.
В PC пользуюсь direct driver (D2XX), а не виртуальным COM. Поток ориентировочно - 150-200 кбайт/сек. У меня возникло желание поиграться с размером буфера и задержками, как описано в родных AppNotes, но пока результат не достигнут...

[one_man_show]

Передаю данные по RS232 со скоростью 2 Мбит/сек в контроллер USB FT232BM, и далее хочу передать эти данные в комп. Передача осуществляется в одном направлении, от компа в FT232BM, никогда ничего не передается, flow control не применяется, посылка состоит из 10 байт (RS-232, 2 Мбит), потом пауза порядка половины посылки, посылка 10 байт, пауза и т.д.
В PC пользуюсь direct driver (D2XX), а не виртуальным COM. Поток ориентировочно - 150-200 кбайт/сек. У меня возникло желание поиграться с размером буфера и задержками, как описано в родных AppNotes, но пока результат не достигнут...

Сдается мне, что при работе без квитирования нужно однозначно обеспечить непереполнение буфера, для этого либо уменьшите 2МБ поток, либо увеличте скорость в СОМ, там Вы указали 150-200 кбайт/c, т.е. при параметрах 1,8,N,1S получите ровно 2МБ, а нужно с запасом порядка 5-10%.
Самый простой способ проверить правильность функционала, понизте скорость потока с 2МБ до 1МБ, а в выходном горле скорость не меняйте.

[khach]

Рекомендую включить RTS/CTS flow control и посмотреть осциллом в режиме ждущей развертки. Если RTS будет дергаться- это буфер переполняеться. Лечиться шаманским бубном, вплоть до смены компа ( материнской платы). Бывало FTDI выделывалось на USB2 контроллерах- воткни в честный USB1.1 и проверь симптомы.
Еще один вариант- тк FTDI построено на ядре 51 конроллера, то он просто неуспевает выгребать байты при приеме из UART. Поставь ДВА стоп-бита- это даст небольшую задержку между байтами.
Еще проверь фронт стартового бита (длинные провода, прохой драйвер)- если он завален, то UART может просто незапускаться. Лучше выкинь вообще формирователь RS232 уровней со стороны тестового сигнала (если он есть).
А вообще FT232 для таких скоростей приспособлен плохо. Или переходи на параллельную шину (245) или делай связку из внешнего UART и микроконтроллера с USB. Мы когда- то подобную проблему решить не смогли (правда это было на FT232AM) и сделали связку AN2135 (Cypress) и TI16c550 (UART с FIFO). При этом AN2135 грузился из serial eeprom и эмулировал полностью протокол FT232AM на USB т.к менять драйвера на компе было уже поздно.

[Вилли]

Передаю данные по RS232 со скоростью 2 Мбит/сек в контроллер USB FT232BM, и далее хочу передать эти данные в комп. Передача осуществляется в одном направлении, от компа в FT232BM, никогда ничего не передается, flow control не применяется, посылка состоит из 10 байт (RS-232, 2 Мбит), потом пауза порядка половины посылки, посылка 10 байт, пауза и т.д.
В PC пользуюсь direct driver (D2XX), а не виртуальным COM. Поток ориентировочно - 150-200 кбайт/сек. У меня возникло желание поиграться с размером буфера и задержками, как описано в родных AppNotes, но пока результат не достигнут...

Для этого чипа для обеспечения такой высокой скорости есть одно единственное условие: применение Flow control/handshake. Это решит проблему с потерями данных. Если необходимо еще и обеспечить постоянно высокую скорость - необходимо ставить FIFO буфер. И это не связано с глючностью самого чипа или вообще с чем-то аппаратным. Объяснение здесь одно: для передачи данных по USB используется BULK точка (стандартными дровами от FTDI) с размером пакета в 64 байта, из которых 2 - зарезервировано. Поскольку BULK - не гарантирует время доставки данных, а гарантирует только безошибочость (см. спецификацию USB), то в процессе передачи данных могут происходить паузы, обусловленные занятостью шины USB (другим USB устройством с более высоким приоритетом), либо занятостью компа (например операциями с жестким диском). И если возникает пауза более нескольких милисекунд - происходит переполнение встроенного в FTDI буфера (384 байта). Именно поэтому надо искользовать FlowControl и свой буфер для хранения данных в то время, когда буфер FTDI забит.
Вообще это касается всех USB мостов которые используют BULK режим. Если не хотите таких проблем - ищите мосты с режимами Isochronous либо Interrupt. Правда, мне такие не известны...
Ну и напоследок: Есть еще один очень неплохой вариант решения этой проблемы - найти или написать дрова для FTDI для Isochronous или Interrupt режима работы. Но это уже совершенно другая история...