Всем привет. Помогите, пожалуйста, разобраться с таймаутами при работе с серийным портом (/dev/ttyS0).
Устанавливаю я него примерно так:

Если параметр timeout меньше 2500 мс, тогда тайумаут работает как надо. Если же это значение выставить выше 2500 мс, тогда он перестает нормально работать и, скажем, при значении в 10 сек, read() может ожидать данных с устройства и 30 и 40 сек, а только потом возвращает полученный байт. Причем байт доступен в устройстве практически моментально. Не знаю чего он там ещё ждёт.
В чём может быть проблема? 
Мне нужны таймауты до 120 с. Сейчас вместо tcsetattr() использую select(), но это костыль. 

там есть 2 "локальных" режима:
"канонический", устанвливается:

"неканонический":

функционал VTIME в каждом режиме свой.
перечитай очень внимательно мануальчик по termios.



Это сообщение отредактировал(а) bilbobagginz - 12.2.2010, 16:25

Канонический режим у меня отключен. man tcsetattr перечитал 10 раз. В каноническом режиме таймаут вообще не работает.

xStream, 
a что сидит на другом конце последовательного порта?

Добавлено через 2 минуты и 37 секунд
может тот, кто сидит на др. конце - вырубается сам.

bilbobagginz, 
Фискальный регистратор.
На вряд ли. С select оно работает 

а можешь показать что получаешь:

?

bilbobagginz,  tcsetattr возвращает 0

все равно собака....  
А если устройство работает быстро, почему таймаут в 2.5 секунды - не подходит?

Добавлено @ 17:22
и еще момент, там есть еще каунтер байтов:

ты его трогал ?
там есть схема условий, когда read  возвращается, 4 случая (когда VMIN/VTIME по нулям)

и еще вопрос: почему асинхронный подход тебе не нравится?


Это сообщение отредактировал(а) bilbobagginz - 12.2.2010, 17:25

Ожидать байт надо столько, сколько прописано в документации к устройству. И это время может колебаться от 500 мс, до 150000 мс. 
.c_cc[VMIN] выставлен в 0.

т.е. 1 байт ожидаешь ?

Добавлено через 12 минут и 37 секунд
и еще вопросик: когда read() возвращается позже чем надо, он какую ошибку возвращает, какой errno ?

да, по 1-му байту считываю

а read() возвращается без ошибки и с 1 прочитанным байтом (как и надо), даже если позже таймаута. но устройство, то уже потеряло логическую нить. оно считает, что комп не ответил в нужный промежуток времени и начинает "диалог" заново. 

ИМХО, select в помощь + все VMIN и VTIME по нулям + при открытии флагами ставить асинхронный режим + читать не по 1 байту - а по реальному их количеству в приемном буфере и потом просто проверять скока прочиталось и скока нужно еще дочитать и т.п. Всё просто.

Вопрос: нужно именно под *.nix или тебе можно и кроссплатформенное решение на Qt4 ? 

Добавлено через 1 минуту и 57 секунд
И еще, какой протокол работы с устройством?

Добавлено через 4 минуты и 30 секунд


Ну неправда... Это не костыль! 

Примерно так всё сейчас и работает.


Не можно, а нужно. Использую QextSerialPort


АТОЛ Протокол работы ККМ.

а попробуйте ка  QSerialDevice. http://fireforge.net/snapshots.php?group_id=199

PS: мне нужны тестеры сего поделия 

Добавлено через 45 секунд


ИМХО - тогда и нечего заморачиваться

kuzulis, отписался тебе в личку. 



приходится. с select тоже не все гладко.