Ioctl tiocmset protocol error

Arduino Uno R3 failure

Recently I’ve got a genuine Arduino Uno R3 from my friend to repair. The problem with his board was actually very generic – it has just stopped working. Personally, I don’t buy such boards, because they are extremely overpriced. I have been using several Chinese clones around for years and I have not encountered any problems so far.

At first sight, the USB interface was working fine and the board was detected by the system without any problems.

However, there was a problem with flashing a program with avrdude. The result log:

The microcontroller was fine, I successfully burned the bootloader to ATmega328P using another board acting as ArduinoISP. After several retries to flash the Arduino board via USB, I found out that the device sometimes disappeared from the system.

Finally, I took an oscilloscope… and immediately tracked down a faulty component. The 16 MHz crystal oscillator for ATmega16U2 was providing very weak signal level.

I replaced it with another 16 MHz crystal, which is a reliable clock source.

The Arduino board works perfectly again.

The photo below presents the faulty crystal oscillator.

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

Программирование RS232 устройства (Попытки подобрать протокол для ТСД)

Программирование RS232 устройства

Сообщение reinhard » 10.07.2007 08:29

Есть терминал сбора данных CIPHERLAB 8001 с последовательным интерфейсом. Программа для загрузки в него данных только под Windows. Требуется, чтобы он заработал под Linux. Под wine не заработала.
Под виндой запускаю HHD Serial port monitor и запускаю обмен данными. Программа и устройство настроены на 115200.
Вот такой протокол обмена (по данным монитора).

Далее около 20 тыс. строчек, повторяющих строчки 50-51.
Затем:

Далее протокол продолжается, я его «прицепил».
Но мне не удается дойти даже до этого места.

Вот как я понимаю что происходит:
комп лочит порт на 9600, сбрасывает RTS, посылает устройству символ с кодом 0x0f, пытается прочитать из порта, у него ничего не выходит.
Затем он лочит порт на 115200, сбрасывает RTS, посылает устройству символ с кодом 0x0f, и на этот раз успешно читает его из порта.
Осталось непонятным что означает

[red]IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_SET_HANDFLOW: Set handshake information),DOWN,TRUE,0x0,01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . [red]
Понятно, что это установка параметров handshake, но каких именно — не могу нигде найти. Подозреваю, что проблема именно в этом.

Вот код программы:

Будучи запущенной программа выводит

т.е. записала успешно, а прочитать не удалось в обоих случаях.
Пробоват подключать модем и писать в него AT — все работало, т.е.
Опыт программирования RS232 у меня более чем скромный, поэтому прошу помощи и/или указания на ошибки.
Заранее благодарен!

Источник

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

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 — регистр состояния линии (точнее, состояния приемопередатчика).

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

Источник

Please be positive and constructive with your questions and comments.

avrdude -p attiny2313 -P /dev/ttyUSB1	 -c dasa -U flash:w:digg.hex

ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
ioctl("TIOCMSET"): Protocol error
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

make: *** [program-digg] Error 1

Please be positive and constructive with your questions and comments.