где могут застрявать байты в преобразователе USB-COM?

Возможно, что они застрявают в брандмауэре висты, она способна на это.

А к чему такой изврат? На обоих компах нет COM и Ethernet? Тестите приложение для передачи по COM?

виста фильтрует трафик по COM-портам?

>виста фильтрует трафик по COM-портам?

Она много чего неведомого творит, кто ее знает. Вполне возможно.

COM-ов нет, с использованием Ethernet - проблемы

А осциллографом посмотреть, что в этот момент через интерфейсы идёт?

tty на линуксовой стороне сконфигурирован правильно? Всякий дополнительный пост и препроцессинг выключен?
stty -a -F /dev/ttyUSB0

с использованием Ethernet - проблемы
Какие проблемы можно рассказать? Или подписка о неразглашении?
Пропускная способность RS232 тем более через FTDI-ку не будет столь высокой, чтоб прон с linux-сервера на висте смотреть в rt.

Буфер в преобразователе с таймаутом, например?

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

speed 57600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

организационные.

там нужно десяток байт в секунду гнать.

А можно поинтересоваться, собственно в чём задача? я заинтригован.

во первых зачем 57600 bod если гонится несколько десятков байт в секунду.. плюс смущает опции -ixany и сочетание -parend -parodd

такое ощущение, что где-то раз в часов в несколько проскакивает ошибка чётности или спец символ (что в принципе вполне нормально для RS-232 на такой скорости, да ещё и через USB конвертер). А протоколы или форматы приёмника/передатчика несогласованны и наступает некоторый тупняк, пока драйвер аппаратно по таймеру передёрнув цепями его не сбрасывает.

будь мущиной - спаяй преобразователь на pic18j67j50, не стоит пользоваться проприетарной поделкой с закрытыми алгоритмами.

а вообще - стань осцилографом на оба выхода и посмотри, делов то (%

Ага, и напиши свой драйвер для него, и под оффтопик, и под никсы.

в блокирующем режиме тоже теряются?

а вообще - стань осцилографом

прям таки девиз :)

Если я правильно понял вопрос - то байты НЕ теряются.

можно развернутей обьяснить?

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

при текущих настройках у Вас явные проблемы в управлении потоком или буферизации. Проблемы проявляются редко - видимо только при помехе на линии или случайно совпавшем спец-символе.

Как предположение - сторона обмена поймавшая это событие затыкает поток, а вторая сторона недождавшись ничего за обусловленное время передёргивает одну из управляющих цепей показывая что всё ещё готова к приёму. Соотв. по этому сигналу передача возобнавляется.

Более развёрнуто - можно только при наличии ТЗ, исходников, протоколов и за деньги :) Всё-же точное лоцирование проблемы и её исправление - очевидно Ваша работа.

> при текущих настройках у Вас явные проблемы в управлении потоком или буферизации. Проблемы проявляются редко - видимо только при помехе на линии или случайно совпавшем спец-символе.

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

Как предположение - сторона обмена поймавшая это событие затыкает поток, а вторая сторона недождавшись ничего за обусловленное время передёргивает одну из управляющих цепей показывая что всё ещё готова к приёму. Соотв. по этому сигналу передача возобнавляется.

я делаю cfmakeraw() это должно выключать интерпретацию всяких служебных символов. это должно быть видно из вывода stty. Поэтому просьба уточнить что вы понимаете под «спец-символом»