По каким причинам read () на последовательном порту POSIX может работать медленно? - PullRequest
Новая
       51

По каким причинам read () на последовательном порту POSIX может работать медленно?

1 голос
/ 27 января 2012

Я пишу консольное приложение под Ubuntu, которое использует последовательный порт. Нужно читать и писать с последовательного порта на частоте 60 Гц.

Я считаю, что вызов read () часто, но не всегда, медленен. Я установил O_NDELAY, поэтому часто он возвращается сразу (отлично). Иногда это может занять до 50 мс, а это слишком медленно для моего приложения. Перед вызовом read () я проверяю количество доступных символов, поэтому не следует ожидать данных.

Что делает read (), что занимает так много времени? Как я могу ускорить это?

Варианты порта: 

options.c_cflag |= (CLOCAL | CREAD);
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;

options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
options.c_iflag &= ~IXON;

options.c_oflag = 0;

edit: я раньше использовал select (), но он оказался ортогональным к вопросу. Обновлено с моей последней информацией.

Ответы [ 2 ]

1 голос
/ 28 января 2012

Решение состоит в том, чтобы установить флаг low_latency на последовательном порту.

См. Высокая задержка в связи RS232 на PXA270 и http://osdir.com/ml/serial/2003-11/msg00020.html

0 голосов
/ 27 января 2012

Это не то, что делает select, это то, что делает система.Ваш поток в конечном итоге использует свой временной интервал, и система позволяет запускать другой код.Если вы используете разумный тайм-аут, а не пытаетесь немедленно вернуться, система должна рассматривать ваш процесс как интерактивный и задержки должны исчезнуть.0 тайм-аут, я не могу понять, что это такое.Почему бы просто не попробовать выполнить операцию и посмотреть, появляется ли ошибка EWOULDBLOCK?

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

...