| |
|
  |
 Вопрос про CY7C68013 EZ-USB FX2, Есть готовое устройство, нужно подключиться, не поломав. |
|
|
|
|
 Sep 8 2010, 10:21
|
Частый гость
Группа: Свой
Сообщений: 183
Регистрация: 10-10-06
Из: Смоленск
Пользователь №: 21 167
|
Цитата(niktagor @ Sep 8 2010, 13:48)  Устройство сделано так, что я отправляю туда один запрос размером 1 байт. Оно в ответ выплевывает 8 транзакций по 512 байт и одну с sync packet'ом. Потом все повторяется заново. Так вот, эта операция должна занимать не больше 1 миллисекунды. А получается какая-то ерунда. Используя USB monitor, получаю удивительные результаты. Все работает сверхбыстро, пока куда-то не пропадают 15мс(смотри скриншот). Где искать причину? Значит получение 4К данных по запросу - это хреново. Чтобы достичь приличной скорости по хорошему нужно выносить всю обработку в драйвер. А так попробуй поднять приоритет процесса до реал-тайм и кидать сразу несколько запросов (точное число проверяется экспериментально) в 1 байт асинхронно приему. PS: Про 15мс тебе уже ответили. PS2: Какой скорости приема нужно достичь?
|
|
|
|
|
|
|
|
Sep 8 2010, 10:31
|
Участник
Группа: Участник
Сообщений: 29
Регистрация: 24-06-09
Пользователь №: 50 601
|
Хорошо. Почему тогда этот другой процесс ВСЕГДА занимает 15мс? Приоритет процесса - реального времени. Запускается на втором ядре. Я могу как-то запустить его не в user mode, а в режиме ядра? Цитата(Serg_Sm @ Sep 8 2010, 14:21) PS2: Какой скорости приема нужно достичь? 1000 таких запросов должно обрабатываться за секунду. Точнее, примерно 4МБ в секунду. Вроде, цифра детская Ситуация странная. На каждую 1мс моих взаимодействий с прибором приходится 15мс потерянного времени. При том, что все остальные программы отключены и загрузка ЦП под 0%. Даже теоретическая максимальная скорость в этом случае всего 30Мбит в секунду. P.S. Это если верить USB Monitor.
Сообщение отредактировал niktagor - Sep 8 2010, 11:05
|
|
|
|
|
|
|
|
Sep 8 2010, 11:19
|
Частый гость
Группа: Свой
Сообщений: 183
Регистрация: 10-10-06
Из: Смоленск
Пользователь №: 21 167
|
Цитата(niktagor @ Sep 8 2010, 14:31) Хорошо. Почему тогда этот другой процесс ВСЕГДА занимает 15мс? Приоритет процесса - реального времени. Запускается на втором ядре. Я могу как-то запустить его не в user mode, а в режиме ядра?
1000 таких запросов должно обрабатываться за секунду. Точнее, примерно 4МБ в секунду. Вроде, цифра детская 15 мс - так организован системный таймер виндов. Все претензии к одному богатому пенсионеру. В режиме ядра запустить виндовое приложение - хм... А вот написать службу, которая будет рулить потоком данных - это нормальный выход.
|
|
|
|
|
|
|
|
Sep 8 2010, 12:03
|
Участник
Группа: Участник
Сообщений: 29
Регистрация: 24-06-09
Пользователь №: 50 601
|
Про 15 миллисекунд разобрался. Это точность системного таймера в большинстве современных компьютеров. Например Sleep(1) и Sleep(8) обе вызывают задержку на 15 миллисекунд. Так что USB Monitor с большим разрешением время посчитать не сможет. И реальные тайминги я через нее не узнаю. Вопрос: можно ли их вообще узнать, не заглядывая в USB провод приборами?
|
|
|
|
|
|
|
|
Sep 8 2010, 12:48
|
Частый гость
Группа: Свой
Сообщений: 183
Регистрация: 10-10-06
Из: Смоленск
Пользователь №: 21 167
|
В FX2LP есть аппаратная буферизация - как минимум 2 запроса должны пройти. Как отреагирует фирмварь это другой вопрос. Определение временных интервалов с помощью high-resolution performance counter: Код #define GETFIRSTTICK() LARGE_INTEGER qwTickCountA[2]; \
QueryPerformanceCounter(&(qwTickCountA[0]));
#define GETSECONDTICKMESSAGE() { QueryPerformanceCounter(&(qwTickCountA[1])); \
LARGE_INTEGER qwFrequencyA; \
QueryPerformanceFrequency(&qwFrequencyA); \
double dbTMPA = (double)(qwTickCountA[1].QuadPart - qwTickCountA[0].QuadPart)/(double)qwFrequencyA.QuadPart; \
char szMessageA[80]; \
sprintf(szMessageA,"Операция завершена за %.9f секунд", dbTMPA); \
::MessageBox(0, szMessageA, ("Время работы"), MB_OK | MB_ICONINFORMATION);}
|
|
|
|
|
|
|
|
Sep 8 2010, 14:38
|
Знающий
Группа: Свой
Сообщений: 549
Регистрация: 1-06-05
Пользователь №: 5 644
|
Цитата(niktagor @ Sep 8 2010, 13:31) Ситуация странная. На каждую 1мс моих взаимодействий с прибором приходится 15мс потерянного времени. Цитата(niktagor @ Sep 8 2010, 15:03) Про 15 миллисекунд разобрался. Это точность системного таймера в большинстве современных компьютеров. Например Sleep(1) и Sleep(8) обе вызывают задержку на 15 миллисекунд. Так что USB Monitor с большим разрешением время посчитать не сможет. И реальные тайминги я через нее не узнаю. Вопрос: можно ли их вообще узнать, не заглядывая в USB провод приборами? Если USB Monitor серьезная программа, то для измерения промежутков времени будет использовать High-Resolution Timer (класс Stopwatch в .NET Framework). Скорее всего, в программе, которую Вы используете в цикле обмена по USB вызывается Sleep(1), что приводит к засыпанию потока Вашей программы, в котором выполняется обмен по USB на 15 миллисекунд.
Сообщение отредактировал Konst_777 - Sep 8 2010, 15:30
|
|
|
|
|
|
|
|
Sep 8 2010, 20:18
|
Знающий
Группа: Свой
Сообщений: 614
Регистрация: 12-06-09
Из: рядом с Москвой
Пользователь №: 50 219
|
Цитата(niktagor @ Sep 8 2010, 16:03) Про 15 миллисекунд разобрался. Это точность системного таймера в большинстве современных компьютеров. Например Sleep(1) и Sleep(8) обе вызывают задержку на 15 миллисекунд. Так что USB Monitor с большим разрешением время посчитать не сможет. И реальные тайминги я через нее не узнаю. Вопрос: можно ли их вообще узнать, не заглядывая в USB провод приборами? Попробуйте параллельно запустить Windows Media Player в режиме воспроизведения видео или музыки - - он повышает точность системного таймера до 1мс. и все измерители времени и Sleep'ы будут работать точнее в 15 раз.
|
|
|
|
|
|
|
|
Sep 9 2010, 11:54
|
Знающий
Группа: Свой
Сообщений: 549
Регистрация: 1-06-05
Пользователь №: 5 644
|
Цитата(niktagor @ Sep 8 2010, 12:48) ... А получается какая-то ерунда. Используя USB monitor, получаю удивительные результаты. Все работает сверхбыстро, пока куда-то не пропадают 15мс(смотри скриншот). Где искать причину? Цитата(niktagor @ Sep 8 2010, 15:03) Про 15 миллисекунд разобрался. ... Так что USB Monitor с большим разрешением время посчитать не сможет. И реальные тайминги я через нее не узнаю... Эх, не посмотрел я скриншот и начал фантазировать. Да, Вы правы. USB Monitor не использует High-Resolution Timer. И реальные тайминги Вы с помощью этой программы не узнаете.
|
|
|
|
|
|
|
|
Sep 9 2010, 17:24
|
Участник
Группа: Участник
Сообщений: 29
Регистрация: 24-06-09
Пользователь №: 50 601
|
Прикрутил high-resolution timer. Выясняется, что между получаемыми пакетами задержка всегда ровно 250мкс. Это при том, что это все часть одной большой информации, и она выдается по одному запросу на 9 пакетов. Косяк явно не в приборе. Так как даже с родной программой и он выдает это быстрее. Использую метод XferData(). Посылка наперед нескольких запросов ситуацию не меняет. Завтра попробую использовать Begin\Wait\Finish DataXfer(). Есть смысл? В чем их принципиальное различие?
|
|
|
|
|
|
|
|
Sep 9 2010, 20:02
|
Знающий
Группа: Свой
Сообщений: 614
Регистрация: 12-06-09
Из: рядом с Москвой
Пользователь №: 50 219
|
Цитата(niktagor @ Sep 9 2010, 21:24) Прикрутил high-resolution timer. Выясняется, что между получаемыми пакетами задержка всегда ровно 250мкс. Это при том, что это все часть одной большой информации, и она выдается по одному запросу на 9 пакетов. Косяк явно не в приборе. Так как даже с родной программой и он выдает это быстрее. Использую метод XferData(). Посылка наперед нескольких запросов ситуацию не меняет. Завтра попробую использовать Begin\Wait\Finish DataXfer(). Есть смысл? В чем их принципиальное различие? первый метод синхронный, второй асинхронный. Асинхронный метод позволяет посылать следующий запрос на чтение данных драйверу не дожидаясь исполнения предыдущего и таким образом можно организовать очередь запросов на чтение и получить скорость до 40-50МБайт/c. Но проблема в том, то у вас нужно посылать ещё и запрос устройству для того чтобы оно выдало данные - вот тут главные тормоза, так как Маздай от билла гейтса не является ОС реального времени и быстро переключать потоки и задачи не умеет.
|
|
|
|
|
|
|
|
Sep 10 2010, 04:57
|
Местный
Группа: Свой
Сообщений: 330
Регистрация: 10-06-05
Из: Россия, Москва
Пользователь №: 5 894
|
Цитата(niktagor @ Sep 8 2010, 13:48) Устройство сделано так, что я отправляю туда один запрос размером 1 байт. Оно в ответ выплевывает 8 транзакций по 512 байт и одну с sync packet'ом. Потом все повторяется заново. Так вот, эта операция должна занимать не больше 1 миллисекунды. А получается какая-то ерунда. Используя USB monitor, получаю удивительные результаты. Все работает сверхбыстро, пока куда-то не пропадают 15мс(смотри скриншот). Где искать причину? Вы НИКОГДА не получите 1мс на USB при запросе туда-обратно. Время на переключение направления Вы не уменьшите. Пробуйте посылать запросы не по одному байту, а пачками, маскимум - размер входного буфера на данном EndPoint. А потом вычитывать данные. Если устройство сделано нормально, то должно работать.
|
|
|
|
|
|
|
|
Sep 10 2010, 06:15
|
Местный
Группа: Свой
Сообщений: 244
Регистрация: 21-02-05
Из: Урал
Пользователь №: 2 806
|
Цитата(-Al- @ Sep 10 2010, 10:57) ....Вы НИКОГДА не получите 1мс на USB при запросе туда-обратно ... НИКОГДА не говорите НИКОГДА PS. Обсуждалось здесь http://electronix.ru/forum/index.php?showt...=37919&st=0
|
|
|
|
|
|
|
|
Sep 10 2010, 08:30
|
Участник
Группа: Участник
Сообщений: 29
Регистрация: 24-06-09
Пользователь №: 50 601
|
По поводу моих 250мкс по Вашей ссылке нашел интересное сообщеньице Цитата У шины время кадра на полной скорости 1 мС, а на высокой микрокадр - 0.125 мс. В течении этого времени в самом худшем случае ( это тот случай, если имеется простейший планировщик пакетов - один запрос в кадре) мы буим иметь задержки 2 мСек и 0.25 мСек соответственно. В связи с этим, вопрос. Планировщик пакетов - это в cyusb.sys, или на более низком уровне? Еще появилась идея перейти под linux и написать код для библиотеки libusb. На сайте написано, что вышла ее версия под Windows. Кто-нибудь пробовал? Есть ли смысл в моей ситуации?
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
