А так, как не надо был LPT порт, я нашол сей девайс:

Очень простой в повторении конвертер USB - LPT. Это клон версии 1.5 на односторонней печатке. Он может подойти для программирования микросхем ISP, JTAG, SEEPROM, управлять примитивной автоматикой, не критичной к скорости работы. Оригинальная схема нарисована мутно, а по сути - элементарная. Если проанализировать, то схема упрощается до безобразия - три резистора на входе с USB, и 15 выводов на LPT. Кварц в стандартном включении.

Если при правильной прошивке комп не определит нового устройства, то резистор R3 поменяте на 1.5кОм и а для надежности нужно понизить питающее напряжение до 3,3...3,6V (как в исходной схеме).

Топология печатки версии 1.5.

Спаяли, прошили через тотже LPT. После прошивки перерезали проводник между RESET(1) и PC2(25). Включили внешний кварц (для этого пректа hfuse=0x89 lfuse=0xAE)

Воткнули шнур в USB - ура! Установили драйвера...
Устройство работает, но очень медленно...

А если всё работает, а записать ничто через него нельзя, то читаем дальше...

Инстркуция гласит что этот прибор полностью совместим с различными принтерами, сканерами и т.д. Подключаем переходник к USB порту, устанавливаем драйвера. Смотрим диспетчер устройств - да там действительно появился некий LPT порт, например LPT2. Ok. Пробуем запустить какой-нибудь пример из статей выше. И ни тут то было - ни чего не работает. Грамотный читатель вдруг вспомнит что LPT2 имеет базовый адрес ввода-вывода 0x278. Однако такая модернизация адреса в запросах ни к чему не приводит - светодиоды как не загорались так и не загораются.

Чтобы разобраться в чем тут дело давайте вернемся на время к обычному "родному железному" LPT порту - LPT1, который из материнской платы торчит. Зайдем в диспетчер устройств, заглянем в свойства нашего порта. Там мы увидим вот такую картину. Отлично видно, что система прописала базовый адрес ввода-вывода 0x378 и запрос на прерывание номер 7. Все правильно.

Теперь погрузимся на уровень программирования. В примерах статей выше мы минуя систему защиты ввода-вывода легальными и нелегальными способами напрямую общались с реально существующим регистром ввода-вывода, которому присвоен адрес 0x378. Тут все понятно. Незабудем также о том, что Windows рекомендует работать с LPT портом используя вызовы API функций - OpenFile(), WriteFile(), ReadFile(). Приложения, которые используют LPT порт для обмена информацией по парралельному интерфейсу с внешними устройствами (принтер, например) так и делает. У него нет задачи установить на каком-либо бите регистра Data лигическую еденицу. Ему (приложению) нужно просто отправить пакет данных, а кто там будет какие линиии при этом дергать и считывать его не сильно интересует. Эти операции проводит системный драйвер LPT порта. Он подгружается в память при загрузке ОС. Когда мы вызываем функцию OpenFile("LPT1", ....) мы посути дела обращаемся к драйверу порта, который имеет символическое имя LPT1. Драйвер делает кучу всякой работы - запрещает доступ к порту другим процессам, настраивает параметры протокола передачи данных, собственно реализует эту передачу, но в конечном итоге все это сводится к прямому управлению отдельными битами LPT порта на уровне ядра ОС.

А теперь попробуем поработать с нашим переходником USB-LPT. Начнем как не покажется странным, с API вызовов. Запускаем OpenFile("LPT2", ...) (например LPT2, смотря как этот переходник диспетчере устройств назовется). Что при этом происходит? Дело в том, что теперь мы будем работать не с драйвером LPT порта ОС а с драйвером этого переходника! Вот в чем фокус то! Он принимает пакет данных от нашего пользовательского приложения и в нужном формате через систмный драйвер USB отсылает этот пакет на USB контроллер, "ноги" которого торчат из внешней LPT розетки на проводе (ну это так, "грубое объяснение"). Чуяте, здесь нет ни какого намека на обращение к регистрам по адресам 0x378(0x278), т.к. их просто нет!

Поэтому, когда Вы патаетесь запускать примеры данного раздела и обращаться напрямую по адресам 0x378 (если этот "псевдо порт" назвался LPT1), 0x278 (LPT2) и т.д. ни чего не происходит. Их просто нет! А вот программа котороая работает через API вызовы ни чего не заметит - вся низкоуровневая работа делается драйвером, а каким драйвером и куда пойдут пакеты данных (в реальный порт ввода-вывода или в USB хост-контроллер) - приложению насрать! Попробуйте открыть свойства "псевдопорта" в диспетчере устройств - что, нет вкладки с ресурсами? Есть, но там каие-то бредовые значения или вкладка деактивировнна? То то и оно.

Материал брал здесь прошивка