Загадочная проблема с COM портом.

Проблема заключается в том что к ПЭВМ подключено специфическое оборудование, взаимодействие с которым осуществляется через COM порт

что данные пройдя через Com порт и вернувшись обратно на ПЭВМ искажаются.

Это так это оборудование работает? В него загружается файл, а потом он его возвращает? Попробуй для начала джампером обычным замкнуть 2 и 3 контакты COM (петля). И погоняй данные, проверь порты.

попробуйте спросить тут: https://forum.astralinux.ru/

Попробую! Но если бы проблема была в нём, то аналогичной проблемы не было бы на usb to com (если нет, поправьте). Сегодня в терминале увидел сообщение об отключении питания usb и его перезапуске. Если оно вылезло в терминале значит оно критическое исходя из настроек rsyslog. Возможно дело куда хуже и за мнимой работой системы скрываются серьезные проблемы с поддержкой портов... Изучу на днях журналы повнимательнее и отпишусь!

Вот ответ официальной техподдержки: «По возможности, проверьте поведение COM в Debian Wheezy(7.8)». Увы возможности нет. Я так понимаю они хотят проверить - их доработки привели к такому поведению или нет.

Учитывая что проблема явно программная и отсутствие у тебя возможности сменить софт, остаётся только бодаться с ними. У дебиана вроде live-cd были?

взаимодействие с которым осуществляется через COM порт

Для начала не помешает схема COM-порта: http://www.compilog.ru/images/raspinovka_COM_porta.gif

через программное обеспечение для МСВС, теперь до нас довели аналогичное но для Astra Linux

С Astra не связывался, а как в ней вообще система устройств организована, также как и во всех линях, через /dev, или как-то по другому?

$ ls /dev/ttyS0

Если как во всех линях, пробуй напрямую общаться, а не через какое-то подозрительное ПО:

$ cat output.txt > /dev/ttyS0
$ cat /dev/ttyS0 > input.txt

См. также /dev/ttyS0

До этого взаимодействие осуществлялось через программное обеспечение для МСВС, теперь до нас довели аналогичное но для Astra Linux

Получается новая, и новая «свежая» версия ПО? Как говорил Щас Баг Вам Дам: Двойной удар!

Программа ведь может сама устанавливать режим работы com-порта, поэтому stty смотреть смысла нет. Сравните strace при передаче одинакового файла с ноутбука и с проблемного компа, какой там устанавливается режим работы com порта. И файл, поди, передаётся без шифрации, записываемы/читаемый байты должны совпадать в обоих трейсах.

Файлы устройств Com портов в Астре находятся в /dev/. Оборудование не принимает информацию отправленную на порт через cat, даже при правильной настройке порта. Возможно, оборудование посылает какие-то команды о готовности к работе (либо программа посылает оборудованию тоже самое) и только после обмена данными сообщениями начинается передача. В момент передачи с оборудования на компьютер команда cat ничего не перехватывает, tails -F тоже.

оборудование посылает какие-то команды о готовности к работе

Так перемкни скобкой TX-RX и посмотри что там эта прога пересылает через cat.

Скорости стандартные? Особо хреновые адаптеры не умеют устанавливать скорость не из стандартного ряда.

когда дело доходит до килобайтов файлы искажаются

Походит на то, что буфер переполняется.

Я бы еще посмотрел управление потоком, не включено ли XON/XOFF, например, вместо обычного аппаратного RTS/CTS. Если зависимость характера искажения от самих данных есть, то можно покопать в этом направлении.

Сегодня в терминале увидел сообщение об отключении питания usb и его перезапуске

я в своё время много работала с USB. есть такая фигня у некоторых контроллеров - они при сбросе питания шлют в сеть левые данные. и если на компе работает какой-нибудь ACPI, который отключает и ресетит чип, то с него могут в канал улетать «лишние» байты. выход - отключать управление питанием на USB шине на компе. но надо проверить, что это происходит именно при сбросе питания. могут быть другие причины.

вообще, в любом случае данные, передаваемые через COM, должны нести в себе какой-то CRC-код, чтоб проверять их валидность. потому что канал очень ненадёжный, подверженный наводкам и всяким прочим напастям.

Какая астра стоит: SE или CE? В случае SE нужны специальные приседания, чтобы ttyS0 работал.

«Искажается и меняется размер» однозначно проблемы с настройкой скорости обмена. Причем скорей всего не совпадает скорость у разных устройств и первые несколько байт приходят нормально, а дальше все бьется. Попробуйте снизить скорость для диагностики (чем меньше скорость тем больше байт подряд приходят без искажений).

Вот ответ официальной техподдержки: «По возможности, проверьте поведение COM в Debian Wheezy(7.8)».

Вообще, если изготовитель оборудования рекомендует определенную ось, то нужно иметь очень веские причины чтобы ставить другую. Почему, собственно, вы используете астру для оборудования, которое явным образом рекомендует дебиан?

В моей организации используется астра, и изготовитель астры, а не оборудования рекомендует дебиан))))

Проверял на всех скоростях. Устанавливал одинаковые скорости на оборудовании и в ПО. Глядя через stty ПО устанавливает скорость корректно. Астра SE 1.5. На ноутбуке где я пробовал всё работает отлично без приседаний. Но если скажите какие - лишним не будет.

Да, всё стандартно. 9600 и поехали далее...

Устанавливал одинаковые скорости на оборудовании и в ПО.

под скоростью обмена я имел виду насколько эти скорости совпадают (даже при одинаковых настройках). Если тактовая частота контроллера последовательного порта сильно отличается, и прога об этом не знает, то при установке 9600 в реальности будет 9400 (проверять осциллом или подобным). Но обычно этим грешит именно аппаратура (особенно самоделки на avr/arm/stm). В компах это стандартный вылизанный блок.

Насчет «приседаний» не скажу. Помню, что пытались настраивать через встроенный в мать ttyS0 управляемый коммутатор, но порт так и не заработал. Хотя когда взяли usb-com, то все сразу взлетело. Возможно была проблема с матерью и настройками биос-а (хотя вроде все там перерыли). Возможно какие-то разрешения в астре, но какие именно обнаружить не удалось.

Еще раз перечитал про ваши искажения на больших файлах. Точно проблема в том, что не точно уставлены скорости обмена. На мелких посылках не успевают разъехаться границы битов, а на больших все расплывается. Пихайте осцилл в порт шлите 0x55 и считайте размер бита. Потом пересчитывайте в боды.

Прога не пересылает ничего пока не установит соединение с оборудованием. В момент передачи порт занят и cat ничего не показывает.

Значит надо соединить два порта и смотреть что на второй выпется.

Прога не пересылает ничего пока не установит соединение с оборудованием. В момент передачи порт занят и cat ничего не показывает.

А по «человечески» можно. Со скрепкой прога не работает? И какая именно команда ничего не выдаёт (напиши её здесь, не поленись)?

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

В момент передачи файлов команды ничего не выдают:

cat /dev/ttyUSB0

tail -F /dev/ttyUSB0

Оборудование не реагирует на команды:

echo «123» > /dev/ttyUSB0

cat ./123.txt > /dev/ttyUSB0

При установки перемычки на 2 и 3 контакты эти команды работают и если отправлять сообщения они появляются.

То что переходник USB to COM исправен не приходится сомневаться, так как на ноутбуке всё отлично работает.

При установки перемычки на 2 и 3 контакты эти команды работают и если отправлять сообщения они появляются.

Тогда почему нельзя поставить перемычку, в консоли дать команду:

cat /dev/ttyUSB0

и запустить эту подозрительную программу? И смотреть в консоле, чем же она пичкает это подозрительное устройство?

А как у вас дела с заземлением компьютеров и этого спец оборудования?

Пробовал отключать Com в биосе и работать только через переходник, менять настройки USB портов. Результата нет. Пробовал смотреть на настройки портов (stty) - они одинаковы и у работающего ПЭВМ и у неработающего.

ПО может неправильно программировать порт, например. Пробуй на тесте по кольцу, исключи ПО, пересылай файлы из одного терминала, лови их в другом терминале. Вот, например.

QinHeng Electronics HL-340 USB-Serial adapter (USB-to-COM) (комментарий)

Если все работает как надо, то проблема в ПО, скорее всего.

И еще вопрос: а как кабель устроен? Используется ли там аппаратное управление потоком или это просто нуль-модем? Наверняка же должна быть распиновка кабелей.

поснифь трафик через wireshark. Ну или для бедных через socat

Имея опыт низкоуровневого прогания компортов еще с досовских времен, скажу тебе, что нюансы бывают, иногда просто пи-дец какие. И я тебе сочувствую, ты точно лососнул тунца.

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

Я бы предложил сменить комп или материнку на другой тип или хотя бы поставить другую pci-карточку с компортом. Можно еще как-нибудь попытаться воссоединить разработчика проги и твой сервер, удаленно или локально.

И не используй в проме usb-com адаптеры.