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

[Edynchik]

Потому, что библиотека проверяется (проверялась) мною только с использованием компилятора MinGW - там всё нормуль.
В MSVC же нету данного файла, поэтому рекомендую скачать не 0.4.0 версию, а более обновленный вариант тут:
https://gitorious.org/qserialdevice/qserialdevice/archive-tarball/master
И все будет путЁм.

сообщение полный оффтоп,но все таки спрошу....был установлен qt creator-инструментарий как я понимаю там был MinGW, потом я установил VS2008 add-in и инструментарий стал Microsoft Visual C++ и не меняется...можно с этим что то сделать...

[kuzulis]

сообщение полный оффтоп,но все таки спрошу....был установлен qt creator-инструментарий как я понимаю там был MinGW, потом я установил VS2008 add-in и инструментарий стал Microsoft Visual C++ и не меняется...можно с этим что то сделать...

Ну а собираете в итоге чем MinGW или студийным компилером?

Попробуйте пошаманить в системных переменных окружения, может там что лишнее прописано и это удалить.

Да и вообще, ИМХО, удалите (если имеется) из системной PATH все пути к Qt, компиляторам и т.п. , может поможет.

[asvil]

Добрый день. Понадобилась Ваша библиотека в проекте с cmake системой сборки. Позволю себе несколько подредактировать Ваши проектные файлы.

Итак, цель: использовать Вашу библиотеку в виде исходных файлов, а не в виде готовой скомпилированной.

Для этого хочу сделать addSubdirectory(../common/qserialdevice ${CMAKE_CURRENT_BINARY_DIR}/qserialdevice). Такая расширенная форма команды используется из-за более удобного расположения исходных текстов библиотеки уровнем выше текущего проекта.

Теперь хочу target_link_libraries(somexe qserialdevice). На релиз сборке все ok, но с дебагом проблемы. Это меня и сподвигло заглянуть в Ваши симэйки.

src/CMakeLists.txt

Код:

include_directories( ${CMAKE_CURRENT_BINARY_DIR}
                     ${QT_INCLUDES} 
)

Можно заменить на

Код:

set(CMAKE_INCLUDE_CURRENT_DIR T)

QT_INCLUDES включать не надо это происходит неявно во время include(${QT_USE_FILE})

----


Добавляем платформоспецифичную папку с заголовочными файлами.

Код:

# qplatformdefs
include_directories(${QT_MKSPECS_DIR}/default)

----------

Код:

set( QT_DONT_USE_QTGUI 1 )

Нужно делать до

Код:

include( ${QT_USE_FILE} )

Или же это можно заменить таким образом:

Код:

find_package( Qt4 COMPONENTS QtCore REQUIRED )

Отныне QT_LIBRARIES переменная будет содержать только то, что Вы захотели.

--------------

Код:

    set ( LIBRARY_OUTPUT_PATH 
        ${PROJECT_BINARY_DIR}/debug
        CACHE string "Path to output library binaries."
    )

Deprecated переменная. Кроме того я настраиваю размещение всех библиотек в самом верхнем "executable" проекте. Нижние проекты не должны знать, куда им собираться. Это более удобно в разросшихся проектах.

------------

Код:

set( QT_DEFINITIONS
    -DUNICODE
    -DQT_NO_DEBUG
    -DQT_THREAD_SUPPORT
)
add_definitions( ${QT_DEFINITIONS})

Можно убрать.

  QT_DEFINITIONS   Definitions to use when compiling code that uses Qt.
                   You do not need to use this if you include QT_USE_FILE.
                   The QT_USE_FILE will also define QT_DEBUG and QT_NO_DEBUG
                   to fit your current build type.  Those are not contained
                   in QT_DEFINITIONS.

Код:

if(BUILD_SHARED)
    add_library( ${LIB_TARGET} SHARED ${QSERIALDEVICE_SRCS} ${QSERIALDEVICE_MOCS} )
else()
    add_library( ${LIB_TARGET} STATIC ${QSERIALDEVICE_SRCS} ${QSERIALDEVICE_MOCS} )
endif()

Можно заменить на

Код:

set(SERIALDEVICE_BUILD_TYPE "SHARED") # or STATIC
add_library( ${PROJECT_NAME} ${SERIALDEVICE_BUILD_TYPE} ${QSERIALDEVICE_SRCS} ${QSERIALDEVICE_MOCS} )

-----------

Код:

if( CMAKE_BUILD_TYPE STREQUAL "Debug" )
    set ( LIBRARY_OUTPUT_PATH 
        ${PROJECT_BINARY_DIR}/debug
        CACHE string "Path to output library binaries."
    )
    set( LIB_TARGET "qserialdeviced" CACHE string "Name of the output library binaries." )
else()

Можно заменить на

Код:

set(CMAKE_DEBUG_POSTFIX d)

-----------

Теперь касаемо ${LIB_TARGET}. У меня нету доступа сверху к Вашей переменной поэтому, хотелось бы так.

Код:

target_link_libraries(${PROJECT_NAME}  ${QT_LIBRARIES} ${ADDITIONAL_LIBRARY})

Переменная PROJECT_NAME содержит то, что Вы в самом начале передали в функцию project(QSerialDevice).
Теперь я могу target_link_libraries(somexe QSerialDevice). И линковка у меня пройдет при любом режиме и любых префиксах/постфиксах библиотеки.

---------

Вообщем-то вопрос ко всем. Зачем делить сборку проекта на папки debug/release, если можно задать префикс/постфикс для всех бинарных файлов проекта.
Для executable, например:

Код:

set_target_properties(exetarget PROPERTIES DEBUG_POSTFIX "_debug" VERSION ${VERSION})

---------

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

[kuzulis]

Прошу прощения что долго не отвечал: был в отпуске

Хорошо, Михаил, я видел твой мерж на гиториусе.
Пусть он пока там повисит, т.к. мне пока некогда разбираться что там и как, но, думаю, ты прав: с конфигурацией для CMake нужно что-то делать, т.к. я делал её в попыхах (по - быстрому) и особо не заморачивался что там и как.
Типо я ждал пока кто-то не предложит чего получше, спасибо!

Вообщем-то вопрос ко всем. Зачем делить сборку проекта на папки debug/release, если можно задать префикс для всех бинарных файлов проекта.

Да, и я тогда тоже жду комментариев от заинтересованных лиц по этому вопросу.

[kuzulis]

В новой версии Qt 4.7.3 из QtSDK 1.1.1 отсутствуют приватные модули типа qwineventnotifier_p.h, в следствии чего библиотека не компилиться. Можно как-то скомпилировать?

1. Можно попробовать взять эти приватные файлы из исходников и попробовать их как-нибудь подключить/поизвращаться, но при этом,
 скорее всего оно потянет за собой и другие приватные хейдеры.
2. Но лучше всего собрать саму Qt из исходников и тогда без проблем компилить.

Имхо, 2-й вариант предпочтительней .

Или будем ждать выхода новой версии QSerialDevice?

А толку то? Библиотека использует некоторые приватные классы и без них не будет работать.
Городить что-то свое (уведомитель - синглтон), завязанное на отдельном потоке не хочется (хотя, мысли в принципе имеются, но оно пока не нужно).
Так что пусть оно как есть так и остается.

[asvil]

А я таки уже говорил, что эти приватные заголовочники и секции классов - массонский заговор.

[kuzulis]

А я таки уже говорил, что эти приватные заголовочники и секции классов - массонский заговор.

Да понятно это всё.
Но без них невозможно пока что в винде сделать что-то аналогичное QSocketNotifier, только для последовательного порта (естественно, без всяких левых тредов и т.п.).
Я то думал, что тролли/нокия запилят(интегрируют) поддержку последовательных портов в Qt (и тогда проблемы такой не было бы) - но теперь понимаю что всем на всё абсолютно по-барабану. 

Qt -RIP 

[b-s-a]

Я то думал, что тролли/нокия запилят(интегрируют) поддержку последовательных портов в Qt (и тогда проблемы такой не было бы) - но теперь понимаю что всем на всё абсолютно по-барабану. 

Qt -RIP 

Не стоит так паниковать. Твою реализацию вряд ли интегрируют (много лишних методов и слотов (или принимающих странные параметры), невнятная работа с ошибками и событиями). А свою писать им некогда.
Думаю, если задаться целью, можно привести библиотеку к пригодному для включения в Qt виду.

[pastor]

Думаю, если задаться целью, можно привести библиотеку к пригодному для включения в Qt виду.

+1

Я бы с удовольствием поучавстовал

[asvil]

А какой вид пригодный? У kuzulis-a интерфейс родился из того как ведут себя операционки, а не из того как хочет пользователь-программист?

[b-s-a]

А какой вид пригодный?

Посмотри уже имеющиеся в Qt классы схожей тематики (в частности, наследники QIODevice). В них, например, нет методов установки свойств через их текстовое представление.

Например, что лично мне не нравится:
1. какой-то жуткий enum Status вытащен наружу, да еще и в public (который используется только внутри класса). И ошибки и не ошибки в одном флаконе. Причем, константы типа ENoneOpen просто убивают.
2. слишком длинное название для свойств порта: FlowControlOff, ParitySpace (имхо, было бы более наглядно: NoParity, Space, Mark, Even, Odd, NoFlowControl, Hardware (или CtsRts), Software (или XonXoff))
3. наличие не кроссплатформенных особенностей, эмуляция которых невозможна (я прав?): StopBits1_5
4. огромный набор констант скоростей передачи данных. Причем, он далеко не общий для всех ОС. Имхо, лучше оставить минимум наиболее стандартных. Остальное, пусть задается прямым указанием скорости в бодах.
5. установка свойств (скорость, четность, стопы) через строки
6. нестатические методы типа QMap<AbstractSerial::StopBits, QString> stopBitsMap() const. Нахрена? Не проще ли сделать пару статических методов (или вообще внешних функций) типа: QString stringFromParity(Parity p)? Не надо затачиваться исключительно под диалог настроек порта. Он вызывается значительно реже, чем все остальное.
7. название класса AbstractSerial предполагает, что от него необходимо наследоваться (мы это уже обсуждали). Имхо, лучше использоваться SerialPort или SerialDevice.
8. я не считаю, что стоит добавлять время ожидания по умолчанию: bool waitForReadyRead(int msecs = 5000). Так как базовый класс его не имеет. Может вызвать ошибку, при смене типа указателя на QIODevice*.

У kuzulis-a интерфейс родился из того как ведут себя операционки, а не из того как хочет пользователь-программист?

Это вопрос или утверждение? Не считаю правильным делать так, как это сделано в ОС. Особенно, в Windows (ClearCommError - отличный пример того, как делать не стоит).

[Ubuntu_linux]

А какой вид пригодный?

Посмотри уже имеющиеся в Qt классы схожей тематики (в частности, наследники QIODevice). В них, например, нет методов установки свойств через их текстовое представление.

Например, что лично мне не нравится:
2. слишком длинное название для свойств порта: FlowControlOff, ParitySpace (имхо, было бы более наглядно: NoParity, Space, Mark, Even, Odd, NoFlowControl, Hardware (или CtsRts), Software (или XonXoff))
4. огромный набор констант скоростей передачи данных. Причем, он далеко не общий для всех ОС. Имхо, лучше оставить минимум наиболее стандартных. Остальное, пусть задается прямым указанием скорости в бодах.

7. название класса AbstractSerial предполагает, что от него необходимо наследоваться (мы это уже обсуждали). Имхо, лучше использоваться SerialPort или SerialDevice.

С длинами констант я не согласен, так нагляднее. А так меня все устаревает.

[kuzulis]

1. какой-то жуткий enum Status вытащен наружу, да еще и в public (который используется только внутри класса). И ошибки и не ошибки в одном флаконе. Причем, константы типа ENoneOpen просто убивают.

Да я сам в шоке, уже и не помню что я хотел сделать.
Хорошо, давайте тогда определяться:
1. Какие из ошибок стоит использовать и выводить их текстовое представление? Давайте составим перечень.
2. Нужно ли информировать приложение об изменении статуса устройства (не ошибок, а любых изменениях в конфигурации)?
Т.е. делать ли "нативную" поддержку классом уведомлений (как сейчас сделано через signalStatus() ) или выкинуть это нафик?

2. слишком длинное название для свойств порта: FlowControlOff, ParitySpace (имхо, было бы более наглядно: NoParity, Space, Mark, Even, Odd, NoFlowControl, Hardware (или CtsRts), Software (или XonXoff))

Хорошо, можно к примеру сократить так:
1.

Код

C++ (Qt)
    enum BaudRateDirectionFlag {
        DirInput,
        DirOutput,
        DirAll
    };
 

2.

Код

C++ (Qt)
    enum BaudRate {
        Baud50,
        ...
        Baud115200
    };
 

3.

Код

C++ (Qt)
    enum DataBits {
        Undefined = -1, 
 
        Data5,  
        Data6, 
        Data7,  
        Data8, 
    };
 

4.

Код

C++ (Qt)
    enum Parity {
        Undefined = -1,   
 
        None, 
        Odd,  
        Even,  
        Mark,  
        Space,
    };
 

5.

Код

C++ (Qt)
    enum StopBits {
        Undefined = -1, 
 
        One,      
        Half,    
        Two,     
    };
 

6.

Код

C++ (Qt)
    enum Flow {
        Undefined = -1,  
 
        Off,        
        Hardware,   
        Software,    
    };
 

3. наличие не кроссплатформенных особенностей, эмуляция которых невозможна (я прав?): StopBits1_5

ИМХО, ну тут пусть остается, т.к. в противном случае Windows пользователи "завоют".

4. огромный набор констант скоростей передачи данных. Причем, он далеко не общий для всех ОС. Имхо, лучше оставить минимум наиболее стандартных. Остальное, пусть задается прямым указанием скорости в бодах.

Хорошо, огласите минимум.

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

Согласен, можно убрать, т.к. пользователи сами могут реализовать необходимый функционал.

6. нестатические методы типа QMap<AbstractSerial::StopBits, QString> stopBitsMap() const. Нахрена?

Согласен, можно убрать. Просто меня просили добавить эти методы (но я так и не понял зачем они понадобились). 

7. название класса AbstractSerial предполагает, что от него необходимо наследоваться (мы это уже обсуждали). Имхо, лучше использоваться SerialPort или SerialDevice.

Можно и так.

8. я не считаю, что стоит добавлять время ожидания по умолчанию: bool waitForReadyRead(int msecs = 5000). Так как базовый класс его не имеет. Может вызвать ошибку, при смене типа указателя на QIODevice*.

Не проблема.

У kuzulis-a интерфейс родился из того как ведут себя операционки, а не из того как хочет пользователь-программист?

Это вопрос или утверждение? Не считаю правильным делать так, как это сделано в ОС. Особенно, в Windows (ClearCommError - отличный пример того, как делать не стоит).

Я тоже недопонял что имелось ввиду.

[asvil]

Это я провоцировал.

[b-s-a]

1. В текст надо пихать все ошибки, которые может определить пользователь класса. Думаю, это все ошибки.
2. Ничего не имею против информирования о статусах. Но, в тоже время, не вижу практически никакой реальной пользы от этого (разве только для отладки, но оно того стоит?). Все необходимые сигналы (кроме очень специфичных для COM) уже есть в QIODevice.

Сокращение меня почти полностью устраивает, но вот может "направление" сократить до Input, Output и Input|Output? Пусть даже используя константы QIODevice. Но такие варианты как Off и None мне не нравятся. Я тоже рассматривал эти варианты, но пришел к выводу, что надежней использовать NoParity и NoFlowControl, так как не перепутаешь. А One/Two/Half заменить на Stop1, Stop2, Stop1_5, чтобы была однообразность с размером данных.

Кстати, предлагаю использовать в качестве значений констант более юзабельные числа (благодаря чему значительно можно оптимизировать низкоуровневую работу с портом):
NoParity = 0, Even = 2, Odd = 3, Space = 4, Mark = 5
Data5 = 5, Data6 = 6, Data7 = 7, Data8 = 8
Stop1 = 1, Stop2 = 2, Stop1_5 = 3

Список скоростей можно определить путем пересечения множеств стандартных скоростей *nix и Windows:

Код

C++ (Qt)
enum BaudRate {
/*    Baud75 = 75,
    Baud110 = 110,
    Baud134 = 134,
    Baud150 = 150,
    Baud300 = 300,
    Baud600 = 600, */
    Baud1200 = 1200,
    Baud1800 = 1800,
    Baud2400 = 2400,
    Baud4800 = 4800,
    Baud9600 = 9600,
    Baud19200 = 19200,
    Baud38400 = 38400,
    Baud57600 = 57600,
    Baud115200 = 115200
};

Часть скоростей закомментировал, так как не уверен в их необходимости в реальных приложениях.

Кстати, напоминаю, что остались еще названия линий. Их я предлагаю сократить так:

Код

C++ (Qt)
enum Line {
        Le	= 0x01,     //Line enable (in)
        Dtr	= 0x02,     //Data Terminal Ready (out)
        Rts	= 0x04,     //Request To Send (out)
        St	= 0x08,     //Secondary TX (out)
        Sr	= 0x10,     //Secondary RX (in)
        Cts	= 0x20,     //Clear To Send (in)
        Dcd	= 0x40,     //Data Carrier Detect (in)
        Ri	= 0x80,     //Ring Indicator (in)
        Dsr	= Le        //Data Set Ready (in) alias for Le
};
Q_DECLARE_FLAGS(Lines, Line)

Теперь немного о улучшении функциональности.
Что сейчас происходит в случае ошибки четности/целостности пакета? А мне бы хотелось иметь возможность настраивать поведение. На мой взгляд возможны варианты:
1. Пропустить "битые данные" (т.е. "их не было")
2. Передать 0 вместо битых данных
3. Игнорировать ошибку (т.е. как-будто ошибки не было)
4. Прервать чтение прямо перед указанным "битым" байтом, выставить ошибку и специальный статус (ParityError, например). Последующее чтение примет первым байтом этот "битый" в том виде, в котором он получен (аналогично п 3) и остальные до следующего "битого", если есть.