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? Или не однозначно...? И как бы там ни было - данные передаются-принимаются, ну теряется ингда там байт, но в вашем протоколе ведь сверка контрольных сумм предусмотрена, правда?

[Advertiser]

[Denn]

OldSpeccer, я так понял, у вас в качестве преобразователя интерфейса в Орионе используется MAX232 ?
Тогда действительно проблем быть не должно.

На всякий случай вот мой вариант связки ВВ51+MAX232 - http://denn.ru/orion/512/rs-232/com1..._schematic.jpg
Этот вариант включения точно рабочий, я его макетировал и проверял, за него я могу ручаться.

Тесты должны работать без ухищрений типа "вход ВВ51 на 0" ! Либо перемычки 7-8, либо честный нуль-модемный линкер. Если в таком варианте тест работает в обе стороны, то и сервер будет работать без проблем.
Важный момент! При тестировании, на писи надо пользоваться не Виндовым гипертерминалом, а вот этой утилитой - http://denn.ru/orion/oriserv/com-test.exe
Эта утилита использует ту же самую компоненту для работы с СОМ-портом, что и в сервере. Если с утилитой не заработает, а с виндовой терминалкой будет ок, значит моё предположение насчёт кривой работы компоненты в новых ОС подтвердится.

Небольшие уточнения. Передачу одиночных символов в обе стороны делать в режиме "CHAR", а строки в два и более символов - в "DUMP". В последнем режиме "проглатываний" первого символа строки на Орионе быть не должно! Символы должны строго соответствовать передаваемым (в т.ч. регистр).
Искажения кодов происходят из-за неточности тактирования ВВ51. Если не удаётся добиться 100%-но стабильной передачи, то нужно снижать скорость протокола. Скорость 38400 Бод - это дичайший оверклок, у меня оно работает вопреки всем даташитам! Возможно, просто удачные экземпляры микросхем (распоследний новодел). Уменьшение частоты генератора в 2 раза даст тайминги для скорости 19200 Бод, при этом ВВ51 будет тактироваться допустимой частотой (1,8432 МГц).

[OldSpeccer]

P.S. Denn, а в каком режиме вы заводите ВВ51-ю? Что мне сразу не показалось подозрительным, откуда вв51-я 38400 бод в асинхронном режиме? 9600 номинально, ну, может 14400. А вот в синхронном режиме она до 56 кбит тянет номинально - стОит попробовать. Получается, что вы ее запускаете и запускали (даже когда на 9600) все время в синхронном режиме - именно в этом режиме она начинает передачу по активному нулю на входе /CTS - в асинхронном же ей на /CTS наплевать. Если так, то во-первых, поможет только полный нуль-модемный кабель и аппаратный flow control, во вторых можно в полтора раза поднять скорость.

[Denn]

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

Странно. Насколько помню, перед отправкой байта с Ориона я проверяю готовность порта (обратку "CTS"). При замыкании порта на себя (лупбэк), очевидно что готовность к приёму (сигнал "RTS") должна быть по-умолчанию (в ВВ51 она должна выставляться по сигналу аппаратного сброса или при программной инициализации УСАПП). С двумя перемычками (2+3 и 7+8) тест на Орионе в режиме "CHAR" должен печатать задвоенные символы. Обязан! Если этого не происходит, значит аппаратно порт Ориона неисправен.

[Stampmaker]

ставим НС138 в качестве ИД7. Потребление КМОП в статике - микроампер

согласен, это вариант

[Stampmaker]

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

[OldSpeccer]

Да, спасибо, так и есть. Идеи заканчиваются... Подскажите, как по-быстрому проверить работу управляющего слова ВВ51? У меня вызывает сомнения /RTS, по программе он должен устанавливаться в "0", а у меня - не дергается даже. Сейчас оторву его от всего и буду отдельно изучать.

[Denn]

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

Поскольку этот узел не вызывал проблем, то так глубоко я не вникал. Код инициализации в своё время взят из чужого кода, я только разобрался как менять настройки паритета (исключительно для теста портов), остальные настройки я не трогаю. В даташите на 8251 из любопытства поинтересовался почему именно такие цифры для инициализации, понял и благополучно "забыл". Опыты с разными вариантами инициализации не проводил.
Единственный момент (он виден в моём исходнике), который пришлось подобрать эмпирически - это запись кодов инициализации с задержкой, т.к. "прямолинейная" запись иногда приводила к неправильной инициализации (ВВ51-я почему-то "тормозит", видимо не рассчитана на работу ЦПУ с тактовой больше 2,0 МГц, а в Орионе аж целых 2,5 МГц). Введение "левых" CALL/RET внесло достаточные задержки, и ВВ51-я стала корректно инициализироваться в 100% случаев.

[OldSpeccer]

Господа, все заработало.
Самое забавное, что я не знаю, что я сделал. Я просто пошел скопом по сигналу RTS, который, как и положено - выдавался. Зашел в преобразователь.
Отдельно проверил его. Воткнул в DB-9 перемычку, проверил приемник, и проследил сигнал вплоть до ВВ51(!!!). Сигнал приходит!
Запускаю на орионе обращение к G: - вижу красивый запрос на TxD(!!!!). Его раньше там не было!!!
Может это сила намерения Denn - иных объяснений я не вижу! Серьезно, ерунда полная. В ходе отслеживания был один нюанс - я оторвал проводок на линии TxD, так как мне показалось он некачественно припаян - перезачистил МГТФ и перепаял. Но цепь /CTS не трогал! Чертовщина. Под лупой смотрел многократно, если что...
Огромное спасибо, коллега, за бесценное время и бескорыстное намерение! Уже успел вспомнить, насколько убогие на Орионе игры )))

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

Поскольку этот узел не вызывал проблем, то так глубоко я не вникал. Код инициализации в своё время взят из чужого кода, я только разобрался как менять настройки паритета (исключительно для теста портов), остальные настройки я не трогаю. В даташите на 8251 из любопытства поинтересовался почему именно такие цифры для инициализации, понял и благополучно "забыл". Опыты с разными вариантами инициализации не проводил.

Ну, адрес-то мы знаем, а управляющее слово по даташиту стряпается за 5 секунд. Мне бы напомнить, как красиво и изящно записать по адресу УС ВВ51-й желаемый байт, не вдаваясь в ассемблерное программирование...

Единственный момент (он виден в моём исходнике), который пришлось подобрать эмпирически - это запись кодов инициализации с задержкой, т.к. "прямолинейная" запись иногда приводила к неправильной инициализации (ВВ51-я почему-то "тормозит", видимо не рассчитана на работу ЦПУ с тактовой больше 2,0 МГц, а в Орионе аж целых 2,5 МГц). Введение "левых" CALL/RET внесло достаточные задержки, и ВВ51-я стала корректно инициализироваться в 100% случаев.

Да, я немного тоже поразмышлял над незамысловатой подпрограммой Кстати, возможно ли подправить бинарник так, чтобы исключить эти задержки - руки чешутся проверить свою NEC. Но первым делом надо 115 проверить!

[OldSpeccer]

Небольшой отчет. Сегодня разработал и изготовил печатку для COM-порта, по честному - двухстороннюю. Все заработало с полпинка. Каюсь, что морочил людям голову, МГТФ - зло Если кому вдруг надо (что конечно очень вряд ли, но все же ) - есть разводка в 6-м лэйауте.
Орион-COM1.rar
Заточено специально под ЛУТ - широкие площадки, минимум переходных отверстий, в основном переходы выролнены на выводах мс. Разведено под кварц+дискретный ген на НС00, перераскинуть под интегральный ген можно в секунду.

И да, uPD71051 замечательно работает на 115200. Разница конечно приятна, но функционально ВВ51 весьма имеет право на жизнь. При орионовских объемах данных эта разница несущественна, гораздо важнее сам функционал.
Ну и кроме того, орион-сервер подтвержденно работает на х64 платформе.
Denn, выражаю еще раз благодарность - как за помощь, так и вообще - за продукт! Повтор введенного буфера по "стрелка вверх" - это кайф! Ctrl+Enter в коммандере!! Бомба! Подозреваю, что о массе ништяков я до сих пор и не знаю
Вот такое вышло. Вилка на плате под писишный кабель с DB-9.