QSerialDevice - Библиотека для работы с COM-портами Опции

[silver47]

дак наверное буфер порта имеет только 4к, смотри в настройках драйвера устройства

Порт виртуальный - ELTIMA Virtual Serial Port. Порты, созданные другими программами (например, Virtual Serial Ports Emulator) не определяются этой библиотекой. Как понял, определяются только те порты, которые есть в диспетчере устройств в ветке "Порты LPT и COM". А где те, которые создаются Virtual Serial Ports Emulator не знаю. Но вопрос не в этом, а в том как получить все, что программа на другом конце записала в порт (~100 кб).

Программа, написанная другим человеком, на делфне читает всё полностью. Может можно как-то последовательно прочитать?

Windows 7; Qt 4.7

Сообщение отредактировал silver47 - 8.2.2011, 14:47

[Litkevich Yuriy]

Созданные другими программами не определяются этой библиотекой

не понял фразы

[kuzulis]

Порт виртуальный - ELTIMA Virtual Serial Port.

Самый хороший из всех эмуляторов! Имхо.

Порты, созданные другими программами (например, Virtual Serial Ports Emulator) не определяются этой библиотекой. Как понял, определяются только те порты, которые есть в диспетчере устройств в ветке "Порты LPT и COM". А где те, которые создаются Virtual Serial Ports Emulator не знаю.

Так и должно быть.

Программа, написанная другим человеком, на делфне читает всё полностью. Может можно как-то последовательно прочитать?

В ELTIMA Virtual Serial Port Driver включите эмуляцию baudrate и будет счастье.

[silver47]

В ELTIMA Virtual Serial Port Driver включите эмуляцию baudrate и будет счастье.

На реальном железе это не вылезет?
Тогда еще вопрос, как получать состояние линий, в примере только про DSR и CTS. За библиотеку спасибо, мне кажется более логичной и удобной чем qextSerialDevice.

[kuzulis]

На реальном железе это не вылезет?

Нет, не вылезет, я только что проверил (на всякий случай).

Тогда еще вопрос, как получать состояние линий, в примере только про DSR и CTS.

Эммм.. посмотрите пример в /test/guiapp , читайте документацию и т.п.

PS: возьмите из git текущую ветку master : http://gitorious.org/qserialdevice/qserial...-tarball/master

[rcdimon]

Какую максимальную скорость передачи данных Вам удавалось получить?

Я передаю в компьютер пакеты по 9 байт. С интервалом 200 мс между пакетами. Если быстрее- программа подвисает. Программа сама по себе не большая и не сложная. Какие есть способы повысить скорость приема данных?

[kuzulis]

Какую максимальную скорость передачи данных Вам удавалось получить?

Я передаю в компьютер пакеты по 9 байт. С интервалом 200 мс между пакетами. Если быстрее- программа подвисает. Программа сама по себе не большая и не сложная. Какие есть способы повысить скорость приема данных?

1. Насчет скорости - зависит от типа UART , т.е. у разных м/сх (контроллеров и т.п.) разные верхние планки бод.
2. Самый "простой" способ - это использовать потоки (threads).

ЗЫ: Я только что сам попробовал на скорости 9600 бод передавать ~20 байт с интервалом ~10 мс и подтверждаю, тормозит .
Я посмотрю что можно предпринять (если будет время) , может что-то в коде библиотеки не то, может еще что, а может иные причины, а может так и должно быть.

ЗЫЗЫ: Должно помочь редактирование файла nativeserialengine_win.cpp (если вы используете винду).
Нужно найти метод qint64 NativeSerialEnginePrivate::nativeWrite(const char *data, qint64 len), всё в нем удалить и
оставить только это:

qint64 NativeSerialEnginePrivate::nativeWrite(const char *data, qint64 len)
{
    if (!clear_overlapped(&this->oWrite))
        return qint64(-1);

    ::DWORD writeBytes = 0;
    ::WriteFile(this->descriptor, (LPCVOID)data, (DWORD)len, &writeBytes, &this->oWrite);

    return len;
}

[rcdimon]

Я, конечно, попробую Ваш совет, но не думаю что дело в этом.

Возьмем любую другую программу для работы с ком-портом, например Terminal. Когда идет большой поток данных она начинает захлебываться и терять данные. GUI тормозит.

А, например, драйвер модема не тормозит и отлично принимает данные даже на самых высоких скоростях. Наверное следует попробовать отвязать GUI от работы с портом. Наверное в этом дело. Запускать в разных потоках.

[BRE]

kuzulis, этот метод должен возвращать реальное число записанных байт (writeBytes), а не то количество? которое хотели записать (len).

qint64 NativeSerialEnginePrivate::nativeWrite(const char *data, qint64 len)
{
    if (!clear_overlapped(&this->oWrite))
        return qint64(-1);

    ::DWORD writeBytes = 0;
    ::WriteFile(this->descriptor, (LPCVOID)data, (DWORD)len, &writeBytes, &this->oWrite);

    return len;
}

[kuzulis]

kuzulis, этот метод должен возвращать реальное число записанных байт (writeBytes), а не то количество? которое хотели записать (len).

По идее да, это так. Но на практике из-за того что нам надо знать реально сколько байт записалось - нам придется дождаться завершения операции I/O - и только после этого мы сможем узнать сколько байт записали. А ожидание I/O (через WaitSingleObject/GetOverlappedResult) - это фризы !
Т.е. WriteFile возвращается немедленно - но не факт что оно возвратит True и не факт что оно возвратит реальное кол-во записанных байт.

Поэтому всё нафик удаляем и считаем что сколько байт записали - столько и записалось! Иного способа (кроме потоков) я не вижу.

Я, конечно, попробую Ваш совет, но не думаю что дело в этом.

В этом, в этом... Не сомневайтесь. Я проверил.

ЗЫ: Все-таки придется наверное что-то с этим делать.