очистка буфера последовательного порта

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

wat?

очищает буфер и порт готов к приему сдедующего пакета

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

Имеет ли значение какой порт используется, изменится ли поведение, если будет «железный» UART?

могут «поплыть» тайминги прохождения данных, т.к. у USB еще свои буфера и таймера. Обычно не критично, но стоит помнить

Может измениться ли поведение в зависимости от настроек порта (если да, от каких настроек это зависит)?

от всех

для порта есть параметр «размер кеша данных» отдельно in отдельно out.
прослойка усб до лампочки, драйвер usbserial.ko или иной из kernel/drivers/usb/serial/ читает кеш усб-устройства, распаковывает пакеты и сливает полученный поток в кеш /dev/ttyUSB*
главное не упираться в размер кеша, не знаю поведение драйвера при переполнении кеша, но в любом случае ты потеряешь данные. так что читай чаще чем возможно переполнение и будет все океюшки.

Я вычитываю количество доступных для чтения байтов, затем читаю их. wat?

ioctl(handle, FIONREAD, &bytes)

По остальному - понял, спасибо.

Тогда, уж, позвольте еще один вопрос: что лучше использовать - select или epol?

Ок, спасибо. Таки о чтении: select vs epoll?

Операционная система на устройстве есть?

Нет

Тогда, уж, позвольте еще один вопрос: что лучше использовать - select или epol?

зачем тебе select/poll? если ты делаешь уже ioctl с гарантированным ответом сколько можно прочитать

ИМХО epoll() лучше

зачем тебе select/poll? если ты делаешь уже ioctl с гарантированным ответом сколько можно прочитать

Я не понял. Разве одно другое заменяет?

select/poll удобен для пачки fd плюс POSIX

Тогда вычитывай в прерываниях, ну или вообще DMA подключи в 2 буфера поочередно, 1 заполнится - и в обработку, а принимай во второй. Это если про устройство. А как в этих ваших компьютерах все сделано - я уже и позабыл.

Операционная система на устройстве есть?

Нет

Оу... Беру свои слова обратно. Если это не ОС Линукс, то тут надо разбираться в ньюансах, чтобы правильно ответить. Детали могут быть очень важны.

Давайте еще попробую объяснить (может, чего не так написал). Моя программа крутится на компе (условно) с дебианом или дебианоподобной ОС; а опрашиваю несколько устройств, на которых STM32 или нечто аналогичное. Вот про этот самый опрос устройств и речь.

FIONREAD

Не стоит это дергать, т.к. в драйвере это может быть не реализовано, тупо стоять заглушка. А также в прошивке самого USB устройства может отсутствовать аналогичная команда (там в CDC ACM спеке что то вроде было такое, не помню).

Кароче, зависит от драйвера устройства или самого устройства.

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

ioctl я вызываю на компе, а от устройства я получаю пакеты, на которые надо реагировать (выдавать команды). Получил пакет - среагировал. А устройство - достаточно ограниченное по возможностям, по сути - датчик.

За совет - спасибо, буду воевать дальше.

UPD. И есть разница между USB шнурком, или аппаратным сериалом на самой плате (если не комп, а типа плата на базе какого нить ARM и прочего). А также от скорости передачи.

У аппаратного сериала фифо намного меньше обычно чем у USB шного, и на больших скоростях тупо происходит overrun, когда не успевает вычитывать данные по евентам от poll/epoll (была такая ерунда однажды с некоей бордой на iMX53, может драйвер был хреновый, может еще что). Поэтому надо сразу читать по многу. ))

Хорошо, спасибо!

Всем спасибо за ответы!

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

Тут мы решаем ряд проблем:

• Данные фрейма могут приходить кусочками по несколько байт. Кольцевой буфер собирает их.
• При операции чтения можно достать конец одного фрейма и начало другого. Или битый фрейм или ещё какой-то мусор. Если такая ситуация возникла, можно выкинуть из начала очереди один байт и снова попробовать распарсить. Это дает возможность всегда вычленять из байтого потока фреймы, даже если процесс разбора сбился из-за битых данных.
• Унифицированный подход к разбору пакетов позволяет легче ориентироваться в своем коде. Когда у тебя будет много всякого кода разбора разных протоколов, то легче в куче этого кода ориентироваться. В голове все не удержишь.

Из недостатков следует отметить дополнительные издержки на промежуточную буферизацию. Но её очень трудно избежать, поэтому скорее всего пусть в какой-то другой форме, но она все равно будет присутствовать в твоем коде.

Кстати, да, проблема поиска начала пакета будет серьезной. Пока у меня демо-версия, но с увеличением количества устройств надо будет буферизовать и проверять пакеты на валидность.

Спасибо, учту.