«Работа с COM и LPT в Win32.»

Мне часто задают вопросы о работе с СОМ портами из программ, написаных для Windows 95/98/NT. Причем чаще всего спрашивают разработчики всевозможных управляющих устройств. Эти устройства либо были разработаны давно, еще в эпоху MS-DOS, либо разрабатываются сейчас. Но объединяет их одно – устройство должно подключаться к компьютеру, в большинстве случаев через RS-232 (COM), реже, через Centronics (LPT).

В литературе, чаще всего, управление последовательным и параллельным портами описывается на уровне регистров этих портов, причем примеры программ приводятся на языке Assembler. Это не удивительно. Последовательный порт довольно медленное устройство, к тому же специфическое. Поэтому в программах работающих с портами используются прерывания. Параллельный порт быстрее, но тоже медленный и не менее специфичный. Взять хотя бы возможность этого порта работать в двух направлениях, да еще и с использованием ПДП (DMA).

Написать программу, управляющую устройством через COM порт, для MS-DOS не так сложно. Это частенько делали не программисты, а сами разработчики устройства. Сложнее было сделать красивый и удобный интерфейс пользователя. Этим обычно занимались профессиональные программисты. С платформой Win32 дело обстоит сложнее. Но только на первый взгляд. Конечно напрямую работать с регистрами портов нельзя, Windows это не позволяет, зато можно не обращать внимания на тонкости различных реализаций (i8055, 16450, 16550A) и не возиться с обработкой прерываний.

Описание программирования будет состоять из подробного описания функций, специфических для работы с портами, краткого описания функций работы с файлами (с портами в Win32 работают как с файлами), краткого описания функций многопотоковой обработки и, естественно, примеров программ.

Сразу хочу оговориться, что Windows требует точного соблюдения аппаратного протока обмена с внешними устройствами. Другими словами, у Вас не получится управлять, например, светодиодом подключенным к одному из выводов параллельного порта. Просто потому, что система будет требовать отработки и сигналов STROBE и ACK. Если Вас это не устраивает, то выход один – писать собственный драйвер вооружившись DDK. Это, конечно, очень интересная тема, но в данной статье я не буду ее касаться.