Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[kuzulis]

Отписываюсь. Попробывать так и не удалось. Я использовал библиотеку 0.2.0. Там нет 230400. Обновился до 0.4.0. Там в справке не увидел 230400, но в *.h вроде есть. но слишлом уж 0.4 отличается от 0.2. Код не компиляется. Придется код перелопатить. Первый косяк... в 0.2 была функция
bool AbstractSerial::setCharIntervalTimeout(int), в 0.4 такой нет, вместо неё есть void AbstractSerial::setCharIntervalTimeout(int). Смотрю хелпник
функция по объявлению возвращаяет void, а в хелпе "Возвращает: False в случае ошибки. Не понятно??? могу конечно её использовать как void, но вдруг это ошибка и в следующем релизе эта функция уже будет bool.

Я не успел добавить это в Ru документацию. Кое где будут огрехи.

Допустим при  открытии/закрытии не нужно не чего делать, а вот при ошибках конфигурировании устройства или при ошибках I/O нужно что-то сделать и пользователя сообщением уведомить. Как отличить излучился сигнал из-за ошибки или из-за открытия/закрытия? Парсить QString&  status?

В текущей реализации особого смысла в возвращении ошибок от установок таймаута символа нет.
Т.е. таймауты символов можно применять только в режиме Unbuffered. И то , если setTotalReadConstantTimeout(int msecs) ,  msecs = -1 (т.е режим автоматического вычисления общего таймаута пакета данных).
В общем, если оч нужен таймаут - то используйте setTotalReadConstantTimeout - оно установит таймаут не на символ - а на весь читаемый пакет, что ИМХО, более правильно и быстрее будет работать/читать.
Минимальный размер читаемого пакета 256 байт - поэтому минимальный таймаут пакета не может быть ниже чем для 256 байт. (хотя и больше тоже не может быть)
Поэтому если у вас размер передаваемых данных < 256 байт - то ставьте смело или 0 или 1 мс и не заморачивайтесь.
А если > 256 байт - то рассчитайте общий таймаут на 256 байт (с учетом скорости, кол-ва бит данных, стоп-бит и т.п.).

А чтобы не заморачиваться с расчетом - делайте setTotalReadConstantTimeout(-1), а  setCharIntervalTimeout не трогайте вообще. И оно само подберет "оптимальный" таймаут. Т.е. если будете менять скорость и т.п. то не нужно переустанавливать таймауты.

ЗЫ:
Там с таймаутами сейчас полный песец - хотелось универсальности - а получилось хз что.
В общем, не обращайте внимание на ошибки от таймаутов вообще, считайте что оно всегда true!

[juvf]

моё преложение не собирается.

Собрал serialDevice 0.4.0. В своём .pro прописал

Код:

INCLUDEPATH += $$(QTPATH)/serportM04/src/qserialdevice \
	$$(QTPATH)/serportM04/src/qserialdeviceenumerator

QMAKE_LIBDIR += $$(QTPATH)/serportM04/src/build/release

LIBS += -lqserialdevice

QTPATH = d:/soft/Qt/
при компиляции получаю ошибки

Код:

d:/soft/Qt/serportM04/src/build/release/libqserialdevice.a(serialdeviceenumerator_p_win.o):serialdeviceenumerator_p_win.cpp:(.text+0x89a): undefined reference to `_imp__SetupDiGetDeviceRegistryPropertyW@28'

d:/soft/Qt/serportM04/src/build/release/libqserialdevice.a(serialdeviceenumerator_p_win.o):serialdeviceenumerator_p_win.cpp:(.text+0xfb3): undefined reference to `_imp__SetupDiGetClassDevsW@16'

d:/soft/Qt/serportM04/src/build/release/libqserialdevice.a(serialdeviceenumerator_p_win.o):serialdeviceenumerator_p_win.cpp:(.text+0x100a): undefined reference to `_imp__SetupDiEnumDeviceInfo@12'

d:/soft/Qt/serportM04/src/build/release/libqserialdevice.a(serialdeviceenumerator_p_win.o):serialdeviceenumerator_p_win.cpp:(.text+0x1170): undefined reference to `_imp__SetupDiOpenDevRegKey@24'

d:/soft/Qt/serportM04/src/build/release/libqserialdevice.a(serialdeviceenumerator_p_win.o):serialdeviceenumerator_p_win.cpp:(.text+0x27de): undefined reference to `_imp__SetupDiDestroyDeviceInfoList@4'

collect2: ld returned 1 exit status

mingw32-make[1]: *** [debug/TestProg.exe] Error 1

mingw32-make: *** [debug] Error 2

Как это победить?

[kuzulis]

Ох, juvf, juvf ....

Смотри примеры и найти отличия в *.pro файлах примеров и твоего.
ЗЫ: Неужто так лень разобраться? Или всё нужно разжевывать и в рот класть?

[Edynchik]

А где можно взять последнюю версию Вашей библиотеки...и желательно с примерами....?

[b-s-a]

http://gitorious.org/qserialdevice/

[juvf]

Код:

char command[4];
AbstractSerial *port;
...
port->write(command, 4);
...

write в таком коде глючит. Бывалые подсказывают, что в порт нада писать то 1 байту, иначе масдай. Это ..... особенности компорта? Или это баг в реализации? должна AbstractSerial::write(command, 4) гарантированно  работать?

[kuzulis]

write в таком коде глючит. Бывалые подсказывают, что в порт нада писать то 1 байту, иначе масдай. Это ..... особенности компорта? Или это баг в реализации? должна AbstractSerial::write(command, 4) гарантированно  работать?

Ну что за чушь... Возьми примеры \test\guiapp , подправь и проверь.

/test/guiapp/mainwidget.cpp

Код

C++ (Qt)
void MainWidget::procSerialDataTransfer(const QByteArray &data)
{
    char buf[4];
    buf[0] = 'a';
    buf[1] = 'b';
    buf[2] = 'c';
    buf[3] = 'd';
 
    if (this->serial && this->serial->isOpen())
        this->serial->write(buf, 4);
}
 

[juvf]

Ну что за чушь...

Да сам удивился - что за чушь. В прикреплении тест показывающий эту "чушь" в  qserialdevice.

[kuzulis]

2 juvf, твой код особо не смотрел, наверняка у тебя где-то ошибка, а исправлять твои ошибки не имею желания.

Я специально видоизменил /examples/anymaster так, чтобы он постоянно слал: 03 FC 41 00.

Код

C++ (Qt)
void AnyMaster::transaction()
{
    start(false);
 
    char tx_packet[4];
    tx_packet[0] = 0x03;
    tx_packet[1] = 0xFC;
    tx_packet[2] = 0x41;
    tx_packet[3] = 0x00;
 
    qint64 r = port->write(tx_packet, 4);
    if (r == 4) {
        qDebug() << "Writed: " << r << " bytes";
        if ((port->bytesAvailable() > 0) || port->waitForReadyRead(responseTimeout)) {
            char rx_packet[258];
            r = port->read(rx_packet, 258);
            qDebug() << "Readed: " << r << " bytes";
        }
        else {
            qDebug() << "Response timeout.";
        }
    }
    else qDebug() << "Bytes writed small: " << r;
 
    start(true);
}
 

Далее, видоизменил /examples/reader так, чтобы он принимал пакет и проверял его и при ошибке в принятых байтах - сыпал в консоль предупреждения.

Код

C++ (Qt)
        char rx_packet[4];
        /* 5. Fifth - you can now read / write device, or further modify its settings, etc.
        */
        while (1) {
            if ((port->bytesAvailable() > 0) ||  port->waitForReadyRead(rrto)) {
                qint64 r = port->read(rx_packet, 4);
                if (4 != r)  {
                    qDebug() << "Readed fail: " << r << " bytes";
                }
                else {
                     quint32 val = quint8(rx_packet[3])
                             | (quint8(rx_packet[2]) << 8)
                             | (quint8(rx_packet[1]) << 16)
                             | (quint8(rx_packet[0]) << 24) ;
 
                    if (0x03FC4100 != val) {
                        qDebug() << "Readed fail: bad packet : val = " << quint32(val);
                    }
                    //else { qDebug() << "Ok"; }
                }
            }
            else {
                qDebug() << "Timeout read data in time : " << QTime::currentTime();
            }
        }//while
 

Вот, уже сижу 2 часа и жду, когда же оно мне скажет что принято что-то не то. Так что ищи ошибку(ки) у себя.

[juvf]

не поленился, так же подправил твои примеры. запустил -  .... как швейцарские часы. ни одного сбоя. стал сверять твой пример со своим. исходники, pro ... Не нашел отличий. Запустил ещё раз твои примеры ... ни прошло и минуты - посыпались баги. Стал экспериментировать .... то сбои постоянно иду, то перезапущу.... упс, нет сбоев.

Вобщем нашел закономерность. У меня в компе есть 2 ком порта. COM1 на материнской плате, "честный" компорт. СОМ7 - преобразователь USB<->RS-232 на чипе prolific. Если мастеру назначаю СОМ1, т.е. "честный", а редэру СОМ7, то все работает без сбоев. Но если мастеру указываю порт СОМ7, а редэру СОМ1 - то ошибки долго не заставляют ждать. Сыпятся.
По хорошему надо бы выкинуть этот prolific и поставить нормальный преобразователь, типа ftdi, но дело в том, что подобный баг наблюдал и с преобразователями на чипах ftdi, и на USB GSM модемах.

[Ubuntu_linux]

Кто-то прикручивал для linux порт rfcomm ? (конект к телефону по Bluetooth)
 

добавил аналогичные (tty) строки для rfcomm в serialdeviceenumerator_p_unix.cpp
 

И удалось завести rfcomm , дело , похоже , в правах доступа на rfcomm.... 

[kuzulis]

Вобщем нашел закономерность. У меня в компе есть 2 ком порта. COM1 на материнской плате, "честный" компорт. СОМ7 - преобразователь USB<->RS-232 на чипе prolific. Если мастеру назначаю СОМ1, т.е. "честный", а редэру СОМ7, то все работает без сбоев. Но если мастеру указываю порт СОМ7, а редэру СОМ1 - то ошибки долго не заставляют ждать. Сыпятся.
По хорошему надо бы выкинуть этот prolific и поставить нормальный преобразователь, типа ftdi, но дело в том, что подобный баг наблюдал и с преобразователями на чипах ftdi, и на USB GSM модемах.

Ага... Ок, проверю это дело... (Уменя в тестах мастер был "мамкин" порт, а слейв - "пролифик" PL2303)  

Кто-то прикручивал для linux порт rfcomm ? (конект к телефону по Bluetooth)
 
добавил аналогичные (tty) строки для rfcomm в serialdeviceenumerator_p_unix.cpp
И удалось завести rfcomm , дело , похоже , в правах доступа на rfcomm....  

Так значит у тебя заработало то что я советовал тебе сделать? Значит мне можно это коммитить в Git?

[Ubuntu_linux]

Да,  вроде все работает, enumerator  выводит инфу о rfcomm, примеры тоже работают.
Но чтоб получить доступ к   порту надо бить под рутом! , ето как то можно исправить сделав группу юзеров которым можно юзать порт rfcomm.

Но мне надо потестить более детально, чтоб делать финальные выводы. 

[kuzulis]

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

В принципе да, можно попробовать добавить пользователя в группы: tty, uucp, serial и т.п. по смыслу (в зависимости от типа дистрибутива Linux)
См тут http://www.prog.org.ru/topic_16678_0.html

[kuzulis]

Вобщем нашел закономерность. У меня в компе есть 2 ком порта. COM1 на материнской плате, "честный" компорт. СОМ7 - преобразователь USB<->RS-232 на чипе prolific. Если мастеру назначаю СОМ1, т.е. "честный", а редэру СОМ7, то все работает без сбоев. Но если мастеру указываю порт СОМ7, а редэру СОМ1 - то ошибки долго не заставляют ждать. Сыпятся.
По хорошему надо бы выкинуть этот prolific и поставить нормальный преобразователь, типа ftdi, но дело в том, что подобный баг наблюдал и с преобразователями на чипах ftdi, и на USB GSM модемах.

Ага... Ок, проверю это дело... (Уменя в тестах мастер был "мамкин" порт, а слейв - "пролифик" PL2303)  

Не подтверждаю "ошибки". У меня работает как часы.
OS: Win7 x32
Шнурок: PL2303
Драйвер:
- поставщик Prolific
- дата разработки 19.11.2009
- версия 3.3.10.140

Да,  вроде все работает, enumerator  выводит инфу о rfcomm, примеры тоже работают.
Но чтоб получить доступ к   порту надо бить под рутом! , ето как то можно исправить сделав группу юзеров которым можно юзать порт rfcomm.

Но мне надо потестить более детально, чтоб делать финальные выводы. 

Всё, добавил в Git.