[shide_3 0]

Здравствуйте. Хотелось бы узнать, кто какие реальные скорости обмена (при регулярном заполнении буфера на передачу) получал на FT232RL в Виндовс и как это соотносилось с Вашей бодовой скоростью uart?

Поясню суть своей проблемы: связка MSP430 и FT232RL. ПК отправляет запрос на чтение, затем MSP после обработки запроса посылает ответ (128 байт), затем новый запрос, новый ответ и т.д., в непрерывном цикле. Пробовал использовать как драйвера d2xx, так и VCP, результат одинаков. Cуть проблемы в том, что время между получением ответа и отправкой нового запроса из ПК в FT получается очень большим - около 16 мс (на Windows 7), время это измерялось осциллографом на ногах Rx и Tx FT232. 

Дело тут надо полагать в драйвере?

Изменено 10 ноября, 2020 пользователем shide_3

[Flood 12]

Это вопрос скорее из области задержек (latency), чем скорости обмена. 16мс выглядит разумным числом. Что-то короче 10мс (8мс) на опросе USB под Windows, наверное, получить не очень просто.

Возможно, удастся что-то накопать по ключевым словам increase mouse polling rate.

[jcxz 184]

6 часов назад, shide_3 сказал:

Cуть проблемы в том, что время между получением ответа и отправкой нового запроса из ПК в FT получается очень большим - около 16 мс (на Windows 7), время это измерялось осциллографом на ногах Rx и Tx FT232. 

Дело тут надо полагать в драйвере?

Суть проблемы тут в вашем протоколе обмена. Уходите от модели "запрос-ответ" и будет счастье. Ну или создавайте несколько параллельных сеансов "запрос-ответа".

[DmitryM 0]

6 hours ago, shide_3 said:

 

Дело тут надо полагать в драйвере?

 

А Вы в панели управления Win в свойствах FT-шки покрутитите времена, они там гибко настраиваются. Насколько помню, 16мс как раз по умолчанию.

[_3m 4]

10.11.2020 в 22:50, DmitryM сказал:

А Вы в панели управления Win в свойствах FT-шки покрутитите времена, они там гибко настраиваются. Насколько помню, 16мс как раз по умолчанию.

При использовании драйвера d2xx латентность можно задать в программе через Api d2xx. Предложение пользователю кутить настройки драйвера - плохое.

На винде достижима латентность 2ms в каждую сторону, т.е. цикл запрос-ответ уложится в 4ms если реакция устройства мгновенная. Ну и разумеется винда время не гарантирует: если ей захочется оптимизировать своп получите не 2ms а 2s.

Философское: Работа методом запрос-ответ для современной вычислительной техники неприемлема. Оборудование сейчас оптимизировано на потоковые операции и режим запрос-ответ это боль, боль...боль.

[jcxz 184]

12.11.2020 в 11:00, _3m сказал:

Ну и разумеется винда время не гарантирует: если ей захочется оптимизировать своп получите не 2ms а 2s.

Хорошо бы если-б только своп. Сталкивался с ситуацией, когда распахивание/свёртывание произвольного окна(!) любого приложения в системе, вгоняло реалтайм-процесс (обменивающийся с девайсом) в ступор на 200-300мсек. С закономерной потерей данных из-за ограниченности ОЗУ в девайсе. И никакое поднятие приоритета потока до максимума не помогало. Правда это было ещё на WinXP.

[Arlleex 131]

14.11.2020 в 00:40, jcxz сказал:

Правда это было ещё на WinXP.

Да то же самое, ИМХО, во всех окнах. Я когда-то экспериментировал с FT232RL и нестандартными высокими скоростями.
Были пропуски данных (насколько помню, в FT232RL очень маленький буфер) - а особенно часто они были когда шевелишь любые окошки в винде.

[shide_3 0]

здравствуйте. Да, в диспетчере поменял интервал опроса с 16 мс на 1мс. На деле он уменьшился до 8 мс. Еще заметил, что этот интервал очень сильно зависит от самой бодовой скорости, т.е. при 921600 это 8 мс, но при 115200 уже около 50 мс... То есть практически пропорционально

[shide_3 0]

On 11/10/2020 at 10:20 PM, jcxz said:

Суть проблемы тут в вашем протоколе обмена. Уходите от модели "запрос-ответ" и будет счастье. Ну или создавайте несколько параллельных сеансов "запрос-ответа".

Тут еще дело в том, что мы используем модбас (а это суть запрос-ответ), согласен, что он тут лишний, но пока концепция такая у нас..

[jcxz 184]

1 час назад, shide_3 сказал:

Тут еще дело в том, что мы используем модбас (а это суть запрос-ответ), согласен, что он тут лишний, но пока концепция такая у нас..

Даже модбас можно сделать правильно, без ненужных задержек. Для этого нужно писать драйвер, работающий на уровне ядра ОС, в реальном времени. А не на уровне приложения, как у вас. Раз уж выбрали модбас.

Но вы всё сделали что-бы как можно больше замедлить обмен: 1) почему-то выбрали режим "запрос-ответ"; 2) почему-то выбрали модбас; 3) почему-то передаёте данные малыми порциями. А потом удивляетесь - "почему так медленно?". Ну а чего ожидали?

Это как если у вас есть стакан напитка, и можно его выпить просто быстро поднеся стакан ко рту, а можно (как у вас): взять самую маленькую ложечку и долго-долго черпать ею, при этом ещё перед каждым зачерпыванием, кладя ложку на стол и беря её снова. Тут не важно насколько быстро вы можете двигать рукой - процесс питья всё равно будет очень долгим.  

[shide_3 0]

6 minutes ago, jcxz said:

Даже модбас можно сделать правильно, без ненужных задержек. Для этого нужно писать драйвер, работающий на уровне ядра ОС, в реальном времени. А не на уровне приложения, как у вас. Раз уж выбрали модбас.

Но вы всё сделали что-бы как можно больше замедлить обмен: 1) почему-то выбрали режим "запрос-ответ"; 2) почему-то выбрали модбас; 3) почему-то передаёте данные малыми порциями. А потом удивляетесь - "почему так медленно?". Ну а чего ожидали?

Это как если у вас есть стакан напитка, и можно его выпить просто быстро поднеся стакан ко рту, а можно (как у вас): взять самую маленькую ложечку и долго-долго черпать ею, при этом ещё перед каждым зачерпыванием, кладя ложку на стол и беря её снова. Тут не важно насколько быстро вы можете двигать рукой - процесс питья всё равно будет очень долгим.  

Драйвер и не писали, тут пользуемся стандартным VCP от windows.

3) ну так порции определены самим протоколом модбаса - длина данных ответа 125 слов максимум.

[rx3apf 0]

Если битовая скорость невелика, то и пусть бы его. А на высоких скоростях (921600, например) с квитированием каждого блока - ОЧЕНЬ тоскливо (по крайней мере при дефолтных установках в драйвере). Даже с 1K-блоком блоком все очень плохо.

[Vasily_ 45]

20 минут назад, shide_3 сказал:

тут пользуемся стандартным VCP от windows.

Под FTDI ?

[shide_3 0]

19 hours ago, Vasily_ said:

Под FTDI ?

ну да. Там же на выбор, d2xx либо vcp

[Vasily_ 45]

4 часа назад, shide_3 сказал:

ну да. Там же на выбор, d2xx либо vcp

Да, только FTDI никогда не использует виндовые драйвера.