shide_3 0 10 ноября, 2020 Опубликовано 10 ноября, 2020 (изменено) · Жалоба Здравствуйте. Хотелось бы узнать, кто какие реальные скорости обмена (при регулярном заполнении буфера на передачу) получал на FT232RL в Виндовс и как это соотносилось с Вашей бодовой скоростью uart? Поясню суть своей проблемы: связка MSP430 и FT232RL. ПК отправляет запрос на чтение, затем MSP после обработки запроса посылает ответ (128 байт), затем новый запрос, новый ответ и т.д., в непрерывном цикле. Пробовал использовать как драйвера d2xx, так и VCP, результат одинаков. Cуть проблемы в том, что время между получением ответа и отправкой нового запроса из ПК в FT получается очень большим - около 16 мс (на Windows 7), время это измерялось осциллографом на ногах Rx и Tx FT232. Дело тут надо полагать в драйвере? Изменено 10 ноября, 2020 пользователем shide_3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 10 ноября, 2020 Опубликовано 10 ноября, 2020 · Жалоба Это вопрос скорее из области задержек (latency), чем скорости обмена. 16мс выглядит разумным числом. Что-то короче 10мс (8мс) на опросе USB под Windows, наверное, получить не очень просто. Возможно, удастся что-то накопать по ключевым словам increase mouse polling rate. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 10 ноября, 2020 Опубликовано 10 ноября, 2020 · Жалоба 6 часов назад, shide_3 сказал: Cуть проблемы в том, что время между получением ответа и отправкой нового запроса из ПК в FT получается очень большим - около 16 мс (на Windows 7), время это измерялось осциллографом на ногах Rx и Tx FT232. Дело тут надо полагать в драйвере? Суть проблемы тут в вашем протоколе обмена. Уходите от модели "запрос-ответ" и будет счастье. Ну или создавайте несколько параллельных сеансов "запрос-ответа". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryM 0 10 ноября, 2020 Опубликовано 10 ноября, 2020 · Жалоба 6 hours ago, shide_3 said: Дело тут надо полагать в драйвере? А Вы в панели управления Win в свойствах FT-шки покрутитите времена, они там гибко настраиваются. Насколько помню, 16мс как раз по умолчанию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 4 12 ноября, 2020 Опубликовано 12 ноября, 2020 · Жалоба 10.11.2020 в 22:50, DmitryM сказал: А Вы в панели управления Win в свойствах FT-шки покрутитите времена, они там гибко настраиваются. Насколько помню, 16мс как раз по умолчанию. При использовании драйвера d2xx латентность можно задать в программе через Api d2xx. Предложение пользователю кутить настройки драйвера - плохое. На винде достижима латентность 2ms в каждую сторону, т.е. цикл запрос-ответ уложится в 4ms если реакция устройства мгновенная. Ну и разумеется винда время не гарантирует: если ей захочется оптимизировать своп получите не 2ms а 2s. Философское: Работа методом запрос-ответ для современной вычислительной техники неприемлема. Оборудование сейчас оптимизировано на потоковые операции и режим запрос-ответ это боль, боль...боль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 13 ноября, 2020 Опубликовано 13 ноября, 2020 · Жалоба 12.11.2020 в 11:00, _3m сказал: Ну и разумеется винда время не гарантирует: если ей захочется оптимизировать своп получите не 2ms а 2s. Хорошо бы если-б только своп. Сталкивался с ситуацией, когда распахивание/свёртывание произвольного окна(!) любого приложения в системе, вгоняло реалтайм-процесс (обменивающийся с девайсом) в ступор на 200-300мсек. С закономерной потерей данных из-за ограниченности ОЗУ в девайсе. И никакое поднятие приоритета потока до максимума не помогало. Правда это было ещё на WinXP. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 17 ноября, 2020 Опубликовано 17 ноября, 2020 · Жалоба 14.11.2020 в 00:40, jcxz сказал: Правда это было ещё на WinXP. Да то же самое, ИМХО, во всех окнах. Я когда-то экспериментировал с FT232RL и нестандартными высокими скоростями. Были пропуски данных (насколько помню, в FT232RL очень маленький буфер) - а особенно часто они были когда шевелишь любые окошки в винде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shide_3 0 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба здравствуйте. Да, в диспетчере поменял интервал опроса с 16 мс на 1мс. На деле он уменьшился до 8 мс. Еще заметил, что этот интервал очень сильно зависит от самой бодовой скорости, т.е. при 921600 это 8 мс, но при 115200 уже около 50 мс... То есть практически пропорционально Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shide_3 0 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба On 11/10/2020 at 10:20 PM, jcxz said: Суть проблемы тут в вашем протоколе обмена. Уходите от модели "запрос-ответ" и будет счастье. Ну или создавайте несколько параллельных сеансов "запрос-ответа". Тут еще дело в том, что мы используем модбас (а это суть запрос-ответ), согласен, что он тут лишний, но пока концепция такая у нас.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба 1 час назад, shide_3 сказал: Тут еще дело в том, что мы используем модбас (а это суть запрос-ответ), согласен, что он тут лишний, но пока концепция такая у нас.. Даже модбас можно сделать правильно, без ненужных задержек. Для этого нужно писать драйвер, работающий на уровне ядра ОС, в реальном времени. А не на уровне приложения, как у вас. Раз уж выбрали модбас. Но вы всё сделали что-бы как можно больше замедлить обмен: 1) почему-то выбрали режим "запрос-ответ"; 2) почему-то выбрали модбас; 3) почему-то передаёте данные малыми порциями. А потом удивляетесь - "почему так медленно?". Ну а чего ожидали? Это как если у вас есть стакан напитка, и можно его выпить просто быстро поднеся стакан ко рту, а можно (как у вас): взять самую маленькую ложечку и долго-долго черпать ею, при этом ещё перед каждым зачерпыванием, кладя ложку на стол и беря её снова. Тут не важно насколько быстро вы можете двигать рукой - процесс питья всё равно будет очень долгим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shide_3 0 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба 6 minutes ago, jcxz said: Даже модбас можно сделать правильно, без ненужных задержек. Для этого нужно писать драйвер, работающий на уровне ядра ОС, в реальном времени. А не на уровне приложения, как у вас. Раз уж выбрали модбас. Но вы всё сделали что-бы как можно больше замедлить обмен: 1) почему-то выбрали режим "запрос-ответ"; 2) почему-то выбрали модбас; 3) почему-то передаёте данные малыми порциями. А потом удивляетесь - "почему так медленно?". Ну а чего ожидали? Это как если у вас есть стакан напитка, и можно его выпить просто быстро поднеся стакан ко рту, а можно (как у вас): взять самую маленькую ложечку и долго-долго черпать ею, при этом ещё перед каждым зачерпыванием, кладя ложку на стол и беря её снова. Тут не важно насколько быстро вы можете двигать рукой - процесс питья всё равно будет очень долгим. Драйвер и не писали, тут пользуемся стандартным VCP от windows. 3) ну так порции определены самим протоколом модбаса - длина данных ответа 125 слов максимум. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба Если битовая скорость невелика, то и пусть бы его. А на высоких скоростях (921600, например) с квитированием каждого блока - ОЧЕНЬ тоскливо (по крайней мере при дефолтных установках в драйвере). Даже с 1K-блоком блоком все очень плохо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vasily_ 45 26 ноября, 2020 Опубликовано 26 ноября, 2020 · Жалоба 20 минут назад, shide_3 сказал: тут пользуемся стандартным VCP от windows. Под FTDI ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
shide_3 0 27 ноября, 2020 Опубликовано 27 ноября, 2020 · Жалоба 19 hours ago, Vasily_ said: Под FTDI ? ну да. Там же на выбор, d2xx либо vcp Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vasily_ 45 27 ноября, 2020 Опубликовано 27 ноября, 2020 · Жалоба 4 часа назад, shide_3 сказал: ну да. Там же на выбор, d2xx либо vcp Да, только FTDI никогда не использует виндовые драйвера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться