V-Comp

Многие из SIO-контроллеров, которые реализуют функции COM-портов, т.е. содержат в своем составе один или несколько UART-контроллеров, спроектированы с ошибками. В результате этих ошибок, с некоторой небольшой вероятностью могут возникать ситуации, когда такой чип «забывает» уведомить драйвер COM-порта о каком-либо событии. В результате компьютер может «не замечать» того, что ему пытается «сказать» подключенное периферийное устройство: модем, принтер и т.п. Это вызывает в процессе обмена разного рода коллизии и сбои. В отличие от всех других драйверов, SerialXP имеет специальный механизм «резервного» опроса чипов с такими ошибками, и этим минимизирует негативные последствия.

Происхождение и способ устранения сбоев

Практически все производимые сейчас UART-контроллеры совместимые с программной моделью 16550A и старше имеют ошибки, недочеты или изъяны аппаратного дизайна, в результате которых приоритет внутренних для UART прерываний (событий) не соответствует исходной спе­ци­фи­ка­ции, но кроме этого существует вероятность подавления одних событий другими, с более высоким приоритетом. Самая тяжелая ситуация с событиями (прерываниями) по изменению статуса модема, они имеют самый низкий приоритет и поэтому с большей вероятностью по­дав­ля­ют­ся событиями по приему-передаче байтов. Ошибка про­ек­ти­ро­ва­ния появилась достаточно давно в каком-то из VHDL-шаблонов, который теперь уже широко распространился в виде различных модификаций, в том числе во всевозможных наборах логики с интегрированными UART-контроллерами. При испытаниях драйвера не было ни одного COM-порта, на котором эта проблема не про­яв­ля­лась бы вообще. Хотя вероятность ее появления существенно варь­и­ру­ет­ся от 1/50 и примерно до 1/100000, но сам факт су­щест­во­ва­ния проблемы всегда подтверждался. Аппаратная ошибка имеет четкий наследственный характер, и, следовательно, вероятность проявления зависит от конечной топологии чипа, техпроцесса изготовления, питающих напряжений и температуры.

Наиболее существенные проблемы возникают при частом изменении квитирующих сигналов, ответственных за управление потоком (flow control: CTS, DSR). При тестировании драйвера часто возникала странная проблема — передача файла по нуль-модемному кабелю средствами HyperTerminal могла неожиданно «зависнуть», но возобновлялась, если соединяющий кабель отключить и подключить заново. Эта же ситуация «зависания» соединения может возникать и при «модемном» соединении с аппаратным управлением потоком (hardware flow control). По­на­до­бил­ся не один десяток часов, чтобы выяснит, что проблему порождает не драйвер, а именно SIO-чип.

В результате поисков в SerialXp появился механизм «сторожевой собаки» (WatchDog), который на всякий случай периодически про­ве­ря­ет, не «потерялось» ли на UART-контроллере какое-либо прерывание. В текущей версии SerialXP период опроса равен системному «тику» времени, что на большинстве компьютеров составляет 9-15 мил­ли­се­кунд. Как оказалось этого не всегда достаточно, поэтому в бу­ду­щих версиях будет более гибкая настройка, в случае необходимости до­пус­ка­ю­щая принудительное учащение системных тиков (см. Ex­Set­Timer­Re­so­lution() в Windows DDK).

Реклама на V-Comp:

04.06.2025