Здравствуйте, товарищи эксперты. У меня очередной затык. Сразу скажу, что я тупенький во всех этих железячных делах...

В наличии:

RS-232 устройство, которое непрерывно шлёт данные стандартными пакетами по 10 байт, 115200-8-N-1. Межпакетного интервала нет.

SK-iMX6S-OEM-Ind

SK-iMX6S/53/50-MB

buildroot-2017.08 на базе ядра 4.1.15-2.1.0 для i.mx6 от sasamy (тык).

Дебиан 9.3, модифицированный sasamy (тык).

Что надо:
Надо из юзерспейса читать посылки и обрабатывать их.

Что накодил:
Использую /dev/ttymxc1 , termios.h , fcntl.h

Получение дескриптора:

Код

d = open(portPath, O_NOCTTY | O_NONBLOCK | O_RDWR);

Настройки, которые задаёт программа через termios:

Код

stty --all -F /dev/ttymxc1
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc

В чём проблема:
Данные впервые поступают в read только после накопления 4096 Б, и далее вновь по мере накопления 4096 Б. То есть они валятся огромным массивом примерно раз в 500мс, что неприемлемо. Причём считывание идёт как 4095 + 1.

Для сравнения, на компьютере (тоже дебиан) в такой же код при передаче данных через usb-rs-232 адаптер (ICPcon i-7561) данные залетают в read по 10-40 байт.

Что надо:
Получать и обрабатывать данные по мере поступления. Пусть склеенными даже по 5-10 пакетов, но не по 400...

Что пробовал:
Пробовал играть с параметрами VMIN и VTIME, делая их ненулевыми в разных сочетаниях. Эффекта никакого.

Пожалуйста, спасите-помогите...

Цитата

Что надо:
Надо из юзерспейса читать посылки и обрабатывать их.

в сети есть масса примеров как работать с компортами, например

https://www.teuniz.net/RS-232/

Цитата

в сети есть масса примеров как работать с компортами, например

Переписал с использованием встроенного в Qt QSerialPort - результат тот же: данные приходят в read по 4096 байт.

Вытянул репозиторий по предложенной Вами ссылке, скомпилил test_rx, предварительно дополнив перечень портами /tev/ttymx*. Результат вновь тот же: данные приходят слепленными в 4096 байт (4095+1).

Я давно себя таким идиотом не ощущал...

По-прежнему нужна помощь.

Цитата

скомпилил test_rx, предварительно дополнив перечень портами /tev/ttymx*. Результат вновь тот же: данные приходят слепленными в 4096 байт (4095+1).

а кто их должен разлеплять ? сколько есть в буфере порта столько и читается

n = RS232_PollComport(cport_nr, buf, 4095);

сделайте тут

n = RS232_PollComport(cport_nr, buf, 10);

будет максимум 10 байт за раз читать

Цитата

а кто их должен разлеплять ? сколько есть в буфере порта столько и читается

Проблема не в том, что я не могу их разлепить. Могу. Проблема в том, что количество байт, доступных для чтения (если раз в 2 мс долбить метод read или poll), на плате imx6 меняется как 0-0-0-...-0-0-0-4096-0-0-0-...-0-0-0-4096-0-0-0-...

Абсолютно тот же самый пример из этой библиотеки на компьютере даёт примерно 20-20-30-20-30-20-40-20-30-20... Числа написаны условно. Главное то, что на компьютере данные выдаются в юзерспейс по мере поступления, а на плате - когда весь входной буфер забьётся.

АБСОЛЮТНО ОДИНАКОВЫЙ КОД на компьютере работает правильно, а на плате - нет. На компьютере данные обрабатываются сразу, как устройство начинает их слать. На плате первые данные появляются через полсекунды и далее раз в полсекунды.

Цитата

Проблема в том, что количество байт, доступных для чтения (если раз в 2 мс долбить метод read или poll), на плате imx6 меняется как 0-0-0-...-0-0-0-4096-0-0-0-...-0-0-0-4096-0-0-0-...
...
Главное то, что на компьютере данные выдаются в юзерспейс по мере поступления, а на плате - когда весь входной буфер забьётся.

может я совсем не понимаю о чем вы - ничего подобного я у себя не вижу. OEM у меня нет, тест на sk-imx6q с корневой buildroot-2017.08-sk

в rs232.c заменил дефолтный порт на ttymxc0

Цитата

const char *comports[RS232_PORTNR]={"/dev/ttymxc0","/dev/ttyS1", ...

в тесте demo_rx.c поменял скорость на 115200

Цитата

int main()
{
int i, n,
cport_nr=0, /* /dev/ttyS0 (COM1 on windows) */
bdrate=115200; /* 9600 baud */

и задержку на 2 мс

Цитата

#else
usleep(2000); /* sleep for 100 milliSeconds */

отключил на плате консоль на ttymxc0 и подключил его к PC через переходник USB-serial, установил скорость как наплате

В терминале PC

Цитата

sasa@sasa-Q500A:~$ stty -F /dev/ttyUSB0 115200
sasa@sasa-Q500A:~$ printf "Hello, world!" > /dev/ttyUSB0
sasa@sasa-Q500A:~$ printf "Hello" > /dev/ttyUSB0
sasa@sasa-Q500A:~$ printf "1234567890" > /dev/ttyUSB0

выхлоп теста на плате

Цитата

# ./test_rx
received 13 bytes: Hello, world!
received 5 bytes: Hello
received 10 bytes: 1234567890

где вы тут видите 0,0, .. ,4096 ?

Создал на PC тестовый файл

for i in $(seq 1 4096); do printf "1" >> test.txt; done

Закинул в порт

cat test.txt > /dev/ttyUSB0

Тест на плате принимает 4095 + 1 как и должно быть - читает пока есть данные в буфере порта (буфер tty в ядре 4096 байт https://www.linuxquestions.org/questions/linux-hardware-18/why-the-%27n_tty_buf_size%27-is-restricted-as-4096-a-605107/)

Цитата

received 4095 bytes: 1111...
received 1 bytes: 1

Поменял в тесте

n = RS232_PollComport(cport_nr, buf, 100);

результат - прием по 100 байт максимум за один раз

Цитата

received 100 bytes: 11111...
received 100 bytes: 11111...
...
received 96 bytes: 11111

Цитата

АБСОЛЮТНО ОДИНАКОВЫЙ КОД на компьютере работает правильно, а на плате - нет.

а может наоборот ? Вам просто надо понять что это не микроконтроллер и не РТОС - нет никакой гарантии в юзерспейс что задержка 2 мс - гарантируется только то что она минимум 2 мс, а может быть и секунду, невозможно сказать сколько байт в буфере после такой задержки.

Если откинуть в сторону Windows - в Linux есть системные вызовы poll/select - с ними не надо никаких задержек делать, выполнение текущей задачи можно приостанвить до появления данных в буфере порта, в данном примере циклические задержки нужны для совместимости с Windows. Для одного порта можно вообще блокирущее чтение использовать без всяких задержек - текущая задача уснет пока нет данных. Эта библиотека просто как пример.

Цитата

может я совсем не понимаю о чем вы

Может, я непонятно объясняю. Ещё раз. Устройство шлёт данные непрерывно пакетами по 10 байт, межпакетного интервала нет. Прикладываю код и лог.

Модифицированный пример:

Код

struct timeval time_val;
int msecs;
char time_str[10];
char full_time_str[20];

if(RS232_OpenComport(cport_nr, bdrate, mode, 0))
{
printf("Can not open comport\n");

return(0);
}

while(1)
{

do {
n = RS232_PollComport(cport_nr, buf, 400);

gettimeofday(&time_val, 0);
msecs = trunc(time_val.tv_usec / 1000.0f);

strftime(time_str, 40, "%H:%M:%S", localtime(&time_val.tv_sec));
sprintf(full_time_str, "%s.%03d", time_str, msecs);

if (n > 0) {
printf("%s: %i bytes read\n", full_time_str, n);
} else {
printf("%s: no data available\n", full_time_str);
}

} while (n > 0);

usleep(2000); // sleep for 2 milliseconds
}

Фрагмент лога на компьютере (Debian 8.7):

Код

09:41:42.775: 20 bytes read
09:41:42.777: 12 bytes read
09:41:42.779: 24 bytes read
09:41:42.781: 12 bytes read
09:41:42.783: 16 bytes read
09:41:42.785: 30 bytes read
09:41:42.787: 16 bytes read
09:41:42.790: 12 bytes read
09:41:42.792: 10 bytes read
09:41:42.794: 28 bytes read
09:41:42.796: 30 bytes read
09:41:42.798: 20 bytes read
09:41:42.800: 12 bytes read
09:41:42.802: 30 bytes read

Фрагмент лога на плате (Debian 9.3):

Код

09:45:20.900: no data available
09:45:20.902: no data available
09:45:20.904: no data available
09:45:20.906: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 400 bytes read
09:45:20.907: 95 bytes read
09:45:20.907: no data available
09:45:20.909: 1 bytes read
09:45:20.909: no data available
09:45:20.911: no data available
09:45:20.914: no data available
<...>
09:45:21.889: no data available
09:45:21.891: no data available
09:45:21.893: no data available
09:45:21.895: 400 bytes read
09:45:21.895: 400 bytes read
09:45:21.895: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 400 bytes read
09:45:21.896: 95 bytes read
09:45:21.896: no data available
09:45:21.898: 1 bytes read
09:45:21.898: no data available
09:45:21.900: no data available
09:45:21.903: no data available

Как видно из логов, на компьютере метод Poll каждый раз считывает некоторое небольшое количество байт, находящихся сейчас во входном буфере. На плате метод Poll возвращает нули до тех пор, пока буфер не заполнится целиком, после чего возвращает весь буфер целиком. То, по сколько байт я хочу считывать, не имеет значения. Посмотрите на временные отметки. Все 4096Б становятся доступны одновременно. Между выдачей данных стабильное время, равное времени полного заполнения буфера. Поскольку поток не блокируемый, я не понимаю, какого лешего так происходит. Я понимаю, что это не реалтайм операционка, но камооон, 10 кБ / сек невозможно обрабатывать чаще одного раза в 900 мс?..

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

Такое ощущение, что реализация tty в дебиане на плате отчаянно пытается дождаться конца посылки данных (нет межпакетного интервала - нет конца), не может его дождаться, и потому вынужденно отдаёт данные после заполнения буфера.

Цитата

Для одного порта можно вообще блокирущее чтение использовать без всяких задержек

Да, ставил VMIN = 1.

Код спит-спит-спит-спит-спит, а потом в него разом валится 4096Б данных. Затем всё повторяется.

Из спортивного интереса воспроизвёл эксперимент на чистом билдрутном линуксе. Результат тот же...

Цитата

Может, я непонятно объясняю. Ещё раз. Устройство шлёт данные непрерывно пакетами по 10 байт, межпакетного интервала нет

это понятно - непонятно с чего вы решили что система обязана в таком случае принимать их кусками размером какой вам нужен - какая разница, 4096 байт вы будете потом парсить или 80 ?

Цитата

Как видно из логов, на компьютере метод Poll каждый раз считывает некоторое небольшое количество байт, находящихся сейчас во входном буфере.

отключите DMA у порта и будет вам "как на компьютере"

imx6qdl.dtsi

для порта ttymxc0 - uart1

Цитата

uart1: serial@02020000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x02020000 0x4000>;
interrupts = <0 26 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_UART_IPG>,
<&clks IMX6QDL_CLK_UART_SERIAL>;
clock-names = "ipg", "per";
/*
dmas = <&sdma 25 4 0>, <&sdma 26 4 0>;
dma-names = "rx", "tx";
*/
status = "disabled";
};