Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: А как дёргать лапами LPT через ВинАПИ?
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
Dr.Alex
Port = CreateFile ("LPT1", .... ) успешно открывает порт,
но WriteFile (Port, ....) ничего не выводит.
А еще хотелось бы какие-то функции, чтоб остальные лапы контролировать....
ReAl
Так WriteFile же, небось, хочет, чтобы ему ACK-али и вааще BUSY изображали, а то и вообще в EPP/ECP режиме работали. Т.е. ждёт на том конце какое-то устройство.
Статусные/управляющие ноги можно опросить/подёргать (проверки для простоты исключены)
Код
#include <windows.h>
#include <ddk/ntddk.h>
#include <ddk/ntddpar.h>
...
    HANDLE hLpt = CreateFile( "LPT1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL );

    UCHAR ParInfo;
    DWORD ret;

    DeviceIoControl(hLpt, IOCTL_PAR_QUERY_INFORMATION, NULL, 0, &ParInfo, sizeof(ParInfo),  &ret, NULL);
    // В ParInfo состояние статсных входов.
...
Устанавливать ножки управления через IOCTL_PAR_SET_INFORMATION
Смотреть где-то там http://msdn.microsoft.com/en-us/library/ff...28VS.85%29.aspx
Dr.Alex
АСКать пробовал, тупо ставя его в низкий уровень, неужто ещё и фронты создавать надо.. :-))
В остальном спасибо.
vvs157
Цитата(Dr.Alex @ Nov 21 2010, 17:42) *
Port = CreateFile ("LPT1", .... ) успешно открывает порт,
но WriteFile (Port, ....) ничего не выводит.
Никак. WinApi предназначен только для вывода на принтер, селективное "ногодрыгство" не предусмотрено.
paskal
Цитата(Dr.Alex @ Nov 21 2010, 21:23) *
АСКать пробовал, тупо ставя его в низкий уровень, неужто ещё и фронты создавать надо.. :-))

Здесь расписаны сигналы стандартного LPT порта: http://www.theiling.de/parport/centronics.html Как видим по линии strobe должен быть импульс, просто определенный уровень выдать недостаточно. А вообще первоисточник стандарт IEEE1284
ReAl
Стандарт IEEE1284 — не более, чем первоисточник по обмену согласно стандарту IEEE1284.

LPT — это устройство, которое позволяет (может позволять) работать согласно этому стандарту. Но кроме этого может позволять и прямое управление, как это делается при работе непосредственно с регистрами ввода-вывода под DOS или через драйвер доступа к портам под windows. И как это делает драйвер параллельного порта под Windows, в режиме SPP всё идёт тем же ногодрыгом, только в драйвере. Можно было дать канал ioctl для такой работы снаружи.
Для COM-порта в WinAPI есть всё дёрганье на нижнем уровне, для LPT под Windows почему-то этого не сделали, ioctl-операции есть только для статусных сигналов.
И, непонятно почему, даже к стаусным сигналам доступ занимает очень много времени — около десяти микросекунд.

Под Linux ioctl-коды есть на все операции с регистрами LPT и занимают они намного меньше времени. Например, для LPT-платы, прямое обращение к регистру данных или состояния которой занимает 0.7-0.72 мкс, ioctl-операции под Linux укладываются в 1.1-1.2мкс, под Windows, как уже сказано, только регистр состояния и около 10мкс.
V_G
Цитата(ReAl @ Dec 19 2010, 06:23) *
Для COM-порта в WinAPI есть всё дёрганье на нижнем уровне, для LPT под Windows почему-то этого не сделали, ioctl-операции есть только для статусных сигналов.

Так верно написали же, что LPT считается портом ТОЛЬКО для управления принтером, а COM - порт универсальный. Для универсализма допустимо и требуется больше функций.
Потому и управление через LPT считается дурным тоном. Если делаете для себя, то допустимо, если для клиентов - то крайне нежелательно. Винды в своем развитии допускают все меньше вольностей подобного рода.
sergeeff
Да и вообще LPT медленно, но верно вымирает. Нечего на него и ориентироваться.
ReAl
Цитата(V_G @ Dec 19 2010, 03:43) *
Так верно написали же, что LPT считается портом ТОЛЬКО для управления принтером,
Iomega ZIP drive. Сканеры.
Да, да, да, «они просто приспособили принтерный порт».

Цитата(V_G @ Dec 19 2010, 03:43) *
а COM - порт универсальный. Для универсализма допустимо и требуется больше функций.
Какая универсальность? COM-порт — это порт последовательного канала со своим стандартом.
У линий DTR, DSR, RTS, CTS есть вполне оговоренное предназначение. Надо аппаратное квитирование — включите его в DCB при настройке порта. Открывайт порт, указывайте скорость, режим квитирования, ... и всё. Обменивайтесь.
Зачем вытаскивать на уровень API операции установки и опроса состояния этих ног?
Точно такая же «вольность подобного рода».

Цитата(V_G @ Dec 19 2010, 03:43) *
Потому и управление через LPT считается дурным тоном. Если делаете для себя, то допустимо, если для клиентов - то крайне нежелательно.
Как клиент Iomega я в своё время был очень доволен. Да, они управление через LPT сделали в драйвере (против чего ял ично ничего не имею, см. ниже).
Но они не считали LPT портом прямо аж большими буквам ТОЛЬКО для принтера, за что я им и благодарен. Ну а уж 1284-ый стандарт так и вообще принтер хоть и упоминает, но как историческую основу.

Цитата(V_G @ Dec 19 2010, 03:43) *
Винды в своем развитии допускают все меньше вольностей подобного рода.
Зачем тогда вытащено прямое управление линими состояния LPT?
Если бы не было ничего — я бы относился с пониманием.
Вот есть порт, вот есть драйвера, вот есть ОС, вот есть приложение. Открывайте устройство (принтер, сканер, ...) и общайтесь через API с устройством. Опрашивайте его готовность через драйвер. И вообще — какой такой WriteFile? PrintPage, PrintDocument, раз это принтер.
А так выходит, что PaperEnd можно вручную опросить через IOCTL, а байт вручную выбросить, записав в регистр данных — нельзя. Где логика?

Ещё раз — я не считаю, что ОС обязана мне предоставить «низкий» уровень работы с каналом связи, будь то принтрный порт или порт RS232. Дала — хорошо, пользуемся. Не дала — разбираемся, как писать свой драйвер.
Я просто вижу странность — для одного порта наверх выведено и нормальное высооуровневое управление типа «включить аппаратное квитирование», и прямой ногодрыг RTS/CTS/DTR/DSR (при том, что при пассивных *Ready по стандрту состояние соответствующих *ToSend-о считется невалидным), а для другого — из нижнего уровня наверх выведена половина.

Цитата(sergeeff @ Dec 19 2010, 13:51) *
Да и вообще LPT медленно, но верно вымирает. Нечего на него и ориентироваться.
Это отдельный вопрос :-)
Кроме того, как говорил один мой знакомый на фразу «так это уже N лет не выпускается!» — «я уже в K раз большее время не выпускаюсь».
V_G
Цитата(ReAl @ Dec 19 2010, 23:12) *
Iomega ZIP drive. Сканеры.
Да, да, да, «они просто приспособили принтерный порт».

Да кто возражает-то? Приспосабливайте для себя и для своих друзей! Но я покупать что-либо с управлением по LPT не буду. И друзьям отсоветую. И клиентам-заказчикам.
А вообще веселое сочетание: date='Dec 19 2010' и Iomega ZIP drive. Сканеры с LPT.
У меня в офисе Пентиум66 с 95 виндой стоит на стенде с ВЧ аппаратурой. Включаю, когда работаю с программатором (комовским) и когда отстраиваю свои радиомодемы (тоже комовские). Летает!
Но это для себя. Друзьям, знакомым и клиентам все-таки ни LPT, ни вин'95 никогда не порекомендую.
ReAl
Cочетание date='Dec 19 2010' и принтер на LPT звучит лишь немногим менее весело. В зоне видимости у меня только один такой, и десятки 50/50 USB и Ethernet.
Да, где-то ещё есть. Но если сравнить количество работавших «тогда» принтеров на LPT и zip-драйвов, то по пересчёту сейчас и должно быть ноль целых шиш десятых iomega zip на город.

Да COM-порт ещё встречается чаще, чем LPT. В основом за счёт переходников USB-RS232, у которых прямое управление RTS/CTS/... — та ещё радость.

Но понимаете какая штука... В WinAPI функции работы с портами заложены были очень давно, про USB тогда и не слышали. Их состав не зависит от Вашего нынешнего отношения к LPT. И этот состав странен, висит как-то посредине. Что я и отметил.

Koluchiy
Когда мне надо было, написал помню драйвер и юзал его...
Но вообще, я с LPT много мучился в том плане, что на больших длинах кабеля начинаются перекрестные помехи.
Соответственно, быстро его забросил и перешел на другие интерфейсы sm.gif.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.