А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.Сообщение от Patron
А в других случаях? Уж кабель должен быть сделан так, чтобы поддерживалось квитирование в обе стороны, да и возможно чтобы было работать в полном дуплексе.
А если в файле UKNC_HX_COM.cfg включить запись на диск лога HX:
то что в процессе загрузки запишется в файл HX_Log.log ?Код:[HX_Log.ini] TabTitle ="" InitialStateOf[StatusBar] = 0 SaveChangesFor[StatusBar] = 0 InitialStateOf[ControlBar] = 0 SaveChangesFor[ControlBar] = 0 InitialStateOf[Log] = 1 SaveChangesFor[Log]=0 DumpMode=1
---------- Post added at 23:59 ---------- Previous post was at 23:54 ----------
У palsw с новым загрузчиком первый блок грузиться с HX2 и только остальные с HX0 - это у всех так ?
Ну в первоначальном варианте УКНЦ по техописанию были все сигналы, т.е. и RTS, и CTS, и DTR, и DSR. Но реально 1801ВП1-065 поддерживает только два сигнала. Да и сигналы DTR и DSR не имеют к обмену никакого отношения. Эти сигналы о том, что аппаратура включена, или на компьютере программа будет использовать COM-порт. Т.е. включили модем и если DSR оказался активен, то можем судить, что на модем подали питание. А вот сигналы RTS и CTS служат как раз для управления обменом и каждая из сторон предупреждает другую, может ли она в данный момент принять данные. Так что сначала хотели сделать на УКНЦ и что в итоге получили - большая разница. Да и сигнал 109, который закрывает вход, имеет обозначение DCD, его ставит модем, когда установил связь с другим модемом, а если связь не установлена, то УКНЦ вообще ничего не сможет получить.
---------- Post added at 01:02 ---------- Previous post was at 01:01 ----------
У меня нормально, все с нулевого драйва.
Похоже, я понял, что может вызывать проблему.
В приложении - новый вариант сервера ( HX_Server 2.1_-_UKNC_12.01.13_04-11 ) с драйвером HX.SYS и загрузчиком Boot_RT-11_from_HX0.bin, которые более корректно осуществляют повторные попытки загрузки при неудаче первой ( ошибка чтения вторичного загрузчика пока может быть обнаружена только при отключенном сжатии ).
Также изменены ячейки для впечатывания даты в передаваемый загрузчик.
...
Последний раз редактировалось Patron; 12.01.2013 в 17:15.
Ну этот вариант для тех, кто дружен с электроникой и паяльником. А если кто-то не хочет лезть в плату?Могу предложить ещё один вариант решения проблемы с сигналом 109
Идея следующая, сделать так что бы 109 не влиял на прием данных не зависимо от того к чему он подключен. Для этого нужно найти выв. 12 микросхемы ЛН3 который звонится на выв. 28 ВП1-065 и отсоединить его от платы
Нелогично называть универсальным решение, которое работает только тогда, когда программа ставит fDtrControl = DTR_CONTROL_ENABLE.
Ведь в любом случае нужно что-то паять. Уж если паять - то так, чтобы работа не зависела от наличия нужного уровня на выводе DTR.
То же относится и к закорачиванию DTR и DSR на стороне PC. Это решение никак нельзя назвать универсальным - всегда есть такой набор настроек порта, при установке которых работа через подобный "универсальный" кабель станет невозможна.
Patron, еще в последних версиях HX-сервера заметил такую особенность - если при старте, когда еще не было загрузки с HX, можно было нажимать и отжимать кнопку "Boot HX0", а после загрузки, если ее нажать, то она сразу отжимается и в последовательный порт начинает поступать первичный загрузчик.
Еще есть предложение - может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.
Значит, там фаза не сбрасывается в начальное состояние и после первого срабатывания - UKNCcomSender продолжает "думать", что только что получил с УКНЦ байт промпта. Сейчас исправлю.
Я затеял экстремальную компактизацию загрузчика, чтобы освободить достаточно места для подсчёта контрольной суммы передаваемых пакетов ( сейчас контрольная сумма загрузчиком не проверяется ), поэтому в последней версии загрузчика дата впечатывается прямо в код:может передаваемую дату и номер загружаемого устройства располагать в последних словах, там в конце как раз четыре свободных слова. А потом с этих слов копировать в ячейки вторичного загрузчика.
Код:BOOT: Mov #5000, R2 ; R2 -> Time & Date block in BSTRAP Mov (PC)+, (R2)+ ; Set TicksHi TicksHi: .Word 0 Mov (PC)+, (R2)+ ; Set TicksLo TicksLo: .Word 0 Mov (PC)+, (R2)+ ; Set Date Date: .Word 0 ; ReBOOT: Mov #10000, SP ; Boottime SP value Clr @(PC)+ ; Warm Boot ( set Date & Time ) BDEVU: .Word 0 ; Boot from Unit 0 ( ONLY !!! )
В этом случае адреса ячеек могут быть разными после очередной оптимизации, а так они будут всегда одинаковыми, ну и в этом случае оптимизироваться можно до бесконечности.
Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.
Если вторичному загрузчику не принципиально, чтобы в 4-х последних словах были -1, тогда можно. Когда я модифицировал первичный загрузчик MX, создалось впечатление, что вторичный загрузчик при работе что-то в последние 4 слова первичного пишет, но насколько важно их начальное значение - непонятно.
Если выбирать номер загружаемого устройства в cfg-файле (путём текстового редактирования), то чтобы подставить нужный образ в HX0 - требуется столько же кликов, как и чтобы задать номер загружаемого привода в каком-то другом месте.Неплохо бы в очередной версии HX-сервере сделать выбор загружаемого устройства.
Любой другой способ - еще накладнее, поэтому логично оставить как есть и выбирать загружаемый образ путём редактирования раздела [HX.ini].
---------- Post added at 13:40 ---------- Previous post was at 13:37 ----------
Чтобы загрузиться с другого привода уже после загрузки с HX0 - достаточно в RT-11 подать команду BOOT HXn:
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием