Последоватьльный порт - таймаут read'a в raw режиме.

Аналогичных проблем не было, н я бы порылся в настройках порта.

Кстати, зачем тебе тайм-аут вообще? Почему не poll?

Т.е. select/poll должен спасти отца марсиянской паранойи от гнева начальства?

> select/poll должен спасти отца марсиянской паранойи от гнева начальства?

Нет, тебя всё равно расстреляют^Wлишат премии. Но зато у тебя не будет бесконечных тайм-аутов :)

ОК - всем отозвавшимя fnx.

Когда-то давно писал опрос электросчетчиков через преобразователь usb<->485 но смысл тот же - последовательный порт, была аналогичная проблема, помоему решилась посимвольный чтением - там по протоколу первый байт был - длина ответа счетчика - поэтому после чтения первого байта было известно количество байт которые нужно считать. Если ты знаешь сколька нужно прочитать - читай посимвольно в цикле.

Уже была такая идея - посимвольно читать. Вот только не жирно ли будет, в том плане, что тянуть ответ целиком проще, чем каждый раз дёргать устройство read'ом из-за каждого символа?

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

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

> не жирно ли будет, в том плане, что тянуть ответ целиком проще, чем каждый раз дёргать устройство read'ом из-за каждого символа?

Бггг. Какая скорость порта? Какой проц?

Ну пока гоняю на 9600, то, естественно, всё равно. Но там режимы вплоть до 115200.

Впрочем, это, похоже, "паранойя жить спокойно не даёт"

Именно так я делал и делаю :) Там же контрольная сумма есть и к тому же в конфиге задавалось максимальное количество неудачных попыток.

> Ну пока гоняю на 9600, то, естественно, всё равно.

О чем и спич.

> Но там режимы вплоть до 115200.

Ставь non-blocking режим, и читай блоками. FIFO тебе поможет.

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

+много Или во время приёма кто-то отрубил питание девайсу, случайно задел RS'овский кабель...

ОК - спасибо, попробую. Со 115200 я немного погорячился - это уже не "вопрос-ответ", а непрерывный режим.

Читай блоками - когда надоест получать ошибки поумнеешь :) Удивляюсь такой настойчивости - ни чужие ни свои ошибки не учат :) При посимвольном чтении таймауты никто же не отменял. А вообще чета интересно стало - что за ацп такой - передает данные судя по 10 байтам ответа - высокой разрядности и без контролной суммы по очень ненадежному интерфейсу ?

>VTIME и VMIN

выставь обеих в 0, включи неблокирующий режим и рули select-om.

\\wbr cvv

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

Уже сделал. А если бы ещё девайс не отключили (чего через ssh не видно) , то и, может увидел бы, не только как этот select timeout отрабатывает.

а я poll'ом жду события от посл порта в отд потоке, который запуская из main при этом прога или зависает или графика глючит а чаще вообще всё вылетает... хотя под bash всё работает нормально..