Высокая задержка в связи RS232 на PXA270 - PullRequest
Новая
       42

Высокая задержка в связи RS232 на PXA270

8 голосов
/ 12 января 2011

Я испытываю большую задержку (1,5 - 9,5 мс) при обмене данными по RS232 на PXA270 RISC PC / 104.Я хочу минимизировать длительную задержку, но я новичок со встроенными устройствами и C ++, поэтому я думаю, что что-то упустил.

Упомянутая задержка происходит в тот момент, когда плата PXA получает пакет от внешнего устройства.устройство через RS232 (115200 бод) до тех пор, пока оно не отправит пользовательский пакет ACK обратно на внешнее устройство.Я измерил задержку на плате PXA с помощью осциллографа, один канал на Rx, а другой на Tx.

На плате PXA установлена ​​ Arcom Embedded Linux (AEL).Я знаю, что это не ОС реального времени, но я все еще думаю, что средняя задержка в 4,5 мс - это слишком высокая для извлечения полученного пакета, проверьте, что это CRC16, создайте пакет ACK (с CRC) и отправьте его обратно по последовательной линии.Я также сознательно помещал ЦП под большую нагрузку (некоторые параллельные операции gzip), но время задержки вообще не увеличивалось.Максимальный размер принимаемого пакета составляет 30 байт.

Приложение C ++ (его написал другой бывший сотрудник) обрабатывает прием пакетов и их подтверждение.Один поток отправляет, а другой получает пакеты.

Я думал, что RTC на плате PXA имеет очень плохое разрешение, и AEL не может согласовать синхронизацию с внутренним разрешением RTC.Но RTC имеет частоту 32,768 кГц.Разрешение достаточно, но не объясняйте большую задержку.Кстати, я думаю, что ОС использует внутренние часы PXA (которые также имеют достаточное разрешение) вместо RTC для синхронизации.

Поэтому проблема должна быть в приложении C ++ или в настройке драйвера / ОСинтерфейса RS232.

Следующие флаги управления используются для связи RS232 в приложении C ++ в соответствии с Руководством по последовательному программированию для операционных систем POSIX : 

// Open RS232 on COM1
mPhysicalComPort = open(aPort, O_RDWR | O_NOCTTY | O_NDELAY);
// Force read call to block if no data available
int f = fcntl(mPhysicalComPort, F_GETFL, 0);
f &= ~O_NONBLOCK;
fcntl(mPhysicalComPort, F_SETFL, f);
// Get the current options for the port...
tcgetattr(mPhysicalComPort, &options);
// ... and set them to the desired values
cfsetispeed(&options, baudRate);
cfsetospeed(&options, baudRate);
// no parity (8N1)
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
// disable hardware flow control
options.c_cflag &= ~CRTSCTS;
// raw input
options.c_lflag = 0;
// disable software flow control
options.c_iflag = 0;
// raw output
options.c_oflag = 0;
// Set byte times
options.c_cc[VMIN] = 1;
options.c_cc[VTIME] = 0;
// Set the new options for the port
tcsetattr(mPhysicalComPort, TCSAFLUSH, &options);
// Flush to put settings to work
tcflush(mPhysicalComPort, TCIOFLUSH);

Я думаю, что мне не хватает чего-то очень простого.Я думаю, что если процесс приложения работает с более высоким приоритетом, это не решит проблему.Должно быть что-то, что инструктирует драйвер RS232 обрабатывать запросы с более высоким приоритетом, чтобы минимизировать задержку.

У кого-нибудь есть идеи?Заранее большое спасибо за помощь.

1 Ответ

10 голосов
/ 13 января 2011

Большое спасибо за ваши комментарии.

Мне удалось уменьшить задержку до ~ 0,4 мс.Команда setserial (8) упоминалась в руководстве AEL.Кроме того, я обнаружил там флаг low_latency со следующим описанием:

Минимизируйте задержку приема последовательного устройства за счет большей загрузки ЦП.(Как правило, задержка в среднем составляет 5-10 мс, прежде чем символы передаются на линейный дисклайн, чтобы минимизировать накладные расходы.) Это отключено по умолчанию, но некоторые приложения реального времени могут найти это полезным.

Затем я выполнил setserial /dev/ttyS1 low_latency, и задержка была уменьшена до ~ 0,4 мс: -)

Но я хотел реализовать это поведение в приложении C ++, не устанавливая этот флаг глобально с помощью setserial (эта команда по умолчаниюне входит во все дистрибутивы).

Я добавил следующие строки кода, которые имели тот же эффект, что и флаг low_latency из setserial: 

#include <sys/ioctl.h> 
#include <linux/serial.h>
// Open RS232 on COM1
mPhysicalComPort = open(aPort, O_RDWR | O_NOCTTY | O_NDELAY);
struct serial_struct serial;
ioctl(mPhysicalComPort, TIOCGSERIAL, &serial); 
serial.flags |= ASYNC_LOW_LATENCY; // (0x2000)
ioctl(mPhysicalComPort, TIOCSSERIAL, &serial);
...