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

[Bepec]

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

Эх, придётся опять доставать свой полусырой класс и гусарить работу с таймаутами

Кстати, вопрос для общего развития - вроде бы точность системных таймеров в W, не позволяет высчитывать точные отрезки времени. Так же у них как бэ погрешность заявленная в 15 мс :/
Так что на высоком уровне работать с таймерами нереально.

Это так осталось или нет?

[kuzulis]

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

Послали пакет, запустили QTimer с неким интервалом ожидания ответного пакета.
Если сработал readyRead() - проверяем сколько байт принято bytesAvailable().
Если принято столько сколько ожидали, то останавливаем QTimer и обрабатываем
принятый пакет. Если принято меньше чем нужно, то ничего не делаем и ждем следующего
readyRead(). Если же сработал QTimer - значит пакет не пришел или пришел не весь,
обрабатываем эту ситуацию. Все предельно просто.

В ином случае я даже не соображу зачем оно (интервалы) нужно.

[Bepec]

Таки до 255 устройств на линии В цикле обходить надо всех. Время ожидания ответа - 16 мс.

Посчитать насколько будет увеличиваться время опроса на каждую дополнительную мс ответа может каждый

Лучший - 4-5 секунд.  Т.е. максимальное время не выдерживается.
А берём плохой результат +15 мс погрешности - 7095.

Добавляем время ответа к обоим результатам.

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

[kuzulis]

Посчитать насколько будет увеличиваться время опроса на каждую дополнительную мс ответа может каждый

А никто в здравом уме не вешает на шину/линию 255 у-в, обычно 8-10,
в ином случае нужно бить проектировщикам по рукам.

Если полудуплекс (RS485-2W), то тут ничего не поделаешь - тормоза это нормально.

Если же полный дуплекс (RS485-4W) - то запросы можно слать сразу всем девайсам,
но тут многое зависит от протокола обмена и т.п.

Но в любом случае, в QtSerialPort не будет read/write таймаутов.
Максимум о чем можно подумать - это возвращение дескриптора порта
для платформо-зависимых "тонких" настроек.

[Bepec]

Это было бы превосходно

PS когда на шине лежат средства охраны периметра, 100-150 это нормально 255 - это крайность, взятая для примера

[b-s-a]

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

Эх, придётся опять доставать свой полусырой класс и гусарить работу с таймаутами

Кстати, вопрос для общего развития - вроде бы точность системных таймеров в W, не позволяет высчитывать точные отрезки времени. Так же у них как бэ погрешность заявленная в 15 мс :/
Так что на высоком уровне работать с таймерами нереально.

Это так осталось или нет?

Можно это обойти. Для этого необходимо заюзать Perfomance Counters. В Qt 4.8 они поддержаны через QElapsedTimer. Чтобы сделать точную задержку необходимо:
1. Запустить таймер
2. Выполнить стандартное системное ожидание на время, превышающее 20 мс.
3. Крутиться в цикле, вызывая Sleep(0) до тех пор, пока не истечет время. Есть мнение, что Sleep(0) в этом случае вызывать вредно. Не уверен.

[kuzulis]

Максимум о чем можно подумать - это возвращение дескриптора порта
для платформо-зависимых "тонких" настроек.

Упс, отставить. Это тоже не поможет, т.к. read/write происходит автоматически
в/из внутренних кольцевых буферов класса некими постоянными порциями.

Например, при приходе в драйвер реально 100 байт, автоматом вызовется
ф-я ReadFile(ReadChunkSize)  (или read(ReadChunkSize)).

Где ReadChunkSize - некая константа (по умолчанию сейчас она 512 байт).

И если даже "тонко" настроить таймауты порта через дескриптор, то получится хрень.

Хотя, в принципе, все-таки дескриптор можно возвращать наверное.

[b-s-a]

Сначала, думаю, стоит придумать зачем. А уже потом возвращать.

[kuzulis]

Сначала, думаю, стоит придумать зачем. А уже потом возвращать.

Это да, согласен.

Но раз уж ты появился - плюсани в Gerrit что-ли и я патч закоммичу. 

[Bepec]

В принципе ладно, библиотечка то хорошая, негоже её портить

b-s-a насколько я помню, все (абсолютно) таймеры в системе W работают, основываясь на паре таймеров. И у этих таймеров именно погрешность в 15 мс имеется. Причём совершенно непредсказуемая задержка на разных компьютерах.

К тому же я не совсем понял логики вашего способа.
Запуск таймера, затем стандартный таймер (который  реализуется QTimer) и крутиться в Sleep(0) до истечения времени?

Тут слабое место на мой взгляд - Sleep и стандартный таймер имеют эту же погрешность в 15 мс ^_^ К тому же насколько я помню, время спячки потока опять таки имеет погрешность в зависимости от загрузки системы и приоритета процесса.

[kuzulis]

PS когда на шине лежат средства охраны периметра, 100-150 это нормально 255 - это крайность, взятая для примера

В этом случае не отвечающему устройству понижают приоритет скорости опроса (т.е реже его опрашивают или вообще выводят
из опроса на определенное время) с установкой аларма типа: "Связь с у-вом потеряна".

ЗЫ: Это конечно, если речь идет к примеру про пожарку в АСУТП.

[Bepec]

К сожалению не пожарка, а именно средства охраны периметра   И не ответ устройства хотя бы в 2 циклах расценивается как тревога - прорыв периметра/неисправность устройства/саботаж  

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

[Phoenix]

У меня mac тоже в виртуалке. Программы собрались, а открывать порт не хотят. В linux такое тоже было пока пользователя не добавил в нужную группу, а в маке не могу найти где это. Кстати, сначала программа выдает ошибку с кодом 10, а при повторной попытке подключиться - с кодом 2.

[Phoenix]

Посмотрел права на файл порта /dev/cu.serial1: crw-rw-rw. Должно работать, но не работает. Заметил в /dev еще один похожий файл: tty.serial1. Может не правильно определяется файл устройства?

[kuzulis]

В linux такое тоже было пока пользователя не добавил в нужную группу, а в маке не могу найти где это.

Фиг его знает как там в маке, но попробуй через su (или sudo) запустить Terminal.

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

Если честно, то не подскажу в чем дело. Код 2 это PermissionDeniedError.
Возможно ты неправильно ассоциировал порт в виртуалке (или вообще не настраивал его),
и что за виртуалка? Если честно, то я не проверял работу с built-in портами в Маке (или проверял - не помню).
Но точно проверял с USB/Serial шнурками - вроде работает.

Попробуй подключи в свой проект (или в пример Terminal) библиотеку напрямую через src-lib.pri и в отладчике
посмотри в файле serialport_unix.cpp как там в методе open() происходит открытие порта, на каком этапе фэйлится
и выведи номер ошибки errno.

Заметил в /dev еще один похожий файл: tty.serial1. Может не правильно определяется файл устройства?

Ну попробуй открыть tty.serial1, хотя правильнее все-таки cu.serial1.