Последовательный порт: не в состоянии записать большой кусок данных - PullRequest
1 голос
/ 10 марта 2010

Я пытаюсь отправить текстовые данные с одного компьютера на другой с помощью последовательного кабеля. Один из ПК работает под управлением Linux, и я отправляю данные с него с помощью системного вызова write (2). Размер журнала составляет около 65 Кбайт, но системный вызов write (2) возвращает около 4 Кбайт (т.е. этот большой объем данных передается). Я пытался разбить данные на блоки по 4K, но write (2) возвращает -1.

У меня такой вопрос: «Есть ли ограничение буфера для записи данных на последовательный порт? Или я могу отправлять данные любого размера? 1003 *

Нужно ли выполнять какую-либо специальную настройку в структуре termios для отправки (огромных) данных?

Ответы [ 3 ]

1 голос
/ 10 марта 2010

Да, есть предел буфера - но когда вы достигнете этого предела, write() должен заблокироваться.

Когда write() возвращает -1, для чего errno установлено значение?

1 голос
/ 10 марта 2010

Буфер передачи составляет одну страницу (взглянул на источники Linux 2.6.18) - что составляет 4 КБ в большинстве (если не во всех) случаях.

Другой конец должен прочитать (не знаюразмер буфера приема), но, что более важно, вы не должны писать быстрее, чем может передавать последовательный порт, если вы используете скорость 115200 бит / с 8-N-1, вы можете записать блок 4K примерно 3 раза в секунду.(115200/9/4096 = 3,125)

0 голосов
/ 10 марта 2010

Убедитесь, что приемник читает.

Вы должны обновить текущую позицию в вашем буфере из функции write () и продолжить следующую запись оттуда. (Применяется ко всем write (), независимо от того, является ли fd последовательным портом, сокетом tcp или файлом.)

Если вы получите сообщение об ошибке для последующих записей. Судя по man-странице, безопасно повторить записи для следующих ошибок: EAGAIN, EINTR и, вероятно, ENOSPC. Используйте perror (), чтобы увидеть, что вы получите. (.. и опубликовать его, мне любопытно.)

Казалось бы, EFBIG указывает на то, что вы пытаетесь писать, используя буфер (или, скорее, счетчик), который слишком велик, но, вероятно, намного больше, чем 64 КБ.

Если внутренний буфер заполнен, потому что вы пишете в fast, попробуйте (nano) немного поспать между операциями записи. Есть несколько умных способов сделать это (как это делает tcp), но если скорость известна, просто пишите с фиксированной скоростью.

Если вы считаете, что приемник на самом деле читает, но ничего особенного не происходит, взгляните на параметры управления потоком через последовательные порты и не подключен ли кабель для DTS / RTS.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...