Да, это я проверял когда свой драйвер писал.Цитата:
Сообщение от Alex_K
Так, что остается просто кривой драйвер который всегда держит прерывания разрешенными. Ну или в FB можно в теории нарваться :)
Вид для печати
Да, это я проверял когда свой драйвер писал.Цитата:
Сообщение от Alex_K
Так, что остается просто кривой драйвер который всегда держит прерывания разрешенными. Ну или в FB можно в теории нарваться :)
В самом начале тестирования HX-сервера с УКНЦ - квитирование, помнится, не хотело работать.
А что если HX-сервер не всё сетапит в COM-порту, что надо - и поэтому нормально работает только тогда, когда между включением PC и его запуском не запускались другие программы, работающие с тем же COM-портом..
Возможно, есть смысл это проверить, запустив на этом же COM-порту сначала эмулятор TU58 или HyperTerminal и только затем - HX-сервер.
Эмулятор TU58 работает только на полноценных портах. На моем ST-Labовском USBшном двойнике к примеру работать не будет из-за кривой реализации break (подозреваю, что драйвера такие [у всех pci, usb железок]). А HX вполне пашет несмотря на то, что порт плюется громадными пакетами символов за раз :)
Квитирование не хотело работать по другой причине. Первое - передача с УКНЦ уходила всегда, потому что всегда на входе BSYD 1801ВП1-065 был активный уровень, связанный с настройками fRtsControl = RTS_CONTROL_ENABLE. После изменения на fRtsControl = RTS_CONTROL_HANDSHAKE все стало в этом плане нормально работать. В случае с приемом ситуация оказалась потяжелее. После получения очередного байта 1801ВП1-065 выставлял неактивный уровень на выходе RR. По идее Windows со своей стороны должна была это видеть и прекратить передачу со своей стороны. Решилось это следующими установками: fOutxCtsFlow = TRUE и StopBits = TWOSTOPBITS. Первая установка заставляет следить Windows за уровнем сигнала CTS, и не передавать, когда он неактивный. А вот два стоп-бита пришлось поставить потому, потому что с одним стоп-битом Windows не успевала обрабатывать CTS и умудрялась послать очередной байт, в связи с чем на УКНЦ возникала ошибка переполнения, если предыдущий байт не был считан.Цитата:
Сообщение от Patron
Но попробую запущу и TU58, и гипертерминал, но попозже.
Ну, как и предполагалось все нормально работает и после запуска TU58, и после запуска гипертерминала. Ну а собственно и не могло быть иначе, ведь HX-сервер программирует COM-порт через структуру DCB.Цитата:
Сообщение от Patron
Мне почему-то кажется, что если передающий порт использует один стоповый бит, а принимающий - два, то правильно может быть передан только первый байт в непрерывном потоке байтов.Цитата:
Сообщение от Alex_K
Кажется неправильно. С одним стоп-битом работает, если не используется сжатие. Со сжатием сразу проблемы, если передаваемый блок большой и хорошо запакован.Цитата:
Сообщение от Patron
Новый вариант сервера ( HX_Server 2.1_-_UKNC_13.01.13_18-28 ) с загрузчиком Boot_RT-11_from_HX0.bin, который (якобы):
1. При обнаружении любой ошибки протокола - входит в режим пропуска байтов, из которого выходит только тогда, когда за 12 выводов байта 015 в порт терминала - в порт HX не поступит ни одного байта от сервера.
2. При входе в первичный драйвер запоминает параметры вызова процедуры чтения и, в случае ошибки передачи - после процедур, описанных выше - повторяет ошибочно завершившийся запрос.
...
Теперь понятно, почему предыдущие попытки наладить управление потоком между PC и 1801ВП1-065 кончались печалью.Цитата:
Сообщение от Alex_K
Байты от PC проходили и с одним стоповым битом, поэтому в ходе экспериментов никто не сподобился переключить COM-порт на два стоповых бита.
Попробовал провести опыт с USB-COM-портом. Чип Prolific PL2303-HXA, сейчас он уже не поддерживается производителем, драйвера старые. Использовал HX-сервер версии "HX_Server 2.1_-_UKNC_12.01.13_16-01".
Первоначально все шло замечательно, загрузка прошла с включенным сжатием, никаких зависаний и ошибок. Тест командой DIR/BAD/FIL прошел без всяких проблем, во время чтения данных выходил в пультовый отладчик и смотрел регистр 176570, никакого переполнения.
Проблемки начались при исполнении команды COP/DEV HX0: HX7:. При нажатии кнопки "Stop reading" посылка данных останавливалась, при отжатии - возобновлялась, проблем нет. Оставил исполняться команду до конца. Во время HX-WRITE появилась ошибка контрольной суммы. На этом завершилось. Перезапустил HX-сервер и УКНЦ, прогрузка с включенным сжатием не пошла - ошибки переполнения.
Ну чтож, передернул в USB COM-порт, далее все пошло как надо, но на команде COP/DEV HX0: HX7: на HX_WRITE опять встало, никаких ошибок и никакого обмена.
---------- Post added at 20:21 ---------- Previous post was at 20:20 ----------
Завтра возьму на работе PCI-COM-порты, интересно как с ними будет?
Alex_K, Этот пролифик - коварная и гнусная вещь. Очень любит ловить ошибки: помехи по COM порту часто воспринимаются им как USB команда перейти в sleep режим, а дальше - только передергивание USB. По версии чип-вендора виноваты китайские производители с плохой разводкой платы. Я склонен думать что просто чип - г..., хотя он и самый распространенный.
Надо USB-COM либо на CP2102 (около $12 с доставкой оттуда), либо на FTDI FT232, он подороже, где-то $14 (СP2102 последний, вышел позже FT и Prolific)
Я программатор два раза в гарантию носил, пока не сказал жёсткое нет пролифику ;-)
О да!!! Сейчас я понял это. На новой версии HX-сервера снова все подвисло на ошибке контрольной суммы на HX_WRITE. И это при отключенном сжатии (хотя это играет роль только при чтении). Да и сам чип у меня, который больше не поддерживается, об этом на сайте производителя прямо и написано, мол есть более свежие версии, для них и драйвера свежие есть. Вот так-то.Цитата:
Сообщение от dk_spb
Alex_K, А более свежий пролифик - просто более свежее г...
Т.е. просто пишет про ошибку и перестаёт что-либо передавать и принимать..Цитата:
Сообщение от Alex_K
А если в файле 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 21:26 ---------- Previous post was at 21:01 ----------
А если выяснить, на каком блоке всё время присходит сбой и потом заказать COP/DEV HX0:/ST:nn HX7:/ST:nn прямо с этого блока - тогда тут же и зависнет ?
Блоки могут быть разные, так что смысла выяснять нету. Это собственно из-за USB-COM-порта Prolific.Цитата:
Сообщение от Patron
Просто интересно, почему перестаёт работать, а не ошибку записи возвращает. Ведь по-хорошему сервер должен сообщить драйверу об ошибке, а тот - выдать признак ошибки в программу.Цитата:
Сообщение от Alex_K
---------- Post added at 22:50 ---------- Previous post was at 22:48 ----------
В принципе - с таким любопытным портом можно сделать и отладить "повторные попытки записи" в драйвере.
С родным аппаратно-железным COM1 все прошло без сучка и задоринки.
А любопытным портом отлаживать не стоит, ибо неизвестно что он выкинет в следующий раз. Выход из ошибки возможен, когда известен алгоритм работы COM-порта, известно что надо в этом случае сделать. А когда COM-порт работает по принципу "хочу-не хочу", то тут отлаживаться можно до бесконечности.
Если запись иногда проходит - повторные попытки записи в драйвере вполне могут помочь. Ведь для того и передаётся контрольная сумма, чтобы выявлять ошибки. Но после сообщения об ошибке контрольной суммы обмен зависать не должен - сервер должен послать драйверу пакет с сообщением об ошибке, а драйвер, получив его - должен установить признак аппаратной ошибки в CSW и завершить вызов.Цитата:
Сообщение от Alex_K
Если так не происходит - это довольно странно, ведь читает драйвер (насколько я понял) с "плохим" портом без проблем, а значит, сообщение сервера об ошибке получить должен.
Вот после этого проблемы и начинаются и с чтением. Происходят ошибки переполнения, и это при установленных двух стоп-битах. Естественно из-за этого и со сжатием не грузится. Помогает только передергивание по USB, да и то ненадолго.Цитата:
Сообщение от Patron
Получается, что драйвер "осмысленное" сообщение сервера об ошибке не получает и крутится в цикле его ожидания.Цитата:
Сообщение от Alex_K
---------- Post added at 23:49 ---------- Previous post was at 23:46 ----------
В такой момент должна помогать отправка Ctrl/C через окно Teletype.
весьма возможно, но мне проверять это уже не хочется, USB-COM-порт отсоединил, завтра (хотя уже сегодня) притащу с работы другие, попробую.Цитата:
Сообщение от Patron
У тебя этот порт тоже рывками работает из под RT-11?Цитата:
Сообщение от Alex_K
Мой например по команде DIR мгновенно нафигачивает по пол экрана информации. В RSX все плавно, но это видимо следствие полнофункционального драйвера который дозирует выдачу.
А именно тесты из этого сообщения
"http://zx.pk.ru/showpost.php?p=567532&postcount=249
описание тестов PORT - для ДВК и PORT2 для УК-НЦ )"
Код:Image : 54y_HX22_TESTUK.dsk
Format : DSK
Size : 800 Kb
Volume ID: RT11A
Owner :
File Blocks Date Bytes
---------- ------ ----------- ----------
SWAP .SYS 27P 19-Dec-1988 13'824
RT11SJ.SYS 78P 16-Dec-2012 39'936
TT .SYS 2P 23-Jan-1980 1'024
STARTS.COM 1 11-Jan-2013 512
RESORC.SAV 25 01-Mar-2012 12'800
IND .SAV 58 18-Jan-1988 29'696
DUP .SAV 45 27-Dec-1983 23'040
LD .SYS 8P 18-Jan-1988 4'096
DAY .SAV 4 19-Dec-2012 2'048
SPAM .MAC 4 09-Jan-2013 2'048
WD .SYS 3P 05-Aug-1979 1'536
WE .SYS 2P 16-May-1979 1'024
COLS .SAV 17 09-Aug-1990 8'704
WDR .SAV 3 01-Oct-1980 1'536
RUS .SAV 2 16-Oct-1994 1'024
SYS .SAV 3 30-May-1979 1'536
LAT .SAV 2 16-Oct-1994 1'024
TTY .SAV 3 25-Jan-1991 1'536
NYS .SAV 22 22-Oct-1993 11'264
PMEM .SAV 2 25-Aug-1993 1'024
TUK .SAV 35 27-Mar-1980 17'920
TS .SAV 40 31-Jul-1992 20'480
SKY .SAV 4 08-Apr-1993 2'048
MZFORM.SAV 6 13-Jun-1990 3'072
CAT .SAV 52 01-Sep-1992 26'624
HUST .SAV 6 31-Dec-1999 3'072
FONTUK.SAV 5 31-Dec-1999 2'560
AC .SYS 5P 12-Sep-1994 2'560
MZ .SYS 4P 12-Jan-1990 2'048
PIP .SAV 30 31-Oct-1998 15'360
DESS19.SAV 19 04-Mar-1994 9'728
MACRO .SAV 63 21-Dec-2012 32'256
LINK .SAV 59 31-Oct-1998 30'208
SYSMAC.SML 92 31-Oct-1998 47'104
DIR .SAV 20 31-Oct-1998 10'240
DISASM.SAV 8 07-Dec-2011 4'096
SL .SYS 10 19-Jan-1988 5'120
UCL .SAV 2 31-Dec-1999 1'024
KLAV .SAV 18 10-Feb-1989 9'216
RMKOI8.SAV 6 31-Dec-1999 3'072
RDWR .SAV 3 20-Dec-1991 1'536
TSSPD .SAV 23 25-Apr-1980 11'776
SYSLIB.OBJ 47 19-Dec-1988 24'064
SPAM .SAV 2 31-Dec-1999 1'024
TSSPD .MAC 93 11-Jan-2013 47'616
BINCOM.SAV 25 31-Oct-1998 12'800
BOT .COM 1 11-Jan-2013 512
BOTHX0.MAC 10 11-Jan-2013 5'120
C2 .COM 1 09-Jan-2013 512
C2 .MAC 5 11-Jan-2013 2'560
HX .COM 1 17-Nov-2012 512
HX .MAC 28 11-Jan-2013 14'336
C2 .LST 13 31-Dec-1999 6'656
HX .LST 73 31-Dec-1999 37'376
HX .SYG 4 31-Dec-1999 2'048
BOTHX0.LST 27 31-Dec-1999 13'824
BOTHX0.BIN 1 31-Dec-1999 512
C2 .SYS 2 31-Dec-1999 1'024
HX .SYS 4 31-Dec-1999 2'048
PALSW .SAV 23 11'776
PORT .MAC 12 14-Jan-2013 6'144
PORT .SAV 16 14-Jan-2013 8'192
PORT2 .SAV 16 14-Jan-2013 8'192
< UNUSED > 361 184'832
---------- ------ ----------- ----------
63 Files, 1225 Blocks
361 Free blocks
"http://zx.pk.ru/showpost.php?p=567532&postcount=249
описание тестов PORT - для ДВК и PORT2 для УК-НЦ )"
Испытал PCI-Serial плату OX16PCI952 производства Oxford Semiconductors Ltd. Могу сказать, что результаты положительные. Загрузка происходила с включенным сжатием. Команды DIR/BAD/FIL и COP/DEV HX1: HX7: выполнены успешно. Во время чтения выходил в пультовый режим и смотрел регистр 176570, все отлично - бита переполнения не установлено.
А если PORT.SAV и PORT2.SAV запустить - какие результаты выводит ?
Так собственно уже давно ответил.Цитата:
Сообщение от Patron
---------- Post added at 21:38 ---------- Previous post was at 20:10 ----------
Испытал VSCom uPCI-200L. Вообще не пошло. На некоторых настройках PC вместо одного байта "@" получает почему-то два - "@" как надо и байт с кодом ноль. Когда получение "@" проходит нормально, то передается несколько байт первичного загрузчика и на этом все замирает.
Именно так было и в начале тестирования:Цитата:
Сообщение от Alex_K
http://emulator.pdp-11.org.ru/misc/tst1.png
Нет, у меня сначала "@", а потом <000>. Но не всегда, только с некоторыми настройками порта.Цитата:
Сообщение от Patron
А потом прочитывалось несколько байт первичного загрузчика и замирало.
В приложении - тестовая версия Boot_RT-11_from_HX0.bin, выводящая эхо на экран при приёме каждого байта из порта С2. Если вывод на экран УКНЦ не упирается в конце строки - можно оценить число принятых байтов.
...
У меня первичный загрузчик прочитаться не мог, так что тут даже до Boot_RT-11_from_HX0.bin не доходит. А последний раз прочлось 27 байт, т.к. значение R1 = 033. Т.е. УКНЦ шлет "@", затем HX-засылает 512 байт первичного загрузчика, но даже и он не проходит.Цитата:
Сообщение от Patron
В приложении - тестовая версия Boot_RT-11_from_HX0 v1.2 (test), выводящая каждый принятый из порта С2 байт обратно в порт С2 ( для просмотра в окне Port Dump ).
...
Это и при одном, и при двух стоповых битах так ?Цитата:
Сообщение от Alex_K
При двух.Цитата:
Сообщение от Patron
---------- Post added at 23:11 ---------- Previous post was at 22:53 ----------
Ну вот, закончил тестирование SUNIX SER4037A. Все тесты прошла нормально, но только при отключенном сжатии. Соответственно плохо реагирует на изменение CTS, есть ошибки переполнения при включенном сжатии.
В описании плат МС1201.01 и МС1201.02 говорится про блок переключателей SA2 с 8-ю переключателями:Цитата:
Сообщение от Alex_K
SA2.1 - 177560/60 или 176560/360
SA2.2 - 7 или 8 бит
SA2.3 - с паритетом или без паритета
SA2.4 - чёт или нечет
SA2.5 - выбор скорости
SA2.6 - выбор скорости
SA2.7 - выбор скорости
SA2.8 - выбор скорости
Т.е. (если я правильно понимаю) количество битов на байт у 1801ВП1-035 может составлять от 10 до 12.
В случае с МС1201.01 и МС1201.02 кол-во бит может составлять от 10 до 12 (зависит от длины посылки - 7 или 8 бит и наличия бита паритета). Но стандартно по умолчанию настроено на 8 бит без бита паритета, получается 11.Цитата:
Сообщение от Patron
Только сейчас я понял, что контроллеры, использующие разное количество стоповых битов, могут успешно обмениваться синхронными данными из-за того, что стоповый бит это всегда "0", а стартовый - всегда "1". Поэтому, при приёме данных контроллеры не считают стоповые биты, а просто ожидают фронта стартового.
В такой ситуации, когда единственное, чем грозит передача неправильного количества стоповых битов - это отправка лишнего байта при работе с квитированием ( что часто сходит с рук при наличии в принимающем порту буфера FIFO ) - только самые вдумчивые и ответственные китайцы станут делать работу порта при отправке двух стоповых битов чем-то отличающейся от работы с одним.
Можно предположить, что именно способность честно отправлять 2 стоповых бита критически важна для успешного взаимодействия контроллера COM-порта PC с 1801ВМ1-065.
Относительно протестированного SUNIX SER4037A можно предположить, что он просто игнорирует настройку на 2 стоповых бита, продолжая отправлять один.
Что же до VSCom uPCI-200L, то думается, что при настройке на один стоповый бит - он смог бы передать первичный загрузчик целиком - видимо, режим с 2 стоповыми битами его разработчиками не тестировался, но уж режим-то с одним стоповым битом должен работать как часы - иначе как вообще этот контроллер можно было бы применять..
Ну насчет "0" и "1" - это смотря с какой стороны посмотреть, вообще стартовый бит по диаграммам всегда низкого уровня, а стоповый - высокого. А стоповые биты (как и стартовый) нужны при асинхронном обмене - во время стопового бита контроллер готовится к приему следующего (сбрасывает счетчики, копирует сдвиговый регистр в буферный), передающая сторона при необходимости опрашивает линии управления.Цитата:
Сообщение от Patron
Ну при включенном буфере FIFO на аппаратном COM-порте тоже все нормально проходит, значит Windows умеет тормозить отправку буфера. А у всяких PCI- и USB-COM-портов качество работы зависит от внутреннего firmware контроллера и от драйвера в Windows, т.к. там обычно работа делается на программном уровне.Цитата:
Сообщение от Patron
А вот протестированный мной PCI Serial с чипом производства Oxford Semiconductors Ltd. успешно работает и с одним стоп-битом. Складывается впечатление, что он работает с квитированием на аппаратном уровне.Цитата:
Сообщение от Patron
Вот уж и не хочется тестировать, да и отнес я их обратно. Я уже писал выше, что если криво сделано firmware контроллера и драйвера, то так и работать будут.Цитата:
Сообщение от Patron
Кстати вчера испытал новый Prolific со свежими драйверами. Загрузится не удалось, на УКНЦ писалось, что идут плохие пакеты. А ведь старый хоть чуть-чуть, но работал. Так что dk_spb в этом плане оказался прав - новый Prolific - новое г.....
Patron, А можно Вас попросить добавить в HX_Server выбор СОМ порта.
Используемый COM-порт нужно указать в файле UKNC_HX_COM.cfg в разделе ComPort.ini в параметре PortName.Цитата:
Сообщение от Vamos
По умолчанию используется порт COM1:
Код:[ComPort.ini]
PortName = "COM1"
InitialStateOf[ShowPortUse]=1
SaveChangesFor[ShowPortUse]=1
Новый вариант сервера HX_Server 2.1_-_UKNC_19.01.13_20-05.
Изменения:
1. Добавлен загрузочный образ NCsys54.DSK с монитором NC11SJ.SYS, сгенерённым для работы с портом С2 в качестве системного терминала. Драйвер HX.SYS, находящийся в этом образе - при загрузке выводит сообщения в порт С2.
2. Добавлен загрузчик Boot_NC-11_from_HX0.bin, который при загрузке выводит сообщения в порт С2.
3. Добавлен файл конфигурации NC11_HX_COM.cfg - для загрузки образа NCsys54.DSK на УКНЦ. Для загрузки файла конфигурации нужно использовать пункт меню: Файл -> Открыть.
4. Добавлен файл Terminal.ini, содержащий настройки терминала типа VT52, используемого в качестве системного терминала при работе с монитором NC11SJ.SYS через порт С2.
...