evg123 0 4 мая, 2010 Опубликовано 4 мая, 2010 · Жалоба МикросхемаFT232R (а новый вариант FT2232D) - сейчас очень часто используется для построения моcтов типа USB -> com, USB -> RS485, USB -> JTAG. У нас возникла проблема с таким переходником USB -> RS485 - медленно работает. С FTDI микросхемой (FT232R) поставляется ихний стандартный драйвер USB-BULK. Всё замечательно но: отправляем пакет в USB (через их драйвер, через API, которое они дают) с периодичностью 1 раз в миллисекунду (64 байта), а на выходе 485 -ой фиксируем этот пакет в среднем 1 раз в 15 миллисекунд. Как раскачигарить этот драйвер? (Есть апп-нота, что якобы можно поднять приоритет драйвера - пробовали - не помогает). Или это проблема винды и она больше не даст? Может быть вместо WinXP поставить WinXP - Embedded? Это может чем-нибудь помочь? Зрительно на экране видим, что пакет (на XP) отправляется не раз в миллисекунду, а гораздо реже (в элементарном окошке считаем количество отправок). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex11 3 4 мая, 2010 Опубликовано 4 мая, 2010 · Жалоба Отправлять раз в 15 миллисекунд 64*15 байтов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
evg123 0 5 мая, 2010 Опубликовано 5 мая, 2010 · Жалоба Отправлять раз в 15 миллисекунд 64*15 байтов. Понятно, но это не годится. На каждый отправленный пакет должен быть ответ. После каждой отправки ждём ответа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sergeeff 1 5 мая, 2010 Опубликовано 5 мая, 2010 · Жалоба Понятно, но это не годится. На каждый отправленный пакет должен быть ответ. После каждой отправки ждём ответа. Возьмите ddk´ный bulk драйвер от XP, например. Там посылается за раз 4Кб буфер (если память не изменяет) и скорость порядка 800 Кб/с можно запросто получить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 6 мая, 2010 Опубликовано 6 мая, 2010 · Жалоба Понятно, но это не годится. На каждый отправленный пакет должен быть ответ. После каждой отправки ждём ответа. Тогда быстрее, чем сейчс, у вас работать не будет, если только не напишете свой драйвер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 6 мая, 2010 Опубликовано 6 мая, 2010 · Жалоба Понятно, но это не годится. На каждый отправленный пакет должен быть ответ. После каждой отправки ждём ответа. Для USB интерфейса алгоритм обмена типа "запрос-ответ" категорически не годится потому что дает низкую скорость. Используйте 2 независимых потока: входной и выходной, причем в pc и девайсе должна быть обеспечена буферизация и чем глубже тем лучше. По другому серьезную скорость не получите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dr.duban 0 11 мая, 2010 Опубликовано 11 мая, 2010 · Жалоба А какой размер ответа? Если я все правильно понимаю то котроллер будет NAKать IN трансферы меньше 62 байт если прошло меньше 16 мс после успешного трансфера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dr.duban 0 11 мая, 2010 Опубликовано 11 мая, 2010 · Жалоба Так и не смог найти код по теме. В целом, тут два пути для оптимизации. длл драйвера должна экспортировать функцию FT_SetLatencyTimer(...) с ее помощью можно изменить время ожидания между двумя последовательными IN трансферами меньше 62 байт. (минимум 2 мс) И еще должна быть функция FT_SetChars(...) которая позволяет установить символ события. После получения такого символа в OUT пакете, котроллер должен ответить байтами статуса и при получении IN запроса заслать до 62 байт данных без задержки. Это, конечно, если я ничего не перепутал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SBE 1 18 июля, 2010 Опубликовано 18 июля, 2010 · Жалоба МикросхемаFT232R (а новый вариант FT2232D) - сейчас очень часто используется для построения моcтов типа USB -> com, USB -> RS485, USB -> JTAG. У нас возникла проблема с таким переходником USB -> RS485 - медленно работает. С FTDI микросхемой (FT232R) поставляется ихний стандартный драйвер USB-BULK. Всё замечательно но: отправляем пакет в USB (через их драйвер, через API, которое они дают) с периодичностью 1 раз в миллисекунду (64 байта), а на выходе 485 -ой фиксируем этот пакет в среднем 1 раз в 15 миллисекунд. Как раскачигарить этот драйвер? (Есть апп-нота, что якобы можно поднять приоритет драйвера - пробовали - не помогает). Или это проблема винды и она больше не даст? Может быть вместо WinXP поставить WinXP - Embedded? Это может чем-нибудь помочь? Зрительно на экране видим, что пакет (на XP) отправляется не раз в миллисекунду, а гораздо реже (в элементарном окошке считаем количество отправок). Попробуйте послать пакет 62 байта. Как-то похоже на latency timer, но тот правда работает на передачу в PC. FTDI добавляет 2 своих статусных байта на каждый пакет, соответственно в вашем случае посылает 2 bulk пакета. Второй через время latency timer, которое по умолчанию 16мс. Почитайте AN232B-04 Data Throughput,Latency and Handshaking. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Oldring 0 19 июля, 2010 Опубликовано 19 июля, 2010 · Жалоба Как-то похоже на latency timer Это похоже на квант планировщика Виндов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SBE 1 19 июля, 2010 Опубликовано 19 июля, 2010 · Жалоба Это похоже на квант планировщика Виндов. И то правда. Как то не замечали таких траблов с FTDI при обмене через ftdi.dll. Может быть вместо WinXP поставить WinXP - Embedded? Это может чем-нибудь помочь? XP Embedded не поможет, поскольку нечем от Professional не отличается. в этой части Real time это WinCe, но это другая ОСь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
