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

[kuzulis]

устанавливаются предопределенные значения в корне не верно

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

В конце концов порешили, что так тому и быть, и теперь QSP::open()
откроет порт с 9600 8 N 1, если до этого не были установлены никакие другие
настройки. И это корректно с т.з. ООП.

Хочешь свои настройки - устанавливай их до открытия; хочешь чтобы менялись
в процессе работы - меняй их у открытого девайса.  

Хочешь чтобы просто открылось - нельзя так. Все, точка.

Логика проста. 

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

Как это не должен знать? Это проблемы того софта.

Если софтина работает с у-вом,
то она должна знать параметры для работы с у-вом и сама его конфигурить. Она берет
над ним контроль, а не "Дядя Вася" откуда-то.

UNIX-way не всегда есть тру-way (оно устарело на 50 лет уже).  

Это можно решить флагом конструктора, например DefaultSettings/SystemSettings.

Не, никто не будет заморачиваться с этим, и я тоже.

PS: Всем не угодишь, а тратить личное время мне уже надоело на все эти потехи, увы.

[poru]

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

Именно тогда вам надо было сказать:

нельзя так. Все, точка

Хочешь свои настройки - устанавливай их до открытия; хочешь чтобы менялись
в процессе работы - меняй их у открытого девайса. 

Хочешь чтобы просто открылось - нельзя так. Все, точка.

Логика проста.

"У Вас тут пахнет всем чем угодно, но только не колбасой" (логикой)

Как это не должен знать? Это проблемы того софта.

Если софтина работает с у-вом,
то она должна знать параметры для работы с у-вом и сама его конфигурить. Она берет
над ним контроль, а не "Дядя Вася" откуда-то.

Вы же прекрасно поняли, что в описанном случае софт работает не с устройством, а с хендлом, а вот на что хендл указывает знает "Дядя Вася". А в примере "echo hello >> com1" по вашему команда echo должна настраивать порт?

Не, никто не будет заморачиваться с этим, и я тоже.
PS: Всем не угодишь, а тратить личное время мне уже надоело на все эти потехи, увы.

Создается впечатление, прошу прощения за грубость, что Вам западло ввести еще одну переменную и проверить ее состояние перед вызовом initialize(). Любители дефолтов ничего не теряют.

[Bepec]

Тролль?
Библиотека QSerialPort кроссплатформенная.
Поддержка фишки одной ОС, которая отсутствует в других - нерациональное решение

[Old]

Поддержка фишки одной ОС, которая отсутствует в других - нерациональное решение

Это вы про какую фишку сейчас говорите? И в какой ОС ее нет?

[kuzulis]

Именно тогда вам надо было сказать:

Ага, ну конечно...

"У Вас тут пахнет всем чем угодно, но только не колбасой" (логикой)

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

Этот автодетект нужен был чтобы после открытия обновить внутренние проперти объекта.
Чтобы, например, дальнейший вызов QSP::baudRate() показал именно текущую скорость,
а не какой-то "левак", но он не всегда работал как ожидалось.

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

Было и еще что-то я уже и не помню.

Вы же прекрасно поняли, что в описанном случае софт работает не с устройством, а с хендлом, а вот на что хендл указывает знает "Дядя Вася".

Опять же, это все частный случай, а не общий. Это "фишка" конкретной платформы, мировосприятия.

А в примере "echo hello >> com1" по вашему команда echo должна настраивать порт?

А оно "echo" для этого и не предназначено.

Ну, есть у меня только "echo" и что с нее толку, если я не знаю,
режим работы порта... И мне, что, перебирать в терминалке на другом конце все возможные
варианты скоростей и всего прочего, чтобы получить это "hello" ?

Ну, я ж и грю, ох уж этот Юникс-вэй... кто-то конфигурит девайс, кто-то с него читает, кто-то в него пишет, кто-то его лижет.
Старичок должен идти на покой. 

Создается впечатление, прошу прощения за грубость, что Вам западло ввести еще одну переменную и проверить ее состояние перед вызовом initialize(). Любители дефолтов ничего не теряют.

А мне этого не надо, меня все устраивает. Код открыт, вперед. 

[lit-uriy]

>>Вы же прекрасно поняли, что в описанном случае софт работает не с устройством, а с хендлом, а вот на что хендл указывает знает "Дядя Вася".
Не понимаю Дедевасиной проблемы, он что порт не в силах был настроить?
указатель на QSerialPort, открытый и настроеный, пусть и передаёт.

[kuzulis]

Не, как я понял, суть в другом.

1. Бородатый Дядя Вася в потрепаном свитаре настроил порт  /dev/ttyS0 через stty на 115200 бод.

2. Девочка Лиза делает echo "Hello, Petya" >> /dev/ttyS0

3. Мальчик Петя запустил cat  /dev/ttyS0 или другую юникс-вей программулинку и
читает данные в консольке, и видит: "Hello, Petya". Он рад и счастлив новым знакомствам.

4. Тут Марь Иванна (уборщица) протерла тряпкой клавиатуру у ПиСи,
и нечаянно запустила программку, которая открывает порт через QSP..

И оп-ля, мальчик Петя плачет, у него больше в консольке ничо не отображается,
QSP скинул настройки на 9600 бод (злая Марьиванна все паламала).

Пичаль-беда... Теперь Мальчик Петя не познакомится с девочкой Лизой, не возьмет
ее замуж.. Эффект бабочки прям какой-то... Во всем виновата Марь Иванна.

Мальчику Пете надо конфетку.

5. Мальчик Петя позвал Дядю Васю, и попросил помочь.. "Не переживай, Петя", крякнул Василий,
и жирными пальцами (от селедки) набрал stty 115200.. "Я линухойд", сказал он, я все умею.

6. И, о, чудо, Петя снова видит Лизины "смски"

7. Но тут Марь-ванна все просекла, дала по шапке Василию, а грязной тряпкой
погнала мальчика Васю и Лизу вон, из помещения - в парк! Негоже молодежи
сидеть в помещении, пусть кушают морожко в парке!

ЗЫ: Все в этом рассказе - чисто гипотетическая и фантазийно-фантазийная сцена,
нигде не пересекающаяся с реальностью, все персонажи вымышленные.

[poru]

Спасибо, повеселили.
У Вас волшебная юмористическая аналитичность.
Однако вспоминается что-то из былого:
 - времена телеграфа - "– Давай, работай, – обратился Будённый к телеграфисту. Телеграфист быстро отстучал телеграфным ключом...";
 - появление телефонов - "Алло, коммутатор? Будьте добры, соедините...";
 - радиопередатчик - "Он отдал сообщение радисту: "Зашифруйте и передайте на частоте...";
 - директор секретарше, забыв номер - "Соедините меня с финансовым отделом!";
 - эпоха интернета - "Пожалуйста, организуйте интернет-конференцию на следующей неделе".
Как видно настройку и организацию связи осуществляют третьи лица. Нет?

[poru]

Поразмыслив, я понял, что потребовал от Вас слишком мало!
Вместо настройки конструктора Default/System надо сделать для каждого "проперти" по мимо существующего смысла Unknown новый смысл System/Default, который будет определять состояние свойства в момент открытия порта, то есть настраивать свойство значением по дефолту/определением или брать его текущим по состоянию системы. Но это только в том случае, если Вы продолжите политику предопределенных значений.

[kuzulis]

по мимо существующего смысла Unknown

В будушем Unknown будет удален.

Все будет упрощено и всегда порт будет открываться и конфигуриться или с умолчальными 9600 8 N 1 или с пользовательскими настройками. Ни о каких "системных" настройках не может идти речи. Точка.

[poru]

Ни о каких "системных" настройках не может идти речи. Точка.

Пичаль-беда... Теперь Мальчик Петя не познакомится с девочкой Лизой, не возьмет
ее замуж..

Итог.
На протяжении 4 лет я слежу и инспектирую класс QSerialPort (QSerialDevice) и аналоги из других библиотек. Смысл отказаться от сторонних компонент и полностью перейти на средства Qt. Из Ваших заявлений я делаю вывод, что QSerialPort как для нас, так и для наших партнеров в очередной раз не готов заменить широко применяемую компоненту TComPort. Кстати разработки 2002-2003 года. Увы, мне очень жаль потраченное Вами время.

[Racheengel]

Наш софт тоже работает с последовательным портом.
В конфигах есть таб, где можно выставить все параметры соединения.
Если это сделано через гуй - параметры передаются сразу порту.
Параллельно настройки пишутся в файлик.
При следующем старте софтины, файлик читается и порт переконфигурируется "вчистую".
По моему, это самое нормальное поведение. Гарантия того, что "дядя Вася" не нашухарил.

[lesav]

Тема: setRequestToSend() setDataTerminalReady()

Вопрос рожден после прочтения следующего
сообщения: Re: QSerialPort и RS-485 короткий вопрос.

Я понимаю, что QSerialPort работает полностью в асинхронном режиме.
Но предложенное решение не подходит для выставления управляющих
сигналов, т.к. сигнал bytesWtitten приходит всегда нестабильно во
времени, и переключение приемопередатчика происходит с опозданием. 
В итоге я получаю не весь ответ от опрашиваемого устройства.

Существует возможность четкого определения ухода в порт последнего бита ?
Или мне поможет только своя реализация поточного опроса COM порта ?

[kuzulis]

.к. сигнал bytesWtitten приходит всегда нестабильно

Вообше не гарантирует что на физическом уровне передался последний байт/бит.
Оно гарантирует только что операция ввода/вывода завершена и все данные отправлены драйвером.
Но вот "куда" отправлены - это дугой вопрос. Зависит от реализации драйвера или самой железяки.

Существует возможность четкого определения ухода в порт последнего бита ?

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

Как вариант, можно попробовать в линукс флаг, аналогичный FIONREAD, должно быть что-то типа FIONWRITE
или около того. А для Windows попробовать читать структуру COMSTAT.

Но тут также все зависит от девайса и от драйвера, реализовано ли, поддерживается ли...

Также я не уверен что оно отражает также данные, например, находящиеся в shift регистрах UART.

Или мне поможет только своя реализация поточного опроса COM порта ?

Чем черт не шутит, попробуйте

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

PSPS: Я даже не знаю, откуда сейчас берут такой раритет с ручным переключением...

[lesav]

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

Легких путей не существует ))))  Я бы с удовольствием "не заморачивался",
но некоторое оборудование жестко привязано к железу, и ничего не изменить.
К тому-же, моё ПО должно уметь работать с любым оборудованием.
Одно радует, что нужна поддержка только Windows, Linux и QNX

PSPS: Я даже не знаю, откуда сейчас берут такой раритет с ручным переключением...

Да, не перевелись такие. Используется Kontron-овская плата CP346.
У этой железки управление приемопередатчиком с помощью сигнала DTR.
Есть вероятность что под Windows драйвер умеет автоматом управлять
направлением передачи, но оборудование работает под Suse linux SLES9. (

Чем черт не шутит, попробуйте свою реализацию...

Она работает, просто хотелось перевести проект на QSerial.
Жалко двух потраченых дней.

Спасибо за отклик