#linux #multithreading #serial-port #linux-device-driver #embedded-linux
#linux #многопоточность #последовательный порт #linux-драйвер устройства #встроенный-linux
Вопрос:
У меня есть сценарий в последовательном драйвере Linux
Пункт 1: последовательный драйвер вызова IRQ непрерывно получает набор байтов на основе запроса, сделанного пользовательским пространством Linux, и мы получаем набор последовательных байтов (Frame1) от других узлов,
Пункт 2: нам нужно проверить временную метку каждого байта с некоторым временем, скажем, t1 сек., если полученные байты превышают t1 сек., драйвер обрабатывает как следующий кадр (кадр 2) для обработки,
как нам достичь пункта 2 в драйвере Linux? я думал о создании рабочего потока, но я не уверен, что нужно проверять пункт 2.
может быть вероятность того, что IRQ может подтвердить проверку фрейма, используя те же секунды t1.
Пожалуйста, помогите, какой лучший вызов функции ядра я могу использовать для этого сценария.
Комментарии:
1. Linux не RTOS. Для этого вам нужен дополнительный микроконтроллер. UART требует слишком много работы даже на современных SoC.
2. @MartinJames К сожалению, существуют протоколы, которые полагаются на такие тайминги, такие как Modbus RTU.
3. Вы не можете сделать это с помощью программного обеспечения Linux. Задержка случайного прерывания сделает измерения таймера неточными. Решение состоит в использовании надлежащего оборудования, т. Е. U [S] ART, который имеет возможность «тайм-аута приемника», который отслеживает последовательный ввод. После получения символа и ожидания строки в течение заданного времени генерируется прерывание.
4. @MartinJames «все UART, начиная с perhistory, имеют 16-байтовый FIFO» — это нелепое и ложное утверждение. Кроме того, использование FIFO приема уничтожит любую / всю информацию о времени, которая была на проводе. Похоже, вы не понимаете актуальную проблему OP, которая задает вопрос XY.
5. «нам нужно проверить временную метку каждого байта …» — Даже если вы могли бы точно установить временную метку для каждого байта (что сомнительно с точки зрения программного или аппаратного обеспечения), предложенный алгоритм является ошибочным, поскольку он создает ситуацию с гниющим пакетом . Когда пакет получен, он фактически не идентифицируется как полный пакет, пока не будет получен следующий байт после простоя (т. Е. Первый байт следующего пакета). Но если линия фактически простаивает в течение более длительного времени (т. Е. Никто ничего не отправляет), то полученный пакет останавливается и не пересылается для обработки.