Question

頑張る on Tue, 12 Jun 2018 06:50:14


HI, 

I read 1B, 2B, 4B  from port by using these three functions READ_PORT_UCHAR (USHORT, ULONG)

but i don't know how to r/w specified length data, like 16 bytes.

code:

pIOBuffer = (PULONG)pIrp->AssociatedIrp.SystemBuffer;

...

switch (IoctlCode)
        {
        case IOCTL_GPD_READ_PORT_UCHAR:
            *(PUCHAR)pIOBuffer = READ_PORT_UCHAR(
                            (PUCHAR)((ULONG_PTR)pLDI->PortBase + nPort) );
            break;
        case IOCTL_GPD_READ_PORT_USHORT:
            *(PUSHORT)pIOBuffer = READ_PORT_USHORT(
                            (PUSHORT)((ULONG_PTR)pLDI->PortBase + nPort) );
            break;
        case IOCTL_GPD_READ_PORT_ULONG:
            *(PULONG)pIOBuffer = READ_PORT_ULONG(
                            (PULONG)((ULONG_PTR)pLDI->PortBase + nPort) );
            break;
        default:      
            return STATUS_INVALID_PARAMETER;

Replies

Don Burn [Windrvr] on Tue, 12 Jun 2018 14:54:50


First what size is the hardware port?   Your example assumes that you have varying hardware port sizes, but your question seems to assume you are trying to read N bytes from a port.   Assuming it is reading N bytes you code would be a loop using READ_PORT_XXX to get the data.

I also have to ask why you are writing a WDM driver i.e. using pIrp->AssociatedIrp.SystemBuffer  any new driver accessing general hardware should be KMDF.

Tim Roberts on Wed, 13 Jun 2018 00:25:57


This code is from the general/portio/sys sample from the Vista DDK.  Are you actually using this for real hardware, or are you just reading through the sample?  There is almost no new hardware these days that uses I/O ports at all.  Designs that do use hardware I/O ports generally do not use large buffers, because the I/O port interface is so freakin' slow -- hundreds of times slower then memory access.

If you did need to read 16 bytes from a single I/O port with this driver, you'd have the application make 16 separate calls to DeviceIoControl( IOCTL_GPD_READ_PORT_UCHAR ).  The size assumptions are built-in to the code.  It would take more than a simple modification.

Don is right.  If this is for real hardware, then the RIGHT answer is to write a KMDF driver that abstracts the function of the hardware.  Applications should not be worrying about I/O port numbers and sizes.


頑張る on Wed, 13 Jun 2018 02:46:23


Thank you for your reply. I have solved the problem!

I am starting to learn from WDM because I am a beginner and I will start practicing KMDF.