LINUX.ORG.RU
Форум — Development  

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


0

0

Приветствую всех!

Интересует аппаратное управление потоком при помощи CTS/RTS сигналов из userspace.
Необходимо запретить передачу на порт при помощи RTS пина. У кого-нибудь это получалось?

пробую таким макаром:
int serial, new_serial;
if ( ioctl(data_fd, TIOCMGET, &serial) ) {
fprintf(stderr, "ioctl TIOCMGET failed : %s\n", strerror(errno));
return -1;
}
if (serial & TIOCM_CTS)
puts("TIOCM_CTS is not set");
else
puts("TIOCM_CTS is set");
if (serial & TIOCM_RTS)
puts("TIOCM_RTS is not set");
else
puts("TIOCM_RTS is set");


new_serial = serial | TIOCM_CTS | TIOCM_RTS;
if ( ioctl(data_fd, TIOCMSET, &new_serial) ) {
fprintf(stderr, "ioctl TIOCMSET failed : %s\n", strerror(errno));
return -1;
}


if ( ioctl(data_fd, TIOCMGET, &serial) ) {
fprintf(stderr, "ioctl TIOCMGET failed : %s\n", strerror(errno));
return -1;
}
if (serial & TIOCM_CTS)
puts("TIOCM_CTS is not set");
else
puts("TIOCM_CTS is set");
if (serial & TIOCM_RTS)
puts("TIOCM_RTS is not set");
else
puts("TIOCM_RTS is set");

В итоге ни CTS ни RTS не изменяются.
Может кто-нибудь что-то подскажет?

===============
извиняюсь за форматирование, ни один из типов форматирования, предложенных лором не показывает код нормально.

★★★★

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

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

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

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

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

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

mky ★★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от mky

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

>то есть "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).

Dead ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от Dead

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

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

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

balodja ★★★
()
Ответ на: Re: UART: аппаратное управление потоком от balodja

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

Кажется решил. Работает весьма странно, но пин переключает. Следующий код запрещает передачу, путем установки 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 не поддерживает эту штуку, то драйвер такой.

Dead ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от Dead

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

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

yax123 ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от yax123

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

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

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

Dead ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от Dead

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

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

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

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

yax123 ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от yax123

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

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

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

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

Dead ★★★★
()
Ответ на: Re: UART: аппаратное управление потоком от Dead

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

Про "брак" беру слова обратно. Таки залез в спецификацию 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 - регистр состояния линии (точнее, состояния приемопередатчика).

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

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

yax123 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development