Здравствуйте!

Написал драйвер для работы с последовательным портом COM1.
Так вот, не могу прочесть из драйвера его регистры
При чтении получаю 0xff.
Каким то образом надо заставить ACPI подать питание на порт!

Кто нибудь сталкивался с этим???

Здравствуйте, kai62, Вы писали:

K>Здравствуйте!

K>Написал драйвер для работы с последовательным портом COM1.
K>Так вот, не могу прочесть из драйвера его регистры
K>При чтении получаю 0xff.
K>Каким то образом надо заставить ACPI подать питание на порт!

K>Кто нибудь сталкивался с этим???

Что-то непонятно, как Вы это делаете и зачем? Если с целью общаться с внешним устройством, то использовать стандартный драйвер, а в противном случае, приведите пример кода...

Здравствуйте, ArtSh, Вы писали:

AS>Здравствуйте, kai62, Вы писали:

K>>Здравствуйте!

K>>Написал драйвер для работы с последовательным портом COM1.
K>>Так вот, не могу прочесть из драйвера его регистры
K>>При чтении получаю 0xff.
K>>Каким то образом надо заставить ACPI подать питание на порт!

K>>Кто нибудь сталкивался с этим???

AS>Что-то непонятно, как Вы это делаете и зачем? Если с целью общаться с внешним устройством, то использовать стандартный драйвер, а в противном случае, приведите пример кода...


Привожу часть кода драйвера:

UCHAR inport(USHORT portid)
{
unsigned char value;

__asm mov dx,portid
__asm in al,dx
__asm mov value,al
return value;
}

NTSTATUS DriverInitialize (PDRIVER_OBJECT pDriverObject,
PUNICODE_STRING pusRegistryPath)
{
...
gpDeviceContext->PortAddress = 0x3f8;
...
}


NTSTATUS ComTransmitData(USHORT PortAddress,
UCHAR* pInput, ULONG dInput,
UCHAR* pOutput, ULONG dOutput,
PDWORD pdInfo)
{
NTSTATUS ns = STATUS_SUCCESS;

*pInput = inport(PortAddress);
*pdInfo = 1;

return ns;
}

NTSTATUS ComDispatcher (PDEVICE_CONTEXT pDeviceContext,
DWORD dCode,
PVOID pInput,
DWORD dInput,
PVOID pOutput,
DWORD dOutput,
PDWORD pdInfo)
{
...
case COM_IO_TRANSMIT:
ns = ComTransmitData(pDeviceContext->PortAddress, pInput, dInput, pOutput, dOutput, pdInfo);
break;
...

return ns;
}

NTSTATUS DeviceDispatcher (PDEVICE_CONTEXT pDeviceContext,
PIRP pIrp)
{
PIO_STACK_LOCATION pisl;
DWORD dInfo = 0;
NTSTATUS ns = STATUS_NOT_IMPLEMENTED;

pisl = IoGetCurrentIrpStackLocation (pIrp);

switch (pisl->MajorFunction)
{
...
case IRP_MJ_DEVICE_CONTROL:
ns = ComDispatcher (pDeviceContext,
...
break;
}

pIrp->IoStatus.Status = ns;
pIrp->IoStatus.Information = dInfo;

IoCompleteRequest (pIrp, IO_NO_INCREMENT);
return ns;
}

NTSTATUS DriverDispatcher (PDEVICE_OBJECT pDeviceObject,
PIRP pIrp)
{
return (pDeviceObject == gpDeviceObject
? DeviceDispatcher (gpDeviceContext, pIrp)
: STATUS_INVALID_PARAMETER_1);
}


A здесь пример кода обращения к драйверу:

hDevice = CreateFile ("\\\\.\\MyDrv", GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);

DeviceIoControl(hDevice, COM_IO_TRANSMIT,
NULL, 0,
byte, 1,
&dData, NULL);

Здравствуйте, kai62, Вы писали:

Если Вы решили писать все сами, то тогда надо разобраться в програмных тонкостях.
COM порт представляет собой (с програмной точки зрения) 7 смежных адресов ввода-вывода, причем некоторые(в зависимости от установленных бит) играют разную роль. Так смещение 0 — THR/RBR, при DLAB = 0, и DLL при DLAB = 1;
THR — промежуточный регистр передатчика(соответственно при записи),
RBR — буферный регистр принимаемых данных(соответственно при чтении),
DLL — регистр младшего байта делителя частоты.
DLAB — 7 бит регистра со смещением 2(FCR).

Кроме того, необходимо анализировать ошибки, возникающие при передаче/приеме, так если Вы попробуете прочитать из порта, к которому ничего не подключено, или не совпадают частоты передачи данных, то Вы увидите 0xFF, и код ошибки в соответствующем регистре ....
Так что будте очень внимательны, и прочитайте какую нибудь книгу про компьютерное железо, или воспользуйтесь стандартным драйвером, по моему, очень тяжело найти задачу, с COM портом, которую нельзя было бы решить в user-mode

Здравствуйте, ArtSh, Вы писали:

AS>Здравствуйте, kai62, Вы писали:

AS>Если Вы решили писать все сами, то тогда надо разобраться в програмных тонкостях.
AS>COM порт представляет собой (с програмной точки зрения) 7 смежных адресов ввода-вывода, причем некоторые(в зависимости от установленных бит) играют разную роль. Так смещение 0 — THR/RBR, при DLAB = 0, и DLL при DLAB = 1;
AS>THR — промежуточный регистр передатчика(соответственно при записи),
AS>RBR — буферный регистр принимаемых данных(соответственно при чтении),
AS>DLL — регистр младшего байта делителя частоты.
AS>DLAB — 7 бит регистра со смещением 2(FCR).

AS>Кроме того, необходимо анализировать ошибки, возникающие при передаче/приеме, так если Вы попробуете прочитать из порта, к которому ничего не подключено, или не совпадают частоты передачи данных, то Вы увидите 0xFF, и код ошибки в соответствующем регистре ....
AS>Так что будте очень внимательны, и прочитайте какую нибудь книгу про компьютерное железо, или воспользуйтесь стандартным драйвером, по моему, очень тяжело найти задачу, с COM портом, которую нельзя было бы решить в user-mode

Здравствуйте!
Все тонкости работы с СОМ-портом мне известны.
Под ДОС у меня все работает нормально!
Ведь все дело в том, что под в драйвере под WINDOWS при чтении любого регистра в диапазоне 3f8-3ff я получаю ff, хотя, к примеру, исходное состояние регистра статуса линии 0х60.
Тут по моему все дело в ACPI, оно отключает питание портов, и каким то образом надо его заставить сделать обратное.

K>Тут по моему все дело в ACPI, оно отключает питание портов, и каким то образом надо его заставить сделать обратное.

Зарегистрироваться на машине вместо родного serial.sys

Здравствуйте, kai62, Вы писали:

K>Под ДОС у меня все работает нормально!
K>Ведь все дело в том, что под в драйвере под WINDOWS при чтении любого регистра в диапазоне 3f8-3ff я получаю ff, хотя, к примеру, исходное состояние регистра статуса линии 0х60.

А вот это действительно странно, я с таким еше не сталкивался, и ACPI здесь не причем. Я делал что-то подобное для LPT порта, и никаких странностей не возникло (хотя в литературе(то-бишь DDK), советуют использовать специальные вызовы вместо асм вставок). И serial.sys отключать не надо. Вы же в режиме ядра! Вам все дозволено! Вы можете использовать любые комнды процессора! Так что непонятно ....

Здравствуйте, ArtSh, Вы писали:

AS>Здравствуйте, kai62, Вы писали:

K>>Под ДОС у меня все работает нормально!
K>>Ведь все дело в том, что под в драйвере под WINDOWS при чтении любого регистра в диапазоне 3f8-3ff я получаю ff, хотя, к примеру, исходное состояние регистра статуса линии 0х60.

AS>А вот это действительно странно, я с таким еше не сталкивался, и ACPI здесь не причем. Я делал что-то подобное для LPT порта, и никаких странностей не возникло (хотя в литературе(то-бишь DDK), советуют использовать специальные вызовы вместо асм вставок). И serial.sys отключать не надо. Вы же в режиме ядра! Вам все дозволено! Вы можете использовать любые комнды процессора! Так что непонятно ....

Вся эта странность именно в портах 3fx.
Только они возвращают ff, да и на запись не реагируют.
А вот с динамиком работать можно: при обращении к портам 0х42, 0х43, 0х61 и манипуляции с ними все отлично, динамик пищит!

Случай из личного опыта: на матери ASUS MEL-B прекрасно работали с
COM-портами Win98, WinNT 4, Linux с ядрами 2.2 и 2.4. Но вот Win2k и
WinXP при загрузка драйверов (стандартных) жаловались на проблемы с
latch register и работать с портами отказывались. Вылечилось обновлением
BIOSа.

kai62 wrote:

>
> Вся эта странность именно в портах 3fx.
> Только они возвращают ff, да и на запись не реагируют.

>>
>> Вся эта странность именно в портах 3fx.
>> Только они возвращают ff, да и на запись не реагируют.

Да я это тоже заметли.
Если страндартный драйвер вести на этом пору и включен все рабоатет нармально.
По все видемости надо как то инициализировать ком порт.