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" должен печатать задвоенные символы. Обязан! Если этого не происходит, значит аппаратно порт Ориона неисправен.

[OldSpeccer]

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

Именно так. А со стороны компа - материнская плата с честным УАРТом.

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

Именно этот вариант у меня и собран. Только не интегральный ген, а параллельный осциллятор на НС00, но это не принципиально. Все клоки в порядке.

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

Однако же без ухищрений не работают. Честного нуль-модемного линкера нет, и его применение хочется оттянуть по возможности - нет под рукой кабеля хорошего, многожильного... А с перемычками не работает железобетонно! Разумеется, тестирование провожу именно вашей утилитой. Повторю, в режиме DUMP нажате любой клавиши на орионе мгновенно выводит "ошибку" - это даже тогда, когда /CTS притянут к земле, и в режиме CHAR одиночные символы уходят без проблем.

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

Я не верю в сбои ВВ51, потому что NEC uPD71051 ведет себя так же, при том что она нормирована на 230 кбод. Спрошу наверное еще раз про режим...вы ведь в синхронном заводите ВВ51?

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

С двумя перемычками (2+3 и 7+8) тест на Орионе в режиме "CHAR" должен печатать задвоенные символы. Обязан! Если этого не происходит, значит аппаратно порт Ориона неисправен.

Но все же нет. Замыкаю попарно TxD и RxD, /RTS и /CTS прямо на выводах порта, чтобы исключить теоретическую неисправность MAX232-й. Символы НЕ ДВОЯТСЯ. Отрываю /CTS, вешаю на землю - символы двоятся. Естественно, что с MAX232 поведение то же самое. Аналогичное поведение демонстрируют примерно 4-5 микросхем из одной партии, все новые, плюс японский аналог.

[Denn]

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

В том-то и дело, что в асинхроне 38400! Как выяснилось, проблема с разгоном асинхрона вот в чём. Для корректной расшифровки протокола в асинхроне, необходимо тактировать УСАПП частотой как минимум в 5 раз превышающей клок самого протокола. А серия 580 имеет верхний предел в 2 МГц. Чтобы выполнилось условие, для скорости 38400 Бод нужен клок не менее 3,6 МГц. С такой частотой ВВ51 не должна работать... тем не менее, у меня она прекрасно работает и даже почти не греется.
С клоком 2 МГц (схема из ж. "РАДИО") максимальный предел устойчивой передачи был 14400 Бод. На передачу можно было и больше, а вот на приём условие 5-кратного превышения обязательное.

[OldSpeccer]

В том-то и дело, что в асинхроне 38400! Как выяснилось, проблема с разгоном асинхрона вот в чём. Для корректной расшифровки протокола в асинхроне, необходимо тактировать УСАПП частотой как минимум в 5 раз превышающей клок самого протокола. А серия 580 имеет верхний предел в 2 МГц. Чтобы выполнилось условие, для скорости 38400 Бод нужен клок не менее 3,6 МГц. С такой частотой ВВ51 не должна работать... тем не менее, у меня она прекрасно работает и даже почти не греется.
С клоком 2 МГц (схема из ж. "РАДИО") максимальный предел устойчивой передачи был 14400 Бод. На передачу можно было и больше, а вот на приём условие 5-кратного превышения обязательное.

В асинхронном режиме микросхеме должно быть наплевать на состояние /CTS. А как оно явственно следует из опытов - от состояния /CTS ее поведение зависит напрямую. Что касается верхнего предела 2 МГц - это конечно же ерунда, заниженная планка ГОСТа.
ЗЫ: иду-ка я наверное паять нуль-модем...

[Denn]

Но все же нет. Замыкаю попарно TxD и RxD, /RTS и /CTS прямо на выводах порта, чтобы исключить теоретическую неисправность MAX232-й. Символы НЕ ДВОЯТСЯ. Отрываю /CTS, вешаю на землю - символы двоятся. Естественно, что с MAX232 поведение то же самое. Аналогичное поведение демонстрируют примерно 4-5 микросхем из одной партии, все новые, плюс японский аналог.

Либо "не той системы" форма клока у вашего генератора, либо ваши экземпляры микросхем не тянут оверклок. Может проблемы реализации (отсутствие блокировочных ёмкостей, наводки из-за неудачной топологии или что-то в этом роде). Другого просто предположить не могу.
Самое простое: для начала попробовать уменьшить частоту клока в 2 или в 4 раза (получится скорость 19200 или 9600 Бод, соответственно). Если так заработает, то тогда будет понятно куда двигаться дальше.

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

В асинхронном режиме микросхеме должно быть наплевать на состояние /CTS.

На основании чего такой вывод? Проверка состояния "CTS" программируется при инициализации, от режима она не зависит. Режим ВВ51 у меня программируется - асинхронный.

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

Символы НЕ ДВОЯТСЯ. Отрываю /CTS, вешаю на землю - символы двоятся. Естественно, что с MAX232 поведение то же самое. Аналогичное поведение демонстрируют примерно 4-5 микросхем из одной партии, все новые, плюс японский аналог.

Со своей стороны могу сказать, что у меня собрана эта схемотехнимка в трёх вариантах: на "О-128", на "О-512" и на "ПРО". На первых двух работает вариант с перемычками-затычками 7+8 (14400 и 38400, соответственно), на "ПРО" сделан полноценный линкер (режим "Flow Control = Hardware"). Причём на "ПРО" вместо ВВ51 поставил быстрый КМОП 82С51А-2 с клоком 10 МГц, работаю на скорости 115200 Бод (аналогичный вариант успешно работает у Дмитрия2012). У Stampmaker'а в обоих "О-128" порты на ВВ51 заработали сразу (14400/19200 Бод). Проблем с CTS/RTS не было, слышу про неё впервые.

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

ЗЫ: иду-ка я наверное паять нуль-модем...

Есть у меня одна догадка... Если к ВВ51 не идёт аппаратный сброс на вход 21, то возможно и будут приколы с установкой сигнала на выходе "RTS". А не идти он может по причине того, что изначально его на "В20" системного разъёма нет (его надо пробрасывать проводком).
И как раз в этом случае не будет работать перемычка 7+8, т.к. "RTS" используется свой, а не от сервера. Тогда при спайке честного линкера Орион таки получит правильный сигнал CTS, но сервер таковой от Ориона не увидит - придётся выставлять "None", в таком варианте даже будет работать

[OldSpeccer]

Либо "не той системы" форма клока у вашего генератора, либо ваши экземпляры микросхем не тянут оверклок. Может проблемы реализации (отсутствие блокировочных ёмкостей, наводки из-за неудачной топологии или что-то в этом роде). Другого просто предположить не могу.

Да не, с клоками все хорошо. И работают микросхемы четко, есть 2-х лучевой 100-мгцный скоп - все, как на ладони. Грабли точно не с клоком. Уж поверьте мне, я на цифре не одну собаку съел и ужасы видал Все кошерно, не морочьте голову себе клоком. Криворукости с моей стороны конечно возможны, со скидкой на лет 30 стажа

Самое простое: для начала попробовать уменьшить частоту клока в 2 или в 4 раза (получится скорость 19200 или 9600 Бод, соответственно). Если так заработает, то тогда будет понятно куда двигаться дальше.

Напомню, что аналогичное поведение наблюдается и в штатном режиме 9600 бод, с ВИ53-й. На лету перепроверить не могу, так как ИЕ5-я распаяна под 7МГц, но и там работало только с /CTS притянутым к земле, и точно так иногда терялся первый байт посылки. Но ради чистоты эксперимента я все же попробую откатиться, вторым делом. А первым - распаяю RTS-CTS линк. Чтоб уяснить для себя.

На основании чего такой вывод? Проверка состояния "CTS" программируется при инициализации, от режима она не зависит. Режим ВВ51 у меня программируется - асинхронный.

На основании изучения даташита Интел 8251А, страницы 2-9, 2-10 - описание работы в асинхронном и синхронном режимах соответственно.
В асинхронном режиме микросхема сразу же отправляет в TxD полученный ею по ШД байт, добавляя к нему служебные биты и синхронизируясь к клоку передачи. В синхронном же режиме она принимает во внутренний буфер байт данных, но выдает его только СИНХРОНИЗИРУЯСЬ сигналом /CTS. Понятное дело, что если /CTS постоянно активен, то работает все аналогично асинхронной передаче - просто синхронизируясь с клоком. Собственно именно это поведение я и наблюдаю у себя, с чего я делаю вывод, что микросхема работает в синхронном режиме.

Со своей стороны могу сказать, что у меня собрана эта схемотехнимка в трёх вариантах: на "О-128", на "О-512" и на "ПРО". На первых двух работает вариант с перемычками-затычками 7+8 (14400 и 38400, соответственно), на "ПРО" сделан полноценный линкер (режим "Flow Control = Hardware"). Причём на "ПРО" вместо ВВ51 поставил быстрый КМОП 82С51А-2 с клоком 10 МГц, работаю на скорости 115200 Бод (аналогичный вариант успешно работает у Дмитрия2012). У Stampmaker'а в обоих "О-128" порты на ВВ51 заработали сразу (14400/19200 Бод). Проблем с CTS/RTS не было.

Еще раз - замена на NEC uPD71051 со штатным 10-ти МГц не меняет картины. Проблема ТОЧНО не в частотах.
Вы знаете - меня самого удивляет, что такой вроде бы давно понятный узел, как , ставит в такие тупики.
Но ловить отладчиком обращение к ВВ51 мне хочется еще меньше, чем паять полный нуль-модемный кабель
Не слишком ли многого я попрошу, если попрошу комментированный исходник процедуры инициализации ВВ51?

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

Есть у меня одна догадка... Если к ВВ51 не идёт аппаратный сброс на вход 21, то возможно и будут приколы с установкой сигнала на выходе "RTS". А не идти он может по причине того, что изначально его на "В20" системного разъёма нет (его надо пробрасывать проводком).

К моему великому сожалению, Ваша догадка не верна. О сбросе я знаю, и конечно же его пробросил - а также наблюдаю его прохождение. Не то...
Волосы на груди кончаются

[Denn]

Напомню, что аналогичное поведение наблюдается и в штатном режиме 9600 бод, с ВИ53-й.

Тогда вариант непрохождения сигнала сброса на ВВ51, как следствие неправильная инициализация УСАПП.

Не слишком ли многого я попрошу, если попрошу комментированный исходник процедуры инициализации ВВ51?

; пОРТ COM1 (вв51а)

PT_TM0:EQU 0F730H
PT_CTM:EQU 0F733H
PT_SP0:EQU 0F740H
PT_SP1:EQU 0F741H

IniCOM:
; нАСТРОЙКА ТАЙМЕРА ви53
MVI A,36H
STA PT_CTM

LXI H,PT_TM0
MVI A,9; 14400 бОД
CALL SvPORT
XRA A
CALL SvPORT

; нАСТРОЙКА усапп вв51а
LXI H,PT_SP1
INR A; =MVI A,1
CALL SvPORT
CALL SvPORT
MVI A,40H
CALL SvPORT
MVI A,4EH; 8N1
CALL SvPORT
MVI A,27H
CALL SvPORT
DCX H; LDA PT_SP0; ОЧИСТКА ПОРТА ВВОДА
MOV A,M
RET

SvPORT:
; зАПИСЬ ДАННЫХ В МЕДЛЕННЫЙ ПОРТ вв51а
MOV M,A
RET

Собственно инициализация ВВ51 это программный сброс и последовательная запись значений:

4Eh (0100|1110b)
27h (0010|0111b)

Соответственно, настройка асинхронного протокола 8 бит, 1 стоп-бит, без проверки паритета, выдача RTS, проверка CTS.