DSDOS для ПРК "Орион-128"

[OldSpeccer]

Мои поздравления с оживлением суперкомпьютера!

Мерси! Тренировка синаптических соединений

По вопросам.
Для корректной работы ВВ51 интерфейс должен быть полноценным, сигналы RTS/CTS она обрабатывает. Соответственно, получаются два варианта: либо мы "затыкаем" RTS/CTS перемычками (7-8 контакты разъёма DB-9) на каждой стороне и т.о. обманываем протокол, либо делаем честный линкер с перекрёстной передачей сигналов RTS/CTS. В первом случае в сервере (на писи) в настройках порта параметр "Flow Control" ставим в "None", во втором случае - "Hardware".

Специально проверил "затычки" - имеются с обоих концов. Никак не влияет. Flow control разумеется везде стоит в none - и в настройках порта в системе, и в настройках "орион-сервера".

Скорее всего где-то аппаратная неисправность. "Лупбэк" (но только с обоих концов!) должен решать вопрос.

В теории. Однако вот что получается. На выходе /RTS порта ВВ51 - неизменно высокий уровень, единица. Замыкаясь на /CTS через перемычку по RS-232, он все равно транслируется в единицу - передачи нет, прием есть. Неисправность ВВ51 исключена. Состояние /RTS не меняется при попытке из ОС обратиться к диску.

В сборках прошивок ОС, в конце есть файлы теста портов СОМ1 и СОМ2, с их помощью можно полноценно протестировать соответствующие порты, в т.ч. и "лупбэком", т.е. замыкаем 2+3 и 7+8 на разъёме СОМ-порта Ориона, в результате чего тест будет печатать задвоенные символы (отправленный и принятый).

Ну конечно, я разобрался - я ж писал выше, что в терминальном режиме (из программы TSTcom1$) я вижу отправляемое с ПК - это было и с ВИ53-й, и с внешним геном. Лупбэк не двоит символы, потому что нет передачи. Если /CTS принудительно опустить в 0 - передача есть,
лупбэк работает, в терминале вижу печатаемое на Орионе, и наоборот - все проходит. Вот только не видит Орион сервера.

В "быстрой" реализации порта (COM2, на 16C550) программно отключена обработка RTS/CTS, т.о. возможно использование "кастрированного" линкера, у которого сигналы RTS/CTS висят в воздухе. При этом в настройках порта сервера "Flow Control" ставим в "None".

Ах если бы у меня не лежало больше 30-ти ВВ51-х - возможно это был бы и вариант Для начала все же запустим на ВВ51,
тем более, что так истинно труъ А в настройках ВВ51 нельзя включить игнор /CTS?

К сожалению, у меня олд-скул что называется "по жизни", и домашние компы примерно уровня Пентиум-3, разлива 2001-го года Соответственно, Винда там ХР, обычная 32-битная. Проверить работоспособность сервера на новомодных 7-ках, 8-ках и 10-ках и 64-битных версиях у меня возможности нет (( Поэтому не могу гарантировать правильную работу старинной компонеты СОМ-порта на таких системах. Если кто-то исследует вопрос, буду благодарен за обратку.

Не вижу причин, почему бы оно не работало, если оно через Win32Api порт дергает. Повторю - в терминале - все работает. Точно тот же порт.

Лично пробовал USB-реализацию СОМ-порта в виде шнурка-переходника - у меня не "взлетела", работать работало, но периодически были ошибки в передаваемых данных в сторону Ориона (ошибка в старшем бите), подозреваю что проблема в плохом согласовании уровней сигналов (в шнурке скорее всего MAX232, а у меня в Орионе "трэш" на КТ315 ). В итоге для увеличения кол-ва портов в писюке нашёл PCI-карту с двумя СОМ-портами, которая заработала сразу "из коробки", на чём и успокоился.

Ну да, всякие согласователи - пройденный этап. Имею количество 232-х конверторов примерно от 5-ти разных производителей, установил сходу TI-ные МАХы. Вариант несогласования - не вариант.

Скорее всего проблема где-то на начальной стадии протокола, т.е. Орион отправил запрос серверу и не получил ответ.
В сервере начиная с версии 2.05 есть возможность подробного логирования ошибок, для этого нужно включить обе галочки "Журнал" и "Подробно". Поскольку протокол всегда двухсторонний, то ошибка на Орионе также приведёт и к ошибке на писи, которую сервер зафиксирует в лог, который можно посмотреть нажав кнопку "Журнал операций". Там будет HEX-код ошибки, по которому я смогу попытаться понять на каком участке алгоритма обмена происходит сбой. Чем меньше код, тем ближе к началу протокола проблема.
Опять же, для начала лучше просто проверить связь Орион<->Писи с помощью тестов, передавая как одиночные символы, так и строки. По ошибкам в строках можно уже примерно предположить характер проблемы.

Возвращаю /CTS на землю. Передаю байты в ПК - их видно в терминале. Символы соответствуют, местами регистр не совпадает, но все
правильно - одиночные символы ок. При передаче текста с ПК на Орион - иногда пакет проходит полностью, иногда теряется первый байт. Строго и только первый. при нажатии любой клавиши в режиме DUMP на орионе вылетает сообщение об ошибке без комментариев.
В логах орион-сервера естественно ничего не находится, ибо, как я уже говорил, попытка обращения к диску G: не вызывает никакой активности на линии TxD, даже с /CTS опущенным в 0.

- - - Добавлено - - -

А как потом обеспечить подачу лог.1 на инверсных чипселектах при выключении питания? Это одно из условий хранения информации в СОЗУ.

Первое, что приходит в голову - ставим НС138 в качестве ИД7. Потребление КМОП в статике - микроампер... При 3 вольтах и околонулевых токах вполне будет себе единички держать, разве нет?

- - - Добавлено - - -

На всякий случай соединил /RTS c /CTS минуя конвертер, замкнул 17 вывод ВВ51-й с 23-м. Симптомы те же - передачи нет, лупбэк не двоит символы. Все еще не хочется верить, что придется аппаратный flow control делать. Denn, у вас ведь работало без него на ВВ51? Или не однозначно...? И как бы там ни было - данные передаются-принимаются, ну теряется ингда там байт, но в вашем протоколе ведь сверка контрольных сумм предусмотрена, правда?