Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FT2232H: FIFO Sync 245 mode, полная скорость не работает
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
PrSt
Всем привет, есть вопрос, не могу победить.

Хочу сделать захват аналоговых данных, очень высокоскоростной.
из ADC[DSP] в -> FTDI -> PC

Использую FT2232H: FIFO Sync 245 mode, полная скорость не работает.
Из обещанных даташитов 40МБайт/с, только куски на скорости 8МБайт/с.
А точнее:
Есть DSP TMS320F28027, на ней я реализовал АЦП который выдает данные в цикле для FTDI FT2232H.
И как мне кажется тут у меня нет вопросов. За исключением того, нужно ли строго отвечать сигналом WR или я могу его его постоянно держать как 0. На практике не видит ни какой разницы...

Суть глюка описываю ниже.

То есть на стороне DSP, проводится вся инициализация, согласно временной диаграмме в даташите (page 27)
тоже описано в "FTDI App Note 130".
Назначаю пины, и жду когда TXE==0. Как только он 0 то выставляю WR=0 и начинаю по циклу измерять встроенным на стороне DSP АЦП и выставлять данные на 8 битный "параллельный порт".
На сколько я понял с документации, а точнее обратное там не написано нигде. То как я понял, до тех пор пока от меня исходит WR=0, FTDI забирает данные. Но она также может в любой момент поднять свой TXE в 1. Я это наблюдаю на осциллографе, что она когда ей вздумается, без всякой детерминированности прерывает на какое то время TXE в 1, и потом опять в 0.
Вот тут начинается второй интересный момент, а точнее второй вопрос.
вот так примерно выглядит форма TXE
---_--_--_--_--_-------------_----_-_------_---------------------------_--_--_------_--_---------
вот тут все что лог."1" это по сути пропуск в измеряемом аналоговом стриме. то есть - бордак полный.
как я понимаю то TXE должен быть либо постоянно 0, на протяжении запрошенного количества байт на считывание
----__________________________________________________________________------
либо вот такой.
----____-____-____-____-____-____-____-____-____-____-____-____-____-____-------

Как я понимаю, это уже все вопросы должны быть к программе что на стороне PC.
На стороне PC я частично базировался на коде, http://dangerousprototypes.com/forum/viewt...f=19&t=1495. А точнее, инициализацию сделал точно как у них и скопипастил их функции по приему данных в цикле с сохранением в файл.
Пробовал переделать, аллочить отдельно память и писать в неё и по завершению всей процедуры писать на HDD. Разницы вообще не заметил. Глюк все также проявляется.

Если верить той дискуссии, они забирают данные достаточно близко к скорости 40МБайт/с (естественно если верить написанному).
И код я уже жаде ихний подставлял, думая что проблема в моем коде. Всё тоже самое.

Особенность, захват данных в начале идёт без пропусков, и потом начинаются данные пропускаться.
Выглядит как будто FTDI сперва данные помещала в пустой буффр полного размера, и потом только в его 1/4 часть. Если отслеживать в программе сигнал, то визуально это так.

Проверяю просто
Подаю на АЦП синус и смотрю его потом в программе на компе. Он с вырезанными кусками от пропусков.
Потом делаю подобие ЛЧМ и тоже самое проверяю. Вижу ту же самую картину с пропусками.

Подскажите - как мне это победить, хочу чтоб данные отдавались ровно и детерминировано.
Тоесть, чтоб я запросил к примеру 50МБайт и их все забрал, а не не-детерминированными кусочками.
Alex11
40 МБ/с близко к теоретическому пределу для шины, скорее всего на сплошном потоке Вы их не получите. Я с этой FTDI не работал, так что не знаю, сколько она отдает на самом деле. Из общих соображений по работе с FTDI - запрашивайте из PC ввод кусками максимального размера.
ivanoffer
Цитата(Alex11 @ Nov 25 2015, 16:37) *
40 МБ/с близко к теоретическому пределу для шины, скорее всего на сплошном потоке Вы их не получите.


Получали среднее значение 43МБ/c на объеме 4ГБ. При этом наблюдали кратковременные провалы до 12МБ/c.
Скорость сильно зависит от архитектуры системы (моста PCIe2USB), загрузки шины и ЦП. На не очень удачных
мат.платах получали среднее значение 21МБ/с с провалами до 8МБ/c, иногда до 2МБ/c. При требуемом нам потоке
не менее 20МБ/c пришлось ставить сглаживающий буфер на внешнем ОЗУ 2МБ.

ukpyr
видел похожие жалобы на форумах FTDI - проблема где-то в их софте.
на CY7C68013A как-то получают 24МБ/с непрерывно.
PrSt
Цитата(ukpyr @ Nov 26 2015, 10:40) *
видел похожие жалобы на форумах FTDI - проблема где-то в их софте.

Но, как то же ведь люди получают 20..25МБайт/сек даже на тех их драйверах. Хотя бы 20...
Я так понимаю, у меня сейчас загвоздка в том, чтоб понять, как бы заставить ЮСБ драйвер чаще обращаться к FTDI.

Цитата(ukpyr @ Nov 26 2015, 10:40) *
на CY7C68013A как-то получают 24МБ/с непрерывно.

Уже лежит под руками....
Александр77
Делал проект с FT2232H в паре с плисиной. Тоже ожидал "детерминированной" длительности активной и пассивной фазы, и обломался.
Выход из положения нашел в буфере FIFO, глубина которого была сначала 8кБ, а потом 16кБ.
Даже после использования FIFO, на вин хр наблюдались потери (скорость порядка 9МБ/с), в паре с семеркой потерь нет.
На большую скорость не проверял.
PrSt
Цитата(Александр77 @ Nov 26 2015, 19:49) *
Делал проект с FT2232H в паре с плисиной. Тоже ожидал "детерминированной" длительности активной и пассивной фазы, и обломался.
Выход из положения нашел в буфере FIFO, глубина которого была сначала 8кБ, а потом 16кБ.

Ага... Расскажите плз, вот про это детальнее.
Это вы использовали какой чип FIFO?
Александр77
Я не использовал внешнее FIFO, а внутри проекта ПЛИС, делал блок FIFO (из внутренней памяти).
Грубая оценка была такой:
минимальный интервал опроса кратен 1 мс;
при имеющемся потоке, можно прикинуть сколько байт запишется за 1 мс;
далее, закладывать размер буфера в 2-8 раз больше (зависит от ограничений. У меня размер памяти в циклоне 2 был 8 кБ, а в циклоне 3 уже мог делать 32кБ, но хватило 16кБ).
PrSt
Цитата(Александр77 @ Nov 26 2015, 22:40) *
Я не использовал внешнее FIFO, а внутри проекта ПЛИС, делал блок FIFO (из внутренней памяти).
Грубая оценка была такой:
минимальный интервал опроса кратен 1 мс;
при имеющемся потоке, можно прикинуть сколько байт запишется за 1 мс;
далее, закладывать размер буфера в 2-8 раз больше (зависит от ограничений. У меня размер памяти в циклоне 2 был 8 кБ, а в циклоне 3 уже мог делать 32кБ, но хватило 16кБ).

ПЛИС пока еще делается, так что еще не удалось протестировать.
Истина с скоростью, причинами и т.д, начала выясняться после активного обсуждения у меня на форуме http://www.uschema.com/forum/viewtopic.php?f=4&t=4049
Александр77
По мотивам Вашего форума, при работе с софтом данные должны быть кратны 64 Б, мне пришлось в свое время увеличить на 3 байта протокол. Хотя, таже железка, но работавшая в паре с лабвью, спокойно рабтала с данными произвольной длины.
Еще, можно сделать на стороне ПК огромный буфер и писать в него - это тоже повышает скорость.
PrSt
Цитата(Александр77 @ Nov 27 2015, 22:48) *
По мотивам Вашего форума, при работе с софтом данные должны быть кратны 64 Б, мне пришлось в свое время увеличить на 3 байта протокол. Хотя, таже железка, но работавшая в паре с лабвью, спокойно рабтала с данными произвольной длины.
Еще, можно сделать на стороне ПК огромный буфер и писать в него - это тоже повышает скорость.

таки да, есть особенности как самого ЮСБ, так же дров от FTDI. я провел простой эксперимент, сделал счетчик пропускной способности и посчитал скорость при отправке пакета кратному размера фрейма 62байта, и просто произвольное число. и заметил что соблюдая кратность скорость естественно увеличивается. А точнее я выравнивал по 4к блоку, там 3968 байт.
Потом тоже самое уточнил через ЮСБ сниффер. Когда данные не кратные, то они досылаются отдельно, и на этом падает скорость.

Но это все объясняет только как поднять максимум на этих драйверах, а там максимум удалось получить лишь около 8МБайт/Сек.

Остался открытый вопрос - Так как же поднять скорость хотябы до 20МБайт/сек ?
(не говоря уже про 40 МБайт/сек).
Александр77
Цитата(PrSt @ Nov 28 2015, 18:53) *
Остался открытый вопрос - Так как же поднять скорость хотябы до 20МБайт/сек ?
(не говоря уже про 40 МБайт/сек).

Тут надо понимать, что для получения таких скоростей требуется предоставить каналу максимальный приоритет. Выполнить подобное можно только минимизацией количества устройств USB (идеальнее - использовать только FT2232 и ничего более ни мышек, ни клавиатур, ни камер...).
PrSt
Цитата(Александр77 @ Nov 29 2015, 21:25) *
Тут надо понимать, что для получения таких скоростей требуется предоставить каналу максимальный приоритет. Выполнить подобное можно только минимизацией количества устройств USB (идеальнее - использовать только FT2232 и ничего более ни мышек, ни клавиатур, ни камер...).

Пробовал.
Там проблема в другом (как раз у меня на форуме обсуждалось), FTDI драйвера позволяют минимум 1мс TimeLatency задавать, а для таких скоростей нужно 125 мкс.
То есть, драйвера этого не могут предоставить.

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.