UART: аппаратное управление потоком

Точного ответа не знаю, но CTS нельзя устанавливать, его можно только читать, то есть "serial | TIOCM_CTS " неправильно.

>В итоге ни CTS ни RTS не изменяются.

Программа то что выводит?

>ни один из типов форматирования

http://www.linux.org.ru/wiki/en/Lorcode тоже не подошёл?

>то есть "serial | TIOCM_CTS " неправильно.

да, я знаю, это от безысходности уже пробую.

>Программа то что выводит?
Сначала выводила что ни тот ни другой не установлен.
Поменял TIOCMSET на TIOCMBIC или TIOCMBIS - вродь как что-то меняет, судя по сообщениям.
Хотя вольтметр показывает, что уровень не меняется. Возможно дело в том, что там еще USB->Serial шнурок присутствует. Сейчас пробую без него на чистом /dev/ttySx. О результатах напишу.

А вы пробовали использовать эти ioctl?


>http://www.linux.org.ru/wiki/en/Lorcode тоже не подошёл?
попробовал, предпросмотр различий в результате от TeX w/o quoting не заметил. Браузер konqueror (4.3.1).

www.linux.org.ru/wiki/en/Lorcode тоже не подошёл?

а, работает, про теги первый раз услышал, спасибо, буду пользоваться

> А вы пробовали использовать эти ioctl?

Пробовал как-то. Для одного бестокового АЦП надо было. Адекватного поведения добиться не удалось, забил огромный преогромный хер и выкинул этот АЦП. И даже не жалею :)

Когда решишь проблему, обязательно отпиши. Авось из дальнего ящика достану это г*вн* мамонта и попробую завести опять.

Кажется решил. Работает весьма странно, но пин переключает. Следующий код запрещает передачу, путем установки RTS.

int new_serial = TIOCM_RTS;
if ( ioctl(fd, TIOCMBIS, &new_serial) ) {
    fprintf(stderr, "ioctl TIOCMBIS failed : %s\n", strerror(errno));
    return -1;
}

Но есть нюанс. У меня это заработало на чистом /dev/ttyS1. На /dev/ttyUSB0 не заработало. Или переходник USB->Serial не поддерживает эту штуку, то драйвер такой.

Позвольте полюбопытствовать. Исходя из банальной эрудиции, аппаратное управление потоком работает автоматически исходя из условия наличия места в буфере приемника. Если места нет, то автоматом выставляется "занято". Передатчик прерывает передачу. Как только буфер вычитали, сигнал "занято" снимается и передача возобновляется. Поправте, где я не прав. И если прав, то в этой модели, управление RTS не имеет смысла.

Исходя из банальной эрудиции, аппаратное управление потоком работает автоматически исходя из условия наличия места в буфере приемника. Если места нет, то автоматом выставляется «занято».

Не все контроллеры работают в автоматическом режиме. Иногда используется и ручное управление потоком. Такая ситуация и у моих заказчиков. Их железка тянет с моей железки данные по RS-232 и тормозит поток, когда ей это нужно. Мне нужно было промоделировать эту ситуацию. А лезть на уровень ядра для этого не хотелось.

Тогда это называется программное управление потоком XOFF/XON. Какой-то странный подход, с одной стороны контроллер не поддеживает аппаратное управление потоком, при этом программное управление никто не реализовывает.

Железка заказчика не просто так тормозит, она просто из буфера не успевает вычитывать. Все это реализуется прозрачно и аппаратно. И тестировать нужно так же.

А то что вы нашли способ управлять пином. Это какой-то аппаратный баг, побочный эффект. Это как раньше по LPT делали ввод по шинам D0-D7. Выдаем на него 0xFF, а снаружи нужные пины заземляем. При чтении из порта это обнаруживается.

Согласен, подход был не верным.

Я не знаю точно как заказчик управляет CTS/RTS, возможно и в автоматическом режиме. Но все же некоторые linux драйверы (например, для некоторых процессоров blackfin) умеют эмулировать hardware flow control через GPIO. Следовательно такой подход также используется.

Не думаю, что управление пином - это аппаратный баг и побочный эфект. Подобная возможность есть и под Windows.

Про "брак" беру слова обратно. Таки залез в спецификацию 16550А и выяснилось что: Назначение бит регистра MCR: * Биты [7:5]=0 - зарезервированы. * Бит 4 - LME(Loopback Mode Enable) - разрешение режима диагностики: o 0 - нормальный режим, o 1 - режим диагностики (см. ниже). * Бит 3 - 1Е( Interrupt Enable) - разрешение прерываний с помощью внешнего выхода OUT2; в режиме диагностики поступает на вход MSR.7: o 0 - прерывания запрещены, o 1 - разрешены. * Бит 2 - OUT1C (OUT1 Bit Control) - управление выходным сигналом 1 (не используется); в режиме диагностики поступает на вход MSR.6. * Бит 1 - RTSC (Request To Send Control) - управление выходом RTS; в режиме диагностики поступает на вход MSR.4: o 1 - активен (-V), o 0 - пассивен (+V). * Бит 0 - DTRCfData Terminal Ready Control) - управление выходом DTR; в режиме диагностики поступает на вход MSR.5: o 1 - активен (-V), o 0 - пассивен (+V). LSR - регистр состояния линии (точнее, состояния приемопередатчика).

Принципиально дергать их можно. Вопрос, только как это скажется на работе всего контроллера. Опять же дока говорит, что "дергать" лучше в диагностических целях. Опять же неизвестно что будет с передатчиком который словит сигнал, он завершит передачу байта? или сразу тормознет. Если сразу тормознет, то несколько бит застрянет во входном регистре приемника и по идее их нужно будет от туда вычистить.

Вобщем нужно погружаться в дебри.