Последовательная связь с низкой задержкой в ​​Linux

Схемы запроса / ответа обычно неэффективны и быстро обнаруживаются на последовательном порту. Если вас интересует пропускная способность, обратите внимание на оконный протокол, например протокол отправки файлов kermit.

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

Если вам повезет, вы можете настроить поведение драйвера без установки патчей, но вам все равно нужно посмотреть код драйвера. Однако, если ARM обрабатывает частоту прерываний 10 кГц, это, безусловно, не пойдет на пользу общей производительности системы ...

Другой вариант - заполнить свой пакет так, чтобы вы каждый раз достигали порогового значения FIFO. Он также подтвердит, является ли это проблемой порогового значения FIFO.

10 мс @ 115200 достаточно для передачи 100 байтов (при условии 8N1), поэтому вы видите, вероятно, потому, что флаг low_latency не установлен. Пытаться

setserial /dev/<tty_name> low_latency

Он установит флаг low_latency, который используется ядром при перемещении данных на уровень tty:

void tty_flip_buffer_push(struct tty_struct *tty)
{
         unsigned long flags;
         spin_lock_irqsave(&tty->buf.lock, flags);
         if (tty->buf.tail != NULL)
                 tty->buf.tail->commit = tty->buf.tail->used;
         spin_unlock_irqrestore(&tty->buf.lock, flags);

         if (tty->low_latency)
                 flush_to_ldisc(&tty->buf.work);
         else
                 schedule_work(&tty->buf.work);
}

Вызов schedule_work может отвечать за наблюдаемую вами задержку в 10 мс.

Последовательные порты в linux «обернуты» в конструкции терминала в стиле unix, что приводит к задержке в 1 тик, то есть 10 мс. Попробуйте, если stty -F /dev/ttySx raw low_latency поможет, правда, никаких гарантий.

На ПК вы можете пойти на хардкор и напрямую поговорить со стандартными последовательными портами, выполнить setserial /dev/ttySx uart none, чтобы отвязать драйвер Linux от последовательного порта hw и управлять портом через inb/outb регистры портов. Я пробовал это, отлично работает.

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

Вы должны иметь возможность сделать то же самое на стороне устройства руки, может быть намного сложнее на экзотическом последовательном порту hw.

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

--- редактировать ---

Оказывается, я был совершенно неправ. Все, что было необходимо, - это увеличить тактовую частоту ядра. К 100 тикам по умолчанию добавлена ​​задержка 10 мс. 1000 Гц и отрицательное значение nice для последовательного процесса дают мне временное поведение, которого я хотел достичь.

Вот что делает setserial, чтобы установить низкую задержку для файлового дескриптора порта:

ioctl(fd, TIOCGSERIAL, &serial);
serial.flags |= ASYNC_LOW_LATENCY;
ioctl(fd, TIOCSSERIAL, &serial);

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

Вы уверены, что ваше оборудование вообще может это сделать? Нередко можно встретить UART с буфером, обеспечивающим задержку в много байтов.

Короче: используйте USB-адаптер и ASYNC_LOW_LATENCY.

Я использовал USB-адаптер на базе FT232RL на Modbus со скоростью 115,2 кбит / с.

Я получаю около 5 транзакций (на 4 устройства) примерно за 20 мс с ASYNC_LOW_LATENCY. Это включает в себя две транзакции на устройство с медленным подключением (время отклика 4 мс).

Без ASYNC_LOW_LATENCY общее время составляет около 60 мс.

С USB-адаптерами FTDI ASYNC_LOW_LATENCY устанавливает межсимвольный таймер на самом чипе на 1 мс (вместо 16 мс по умолчанию).

В настоящее время я использую самодельный USB-адаптер, и я могу установить задержку для самого адаптера на любое значение, которое я хочу. Установка на 200 мкСм снижает еще на 20 мСм.

На этих скоростях линии вы не должны видеть столь больших задержек, независимо от того, как вы проверяете готовность.

Вам необходимо убедиться, что последовательный порт находится в необработанном режиме (так что вы выполняете «неканоническое чтение») и что VMIN и VTIME установлены правильно. Вы хотите убедиться, что VTIME равен нулю, чтобы межсимвольный таймер никогда не сработал. Я бы, вероятно, начал с установки VMIN на 1 и настроился оттуда.

Накладные расходы на системные вызовы - ничто по сравнению с временем в сети, поэтому select () vs. poll () и т. Д. Вряд ли что-то изменит.