Сначала опишу ситуацию:
Микроконтроллер (МК) подключен по UART к AT91SAM9XE512 (Linux 3.0.4).
У микроконтроллера ограничено ОЗУ, поэтому реализован обмен пакетами динамического размера - от 3 до 48 байт.
При скорости 500000 бод время передачи пакета не более 1мс.
В Linux написали приложение в юзерспейсе (кушает 2...5%CPU).
И теперь ответный пакет (3-5байт) из Linux приходит не сразу, а с задержкой до 10 мс (подозрение на переключение контекста).
Работать без ответов нельзя - МК должен убедиться, что доставил пакет в Linux приложение.
При этом МК тратит на обработку пакета до 80 мкс.
В итоге средняя скорость данных - около 4700 байт/сек.
Что хочется сделать:
Главное - максимально быстро дать знать МК, что пакет принят.
Теоретически, если бы в большинстве случаев (иногда задержки до 10 мс допустимы) Linux по UART-у отвечал так же быстро, как и МК, то:
- в течении 10 мс может прийти до 10 пакетов и нужно сделать 10 ответов.
- скорость может быть почти 41000 байт/сек, то есть почти в 9 раз больше!
- обработку собранных пакетов можно сделать и позже (приемлемо до 100 мс).
Теперь собственно вопрос:
Как в Linux сделать быстрый ответ по UART? В данном случае уже всё равно - userspace or kernelspace.
Изучая этот вопрос, склоняюсь к написанию специальной line discipline, однако не могу найти вразумительное описание как это делается.

Вопрос сходу. Почему не сделать обмен, например, по 10 пакетов за раз? Linux отвечает один раз с указанием того, какие пакеты принял. Учитывая скорость передачи и скорость обработки пакета на МК, сэкономите кучу времени. Как проводить идентификацию пакетов в группе и обрабатывать нештатные ситуации - на свое усмотрение.

Пункт 4.4:
https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf

Вы прямо читаете наш код )) В МК уже сделали передачу по 32 пакета.
Осталось сделать группировку пакетов с подтверждением на Linux, однако есть непонимание, по какому принципу начинать отправку пакетов потдверждения, поскольку поток не регулярный.
То есть можем собрать 8 ответов и недопустимо долго ждать следующего пакета. Придётся какой-то таймер завести.
Да и в Linux пока такое безобразие не добавлено.
Думалось, может можно как-то на корню решить проблему быстродействия (пусть даже kernelspace) и выкинуть код не заморачиваться передачей много пакетов за раз.
to BaN
Спасибо за статистику, весьма совпадает с реальностью нашего Linux и userspace. Посмотрим, что за зверь этот xenomai.

Ну, вам виднее - без знания того, откуда берутся данные для посылки сложно что-то предполагать. Но даже так можно представить структуру: буфер, данные которого по расписанию(по таймеру), отправляются на linux. А содержимое буфера обновляется по готовности. (Соотв-но, если не обновилось, отсылаем что было - linux уже сам разберется что к чему по ID пакета) Так будет постоянный поток данных, что теоретически может сильно нагрузить и мк и linux, но с другой стороны наличие расписания может сыграть хорошую службу в плане ответных пакетов.