_3m 9 13 марта Опубликовано 13 марта · Жалоба На вход последовательного порта поступают пакеты произвольной длины, конец пакета обозначен специальным (зарезервированным) символом который в теле пакета не встречается. Пакеты могут следовать как слитно так и с паузами, причем паузы могут быть в произвольном месте как между пакетами так и между байтами внутри пакета. Например конец пакета - символ '\n': ...\n__idle__<packet1>\n<packet2>\n<packet3a>__idle__<packet3b>\n<packet4>\n<packet4>__idle__\n... Мне необходимо передавать пакет на обработку с минимальной задержкой после получения символа конца пакета. Как это можно реализовать максимально эффективно ? Я пошерстил гитхаб и гугл. Типовые реализации работают либо по таймауту либо по размеру ожидаемого пакета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 45 13 марта Опубликовано 13 марта · Жалоба 29 minutes ago, _3m said: Типовые реализации работают либо по таймауту либо по размеру ожидаемого пакета Даже совсем не новый STM32F0 умеет принимать через UART+DMA до прихода программируемого символа, при поступлении которого возбуждает прерывание. Сложно придумать что-то более эффективное. Такое есть не во всех МК даже одной линейки, поэтому смотрите на свойства UART. На наличие этого свойства указывает аппаратная поддержка Модбаса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 190 13 марта Опубликовано 13 марта · Жалоба 39 минут назад, _3m сказал: Мне необходимо передавать пакет на обработку с минимальной задержкой после получения символа конца пакета. Цитата .../Операционные системы/Linux/Парсинг пакетов от serial port Вы пытаетесь поженить теплое с круглым. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 13 марта Опубликовано 13 марта (изменено) · Жалоба 9 минут назад, tonyk_av сказал: Даже совсем не новый STM32F0 умеет принимать через UART+DMA до прихода программируемого символа, при поступлении которого возбуждает прерывание. Сложно придумать что-то более эффективное. Такое есть не во всех МК даже одной линейки, поэтому смотрите на свойства UART. На наличие этого свойства указывает аппаратная поддержка Модбаса. Здесь форум про Linux. То есть tty, termios, read(), write() и все! Не нашел в Linux tty сигнала по приходу программируемого символа. И stm32 такое умеет совсем новый серии G. В винде есть но пишут что оно не работает потому что реализация Vendor specific и на нее производители просто забивают болт. Более того задача кроссплатформенная - надо и под win то же самое. Изменено 13 марта пользователем _3m Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ericN 3 14 марта Опубликовано 14 марта · Жалоба хотел предложить написать свой драйвер UART и там реализовать всё что Вам нужно, но потом увидел В 13.03.2024 в 19:31, _3m сказал: Более того задача кроссплатформенная - надо и под win то же самое. тут только прикладной уровень. Может быть Qt? У QSerial есть сигнал по получении байта. Пишем свой слот, который по одному выгребает весь приемный буфер серийного до стоп-символа. Как нашел, сигналит пакетом обработчику пакетов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 14 марта Опубликовано 14 марта · Жалоба On 3/13/2024 at 4:46 PM, _3m said: Мне необходимо передавать пакет на обработку с минимальной задержкой после получения символа конца пакета. Как это можно реализовать максимально эффективно ? написать модуль ядра своего кастомного фреймера по примеру SLIP Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 14 марта Опубликовано 14 марта · Жалоба 1 час назад, sasamy сказал: написать модуль ядра своего кастомного фреймера по примеру SLIP Да, я тоже думал в эту сторону, похоже в линуксе нет эффективных способов решить эту задачу в userspace. Еще есть мысль подстроиться под кукую либо из уже имеющихся line discipline, тут трудность в том что оно плохо документировано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 14 марта Опубликовано 14 марта (изменено) · Жалоба On 3/14/2024 at 10:10 AM, _3m said: Да, я тоже думал в эту сторону, похоже в линуксе нет эффективных способов решить эту задачу в userspace. штатно есть канонический режим tty Quote 2.3.1. Canonical Input Processing This is the normal processing mode for terminals, but can also be useful for communicating with other dl input is processed in units of lines, which means that a read will only return a full line of input. A line is by default terminated by a NL (ASCII LF), an end of file, or an end of line character. A CR (the DOS/Windows default end-of-line) will not terminate a line with the default settings. https://tldp.org/HOWTO/Serial-Programming-HOWTO/x56.html#AEN92 может получится его нстроить Изменено 14 марта пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 57 14 марта Опубликовано 14 марта · Жалоба 2 часа назад, sasamy сказал: написать модуль ядра своего кастомного фреймера по примеру SLIP Под винду тоже драйвер писать будете? 17 часов назад, _3m сказал: надо и под win то же самое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 0 14 марта Опубликовано 14 марта · Жалоба On 3/14/2024 at 11:21 AM, mantech said: Под винду тоже драйвер писать будете? вопрос в ветке про Linux, про венду в другой ветке - там и умничайте 🙂 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 57 14 марта Опубликовано 14 марта · Жалоба 2 часа назад, sasamy сказал: там и умничайте ТС про винду здесь задал вопрос, поэтому здесь и умничаю Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 9 14 марта Опубликовано 14 марта · Жалоба 16 минут назад, mantech сказал: ТС про винду здесь задал вопрос, поэтому здесь и умничаю На винде есть хотя бы теоретический DCB.EvtChar а в линкуксе в неканоническом режиме даже этого нет. А канонический ... ну не знаю на что он годен в 202* году. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 29 14 марта Опубликовано 14 марта · Жалоба Наверно, что-то типа: Цитата This is a completely non-blocking read – the call is satisfied immediately directly from the driver’s input queue. If data are available, it’s transferred to the caller’s buffer up to nbytes and returned. Otherwise zero is immediately returned to indicate “no data”. We’ll note that this is “polling” of the serial port, and it’s almost always a bad idea. If done repeatedly, it can consume enormous amounts of processor time and is highly inefficient. Don’t use this mode unless you really, really know what you’re doing. https://makemeengr.com/linux-blocking-vs-non-blocking-serial-read/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 69 15 марта Опубликовано 15 марта · Жалоба 18 часов назад, _3m сказал: похоже в линуксе нет эффективных способов решить эту задачу в userspace. DPDK? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 17 марта Опубликовано 17 марта · Жалоба On 3/14/2024 at 3:10 AM, _3m said: похоже в линуксе нет эффективных способов решить эту задачу в userspace. Все определяется тем, что подразумевается под эффективным способом. Для некоторых задач вполне подойдет userspace решение. On 3/14/2024 at 4:21 AM, mantech said: Под винду тоже драйвер писать будете? Ну наполовину задача уже решена будет. А потребуется, то и на винду драйверы пишут обычные люди. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться