Стандарт FIRDA. Каждый фронт в сигнале RS232 кодируется коротким однополярным импульсом, который передается по оптическому каналу. Hа приемнике эти импульсы поступают на вход триггера, работающего в счетном режиме. Hа выходе триггера получаем (в идеале) сигнал RS232. В принципе, это все. У это чудесного по своей простоте алгоритма есть только один существенный недостаток, который заключается в том, что при пропуске хотя бы одного импульса, на выходе триггера начинает появляться инверсия сигнала RS232. Конечно, можно сказать, что при потере стартового фронта в RS232 (или первого импульса в пачке IRDA) тоже произойдет сбой синхронизации, который при плотном потоке информации может быть ликвидирован не скоро. Однако, в предлагаемой системе потеря любого (а не только первого) импульса приводит к неприятностям. Грубо говоря, помехоустойчивость FIRDA раз в 8-10 хуже IRDA или RS232. В принципе, это было бы не так страшно (считаем, что ошибки появляются достаточно редко), если бы с течением времени FIRDA выходил на нормальный режим работы, как это происходит с его именитыми прототипами. Однако, если не предусмотреть специальных мер, FIRDA так и будет гнать инвертированный поток, пока не произойдет еще одного сбоя ;)) Именно длительная инверсная работа мне казалась главным недостатком FIRDA и я дополнил его маленькой добавкой, которая в последствии меня самого удивила своей эффективностью и практически решила все проблемы. Добавка очень простая: если в течении некоторого времени (ну например 0.1 сек) на выходе триггера присутствует "1", то следует принудительно перевести его в нулевое состояние (считаем, что в паузах передачи на выходе RS232 - ноль). Теперь для полного счастья надо дергать готовность ком-порта передатчика один раз в 10 сек, прерывая передачу на 0.1 сек, с тем чтобы триггер приемника установился в исходное состояние. Очевидно, в данном примере потери в скорости передачи - 1процент. Вот теперь, действительно все.

Как показала практика, дергать готовность ком-порта передатчика не надо. Многочисленные эксперименты показали, что при реальной работе через ком возникает множество естественных пауз различной длительности. (были проверены несколько сетевых игрушек, сеть между двумя Вин98, терминалки с разными протоколами. Действительно плотный поток оказался только у терминалок, работающих через Z-модем). В моей версии линка время принудительной установки триггера выбрано около 5 миллисекунд. Такие паузы встречаются очень часто. Правда, это ограничивает снизу используемые скорости передачи (в моем случае - не меньше 2400). Зато никаких проблем ни с каким софтом я не имел во всем диапазоне скоростей 2400..115200.

(скорость может колебаться,надеюсь мне не надо объяснять почему...)