Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Виртуальный COM-порт, как настроить драйвер usbser  (Прочитано 21408 раз)
0 Пользователей и 1 Гость смотрят эту тему.
anthill
Гость
« : 09-07-2008 06:44 » 

На базе PIC18F4550 реализовал виртуальный COM-порт. Работает хорошо, устойчиво, но есть одна хотелка скорость передачи достаточна низкая. Дело в том, что рекомендуемые для установки драйвера inf файлы не содержат настроек таймаутов опроса USB устройства класса CDC. По умолчанию получается, что компьютер опрашивает устройство примерно каждые 100 миллисекунд с максимальным размером запрашиваемого дампа 4096 байт(данный дамп читается всего за 8 миллисекунд, а дальше идет таймаут на 100 миллисекунд, что существенно увеличивает время передачи).

Так вот вопрос в следующем, можно ли каким-то образом снизить таймауты опроса виртуального COM-порта хотя бы до 1 миллисекунды или увеличить размер минимального дампа посредством ввода в inf файл каких-то дополнительных настроек или данные настройки определяет Windows приложение для обслуживания COM-порта. В своих пробах использовал ComPortToolKits ...

Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 09-07-2008 08:21 » 

возможно проблемма не в драйвере а в приложении?
почему вы считаете что это ошибка драйвера?
попробуйте написать свое приложение обработчик?

PS вобще 4096 байт * 10 Гц * 8 Бит = 327680бит/сек = 327 КБит/сек
для COM - вы считаете мало?)))

PPS данный дамп читается 8мс. - ОТКУДА читается? чем и где вы мерили это время?
« Последнее редактирование: 09-07-2008 08:25 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
anthill
Гость
« Ответ #2 : 09-07-2008 09:14 » 

Возможно проблема и в приложении. Это я и хочу узнать.
И ни в коем случае я не считаю это ошибкой драйвера, перевернул
горы литературы и нашел, что через драйвер serenum.sys в купе с драйвером usbser можно настраивать
таймауты на прием и изменять длину пакета как для чтения так и для записи.
Даже нашел простейшие примеры inf файлов, где показано как установить например
жесткую скорость VCP, через inf файл, пробовал данный inf файл исправить на работу
с определенными  мною VID и PID - действительно, только при установке определенной
в inf файле скорости происходит связь, на других скоростях драйвер просто блокирует
передачу. Да кстати скорость Вами подсчитана неправильно 4096 байт не надо еще раз умножать на 8 Улыбаюсь
в итоге 4096 * 10Гц = 40960 бит/сек. А реально мое устройство может готовить данные для передачи
порядка 720 байт в миллисекунду, что вполне умещается в один фрейм FullUSB режима. Кстати пробовал
на этом же устройстве сделать MassStorage, чтение памяти в 4Мбайта происходит всего за 8сек

 А насчет того как я увидел, что дамп в 4096 байт читается 8 мс, так это очень просто - по осциллографу, данные то не просто данные, они читаются и микросхемы памяти. Видно, когда процессор действительно получил запрос по USB и читает память, потом таймаут на 100мс, потом опять чтение 4096 байт. Вы можете сказать, а уверен ли я, что не пропускаю посылки. Уверен на 100%, что не пропускаю, т.к. подключал USBspy и видел картинку запросов и ответов, пропусков ответов не было, каждый запрос обрабатывается. Написать свою утилитку можно, но у меня больше уверенность в том, что проблема в настойке драйвера. Потому и обратился за помощью. Может кто-нибудь ковырял стандартный CDC драйвер досконально ...
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 09-07-2008 12:08 » 

угу. доводы серьезные.
посмотрю.... с ходу пока ничего дельного.

1 надо покопать в сторону IOCTL (управление) этого драйвера. поискать его интерфейс. может быть исходные коды. хотя бы интерфейс должен быть где то. либо через реестр

serenum в коде есть в DDK. но помоему это не то...
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
anthill
Гость
« Ответ #4 : 18-11-2008 05:07 » new

Вот что по этому вопросу советуют японские товарищи.
There is no relation between the transfer speed of the CDC bulk endpoints and the baudrate setting of the virtual COM port.

CDC-ACM is designed to carry UART signaling and parameters over USB. It supposes a UART connected on the device side (though we can connect any peripherals, instead of a UART). The baudrate setting is also just a parameter carried over USB. It is applied to the UART, not to the USB. Therefore, the baudrate doesn't determine the USB transfer speed directly.

You can set any baudrate to the UART on the device, as long as the UART supports the baudrate. usbser.sys just passes the baudrate set by IOCTL_SERIAL_SET_BAUD_RATE request to the device over Set_Line_Coding. And then the device firmware sets up the baudrate of its UART to this value.

The transfer speed of the bulk endpoints of usbser.sys has no difference from other bulk device driver, like WinUSB. For the top speed, You'll see 17-18 full-size packets (64 bytes) per frame on FS bus, on recent PCs over HS hub, if your device accepts this speed.

But actual transfer speed varies by the transfer size, as usual of the bulk transfer. If you send one byte by one byte, 1 byte per frame at most. To see 512 byte per frame, write 512 bytes (or more) block at a time to the COM port on the host app. From the device side, send the 512 bytes block without any gap.

Посоветуйте как можно без дополнительных заморочек установить параметр IOCTL_SERIAL_SET_BAUD_RATE ...
Записан
sss
Специалист

ru
Offline Offline

« Ответ #5 : 18-11-2008 06:17 » 


 надо покопать в сторону IOCTL (управление) этого драйвера. поискать его интерфейс. может быть исходные коды
Записан

while (8==8)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines