УКНЦ загрузка через стык С2

[Alex_K]

Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант:

Разъем                             Разъем
Стык С2                            DB9S
  1,10 (102) ■─────────────────────■     5 (GND)

  5    (103) ■──────────┐     ┌────■     3 (TD)
                  ┌────■│■────┘
  6    (104) ■────┘     └──────────■     2 (RD)

  3    (+5В) ■─               ┌────■     4 (DTR)
                              │
  7    (109) ■────────────────┤   ─■     1 (CD)
                              │
                              └────■     6 (DSR)

  2    (108) ■──────────┐     ┌────■     7 (RTS)
                  ┌────■│■────┘
  9    (107) ■────┘     └──────────■     8 (CTS)

Отличается тем, что на вход 7 УКНЦ (сигнал 109) подается не +5В с УКНЦ, а сигнал DTR с PC. Сразу предупрежу, что этот кабель для УКНЦ с квантовской схемотехникой. На УКНЦ с СЭМЗ-овской схемотехникой на вход 7 надо подавать ТТЛ-уровень, так что там остается вариант только с +5В.
Для нормального функционирования данного кабеля в настройках HX-сервера обязательно должны стоять следующие параметры:

fDtrControl = DTR_CONTROL_ENABLE
fRtsControl = RTS_CONTROL_HANDSHAKE

StopBits = TWOSTOPBITS

fOutxCtsFlow = TRUE
fOutxDsrFlow = TRUE

[Advertiser]

[palsw]

hobot, RT1154Y_HX22_UKNC.rar запустил...

[hobot]

RT1154Y_HX22_UKNC.rar запустил...

там есть тест DR_Titusa ! )

[palsw]

Patron, Словил баг что ли - у меня образ всегда грузится с HX2:
На новой версии первый блок грузиться с HX2: а остальные только с HX0:.Тоесть образ должен быть загружен в HX0: и HX2: одинаковый и одновременно

[hobot]

Patron,

какой именно образ?

[palsw]

hobot, HX_Server 2.1_-_UKNC_11.01.13_16-10.rar из новой версии .Раньше я на HX0 и HX1 свои образы загружал,а в HX2 загрузочный образ был

[Patron]

Воспринимая критику кабеля со стороны Vamos, хочу предложить следующий вариант кабеля

Но если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?

Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..

[Alex_K]

Но если с этим вариантом кабеля сигнал DTR постоянно установлен через fDtrControl = DTR_CONTROL_ENABLE - то какой тогда смысл в fOutxDsrFlow = TRUE ?

Ведь, если на входе DSR всегда будет TRUE от DTR - никакого управления потоком через DSR не будет..

А нет никакого смысла. Управление через DTR/DSR не ведется. А на самом деле смысл есть только в установке fDtrControl = DTR_CONTROL_ENABLE, чтобы открывало вход для посылок извне на УКНЦ, а fOutxDsrFlow = TRUE так для проверки, что DTR установился.

[Patron]

И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..

Ведь, провод RTS реально используется только тогда, когда сервер не забирает байты у Windows более 3 секунд ( а он обычно это делает 60 раз в секунду ). Если просто подать TRUE на вывод 9(107) и не распаивать провод RTS в кабеле - ни какой разницы при реальной работе не будет.

---------- Post added at 23:19 ---------- Previous post was at 23:15 ----------

А нет никакого смысла.

Не нужно вообще с DTR заморачиваться - это совершенно бессмысленная затея. Со стороны PC ни DTR, ни DSR распаивать не надо.

[Alex_K]

И какие вообще преимущества должен ( по идее ) дать пятый провод в кабеле, когда и четырёх проводов больше чем достаточно..

А каких четырех? Давайте считать. 1 - земля, 2 - принимаемые данные, 3 - передаваемые данные, 4 - контроль по CTS. Ну и если нет контроля по RTS, то с RTS или DTR подать сигнал на вход УКНЦ 7 (сигнал 109), иначе посылки приниматься не будут, это пятый.