Программирование com-портов. Изменение буфера r/w FIFO?

Question

[dlinyj]

Доброго времени суток.


Ваяем тут одну железяку с кучей СОМ-портов, работающую под линем. И для отладки драйверов и железа ваяю программу тестирования СОМ-портов. Чтобы не изобретать велосипед за основу была взята программа linux-serial-test.


Эмпирическим путём мы поняли, что при передаче данных в порт, они записываются в промежуточный буфер, а от туда уже передаются в СОМ-порт (америку мы не открыли, просто открыли размер этого буфера). Оказалось, что он занимает 4 килобайта. Получается забавная вещь, что вызывая процедуру передачи данных, по готовности порта пример кода

void process_write_data()
{
	int count = 0;
	unsigned char write_data[1024] = {0}; //буфер 1 килобайт
	while (1) {
		int i;
		for (i = 0; i < sizeof(write_data); i++) { //заполняем буфер данными
			write_data[i] = _write_count_value;
			_write_count_value++;
		}

		int c = write(_fd, &write_data, sizeof(write_data));

		if (c > 0) {
			_write_count += c;
			count += c;
		}
		if (c < sizeof(write_data)) { //проверяем всё ли передали?
			_write_count_value -= sizeof(write_data) - c;
			break; //да, всё, выходим из цикла
		} else {
			count += c;
		}
	}
}

Мы не можем быть уверенны в том, что данные передались. Фактически получается так, что система нам говорит о готовности передачи, мы укладываем туда данные, а фактически мы укладываем 4 килобайта внутреннего буффера, и данные ещё даже не начали передаваться.

Внимание вопросы:
1. Возможно ли изменить с помощью, например, ioctl размер буфера записи/чтения (драйвер пока перепахивать не очень хочется)?
2. Есть ли возможность сделать более real time передачу через СОМ-порт (со стороны user space и kernel space)?

Answer 1

[Ariman]

Доки на драйвер говорят, что буферы не более 64 байт, а обычно и вовсе 16.
Килобайтные буферы, если они и есть, находятся выше собственно драйвера последовательного порта.

Comments

[dlinyj]

А можно посмотреть какие доки вы читаете?

[Ariman]

Да первые же нагуглившиеся:
http://www.tldp.org/HOWTO/Serial-HOWTO-18.html#ss18.2

А, вот.

>It's been mentioned that there are 3 buffers for each direction of flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair of larger buffers inside a device connected to the serial port (such as a modem), and a pair of buffers (say 8k) in main memory. When an application program sends bytes to the serial port they first get stashed in the transmit serial port buffer in main memory. The other member of this pair consists of a receive buffer for the opposite direction of byte-flow. Here's an example diagram for the case of browsing the Internet with a browser. Transmit data flow is left to right while receive flow is right to left. There is a separate buffer for each direction of flow.

application 8k-byte 16-byte 1k-byte tele-
BROWSER — MEMORY — FIFO — MODEM — phone
program buffer buffer buffer line

[dlinyj]

Ну во первых, у меня апаратаное решение не подпадает ни под одно из описанных.
У меня стоит микросхема MAX14830 и там он 128 байт. НО! Это АППАРАТНЫЙ буфер и его не нужно трогать. Я же говорю внутриядерный буфер драйвера

Мой вопрос только по части софта!

[Ariman]

Ну вот я смотрю в драйвер tty, верхний самый.
>tty_wait_until_sent
есть вот такая функция, экспортируемая им.

/**
 *	tty_wait_until_sent	-	wait for I/O to finish
 *	@tty: tty we are waiting for
 *	@timeout: how long we will wait
 *
 *	Wait for characters pending in a tty driver to hit the wire, or
 *	for a timeout to occur (eg due to flow control)
 *
 *	Locking: none
 */

Answer 2

[Ariman]

Это буфер TTY, вот чего.
Строка 51 include/linux/tty.h
По умолчанию — одна страница. Задать индивидуально для ком порта вы не сможете, как я понимаю, только изменить глобальный размер TTY во всей системе. Но можно попробовать подергать этот самый tty_wait_until_sent, чтобы понять, когда данные из буфера ушли в железо.

Comments

[dlinyj]

Спасибо добрый человек за идею! Мы тут ещё пошерстили, и нашли интересные вещи.

В функции

long tty_ioctl(struct file *file, unsigned int cmd, unsigned long arg)

Есть вызов функции изменения окна lxr.free-electrons.com/source/drivers/tty/tty_io.c#L2750. В описании сказано:

/**
 *      tiocswinsz              -       implement window size set ioctl
 *      @tty; tty side of tty
 *      @arg: user buffer for result
 *
 *      Copies the user idea of the window size to the kernel. Traditionally
 *      this is just advisory information but for the Linux console it
 *      actually has driver level meaning and triggers a VC resize.
 *
 *      Locking:
 *              Driver dependent. The default do_resize method takes the
 *      tty termios mutex and ctrl_lock. The console takes its own lock
 *      then calls into the default method.
 */

Единственное, надо глянуть под ядро 3.3.8 (давно ведётся разработка, ядрышки убежали вперёд :). )

[Eddy_Em]

На крайняк можно просто модуль ядра пропатчить…

[dlinyj]

Eddy_Em этим вовсю занимаемся, но размер буфера лежит несколько выше…

Answer 3

[Руслан Лопатин]

В коде драйверов COM-портов для Java, например в PureJavaComm, встречал очень простой способ: смотрим скорость передачи и делим на неё размер данных. Получаем время, которое нужно подождать до завершения передачи.

rs232 ну очень примитивный протокол. Передача идёт постоянно, с одной и той же скоростью, пока в буфере есть данные. И не важно, подключено ли к порту устройство, которое эти данные получает. Способа определить наличие устройства нет.

Ну а размер буфера указать можно, так же как и и узнать переданы ли все данные из буфера. Сказать какие ioctl использовать, к сожалению, не могу. Но разобраться довольно легко. Для примера, как это делается, можно заглянуть в код PureJavaComm — там есть соответствующие вызовы.

Comments

[dlinyj]

В коде драйверов COM-портов для Java, например в PureJavaComm, встречал очень простой способ: смотрим скорость передачи и делим на неё размер данных. Получаем время, которое нужно подождать до завершения передачи.

rs232 ну очень примитивный протокол. Передача идёт постоянно, с одной и той же скоростью, пока в буфере есть данные. И не важно, подключено ли к порту устройство, которое эти данные получает. Способа определить наличие устройства нет.

По моему это на столько очевидные вещи, что человеку, который пишет драйвер их объяснять не нужно :).

Простите, а почему вы этот код называете драйвером? и Я там не нашёл контроля. В моём примере запись/чтение идёт по готовности, таким образом:

	struct pollfd serial_poll;
	serial_poll.fd = _fd;

	while (1) {
		int retval = poll(&serial_poll, 1, 10000); //ожидаем события - готовности передачи, приёма или таймаута 10 секунд
		if (retval == -1) {
			perror("poll()"); 
		} else if (retval) {
			if (serial_poll.revents & POLLIN) {
				process_read_data();
			}

			if (serial_poll.revents & POLLOUT) {
				process_write_data();
			}
		} else {
			printf("No data within ten seconds.\n");
		}
	}

poll — ожидает некоторое событие в файловом описателе

Как только состояние меняется, функция высвобождается и идёт проверка, что же произошло. Но по сути идёт проверка готовности буферов!

[Руслан Лопатин]

Ну, потому что это драйвер и есть. Только драйвер для Java, а не для ОС. Ну и тот файл, на который ссылка — это реализация отдельных вызовов для Linux. Реализация логики здесь.

А насчёт poll — вы уверены, что сигналы идут именно о записи в буфер? Если так, то ой. Видимо, слушать события от порта не получится. Но всегда остаётся вариант с подсчётом времени, необходимого на отправку. Ну или ждать момента получения ответа — как у вас в коде. Ответ есть — значит данные отправлены. Логично?

[dlinyj]

Не логично. Задача либо поменять размер буфера, либо реализовать более жесткое общение с портом (пусть ценой переписывания драйвера). Просто, как мне кажется задача тривиальная и наверняка кто-то с ней сталкивался.

[Руслан Лопатин]

А tcdrain не помогает? Этот вызов должен ждать, пока данные не будут переданы.

[mayorovp]

rs232 ну очень примитивный протокол. Передача идёт постоянно, с одной и той же скоростью, пока в буфере есть данные. И не важно, подключено ли к порту устройство, которое эти данные получает. Способа определить наличие устройства нет.

Да неужели?

То есть DTR/RTS отменили, как и прочие механизмы?

[Руслан Лопатин]

mayorovp, ну, значит я не прав. А они всегда применяются, эти DTR/RTS? Даже когда используется software flow control? Я думал, что на устройстве, с которым работал это не поддерживается (там DTR off, RTS off устанавливается — и всё). Мне правда нужно знать, раз уж я этой темой занялся.

[dlinyj]

lorus

Почитайте про аппаратную работу с модемом с полным (25 pin) COM-портом. Занимательное чтиво :)

[mayorovp]

lorus, для использования software flow control на com-порт ставят специальную перемычку, замыкающую контрольные и статусные линии. Но даже в таком случае драйвер ядра не начнет выдавать в порт данные, пока не обнаружит эту самую перемычку.

Answer 4

[Руслан Лопатин]

Мда, а размер буфера PureJavaComm не устанавливает.

Answer 5

[Ariman]

(Случайно дублировался пост)