unsigned char inport(unsigned short port)
{
unsigned char value;
asm {
mov dx, port
in al, dx
mov value, al
}
return value;
}
void outport(unsigned short port, unsigned char c)
{
asm {
mov dx, port
mov al, c
out dx, al
}
}
Port[] как в Паскале
Привет.
В Паскале определен массив Port[] для прямого доступа к портам. Подскажите, есть ли в C/C++ что-то аналогичное? Или, пусть, не аналогичное, но для работы с портами напрямую.
Спасибо.
В Паскале определен массив Port[] для прямого доступа к портам. Подскажите, есть ли в C/C++ что-то аналогичное? Или, пусть, не аналогичное, но для работы с портами напрямую.
Спасибо.
С какими портами - изясняйтесь яснее. )
Цитата: aks
С какими портами - изясняйтесь яснее. )
Топикстартер имеет в виду доступ к портам переферийных устройств, отображенных на оперативную память.
Зависит от среды исполнения программы. Если MSDOS - то аналогичные адреса будут совершенно справедливы (железо-то ни куда не делось). А вообще были такие инструкции In и Out (в C++ допускаются ассемблерные вставки), но они запрещены в user-mode в NTшках.
Так и знал, что без asm'а не обойтись
Цитата:
они запрещены в user-mode
Я драйвер подключу...
Из user-mode винды - CreateFile("COM1",...) и вперед без асма. Еще есть куча апишек типа
BuildCommDCB
BuildCommDCBAndTimeouts
ClearCommBreak
ClearCommError
CommConfigDialog
EscapeCommFunction
GetCommConfig
GetCommMask
GetCommModemStatus
GetCommProperties
GetCommState
и т.д.
а вот в дос-варианте C/C++ аналогов нет, хотя может борланд сделал для своей ТурбоС такое же? BGI ведь там и там есть!
BuildCommDCB
BuildCommDCBAndTimeouts
ClearCommBreak
ClearCommError
CommConfigDialog
EscapeCommFunction
GetCommConfig
GetCommMask
GetCommModemStatus
GetCommProperties
GetCommState
и т.д.
а вот в дос-варианте C/C++ аналогов нет, хотя может борланд сделал для своей ТурбоС такое же? BGI ведь там и там есть!
Цитата: Phodopus
Из user-mode винды - CreateFile("COM1",...) и вперед без асма.
Не всякая железка живет на ком-порту :) (ну вы поняли).
Ай-яй-яй, а DeviceIoControl забыли.
Цитата: hardcase
Не всякая железка живет на ком-порту :) (ну вы поняли).
А, так там массив доступа к любому порту из пространства портов! Тогда да, звиняйте, чета в голове одни COM-ы :)
Цитата: hardcase
Ай-яй-яй, а DeviceIoControl забыли.
Да с ком-ами он совершенно не нужен :)
А при чем здесь COM1? Это совсем другие порты.
Массив Port[] использовался в Turbo Pascal для доступа к портам ввода-вывода. В Turbo/Borland C++ вместо него можно использовать функции inp(port) для чтения байта из порта и outp(port, value) для записи байта в порт, все это, естественно, работает только в DOS.
Что же касается Windows, то здесь нужно использовать встроенный ассемблер. При этом в Windows9x можно использовать порты в UserMode (например, я делал проигрывание звука через динамик - совсем как в DOS), а в NT - нельзя, там инструкции in и out могут выполняться только в KernelMode (ring 0).
Массив Port[] использовался в Turbo Pascal для доступа к портам ввода-вывода. В Turbo/Borland C++ вместо него можно использовать функции inp(port) для чтения байта из порта и outp(port, value) для записи байта в порт, все это, естественно, работает только в DOS.
Что же касается Windows, то здесь нужно использовать встроенный ассемблер. При этом в Windows9x можно использовать порты в UserMode (например, я делал проигрывание звука через динамик - совсем как в DOS), а в NT - нельзя, там инструкции in и out могут выполняться только в KernelMode (ring 0).
Снова всем привет! Извините, долго не появлялся. Спасибо за ответы. Лично я решил это перелопатить с помощью асм. Посмотрел в инете, почитал книги и пришел к этому:
Под NT, естественно, для начала следует установить GiveIO.
Код:
Под NT, естественно, для начала следует установить GiveIO.
Цитата: Pelican
Под NT, естественно, для начала следует установить GiveIO.
Сам не использую и никому не рекомендую. Архитектура систем NT виртуализирует оборудование через диспетчер ввода/вывода. Делается это для того чтобы обеспечить разделяемый доступ к оборудованию. А таким вот быдлокодингом только проблемами пользователя обеспечивать. Причем не обязательно со своим приложением, а целиком в системе. А потом начинается - ой, вот это не работает/тут глючит/здесь виснет. Хочется как можно более прямой (низкоуровневый) доступ к оборудованию - пишите драйвер. Но даже для драйвера общение с портами идет через функции уровня аппаратных абстракций.
Никто не мешает перед общением с нужным устройством спросить у венды, на каком порту оно находится и не занята ли оно вендой.