What is the difference between using IOCTL to write/read IO ports vs. modifying IOPM and using _INP/OUTP_ ??
in [Device Drivers]
|
Prev: Problem with WinUsb_ReadPipe
Next: What is the difference between using IOCTL to write/read IO ports vs. modifying IOPM and using _INP/OUTP_ ??
From: L337 on 2 Sep 2009 19:49 Also, it just looks like most of the time spent is actually in the IRP stack. Since the device object is already opened, (CreateFile), and I'm just repeating a DeviceIOControl call to do two consecutive writes, between the time when the kernel returns a sucess and the start of the next write, is nearly 8-9 uS.. this looks to be because the high-level command is still being queued down the IRP stack. By the time it reaches the device driver that responds to the IRP stacks, nearly that 8uS has passed and it only took 2 to 2.99uS to process the write command as we can see.
From: Maxim S. Shatskih on 3 Sep 2009 01:39 > The way I see it is that I want to do fast back-to-back burst IO > writes and IO reads. READ_PORT_BUFFER_USHORT is the solution. 1 IOCTL for a burst. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Alberto on 3 Sep 2009 10:35 Why don't you try this: __asm { mov dx,yourportaddress in al,dx; } Won't work on a 64-bit machine, but you can't go faster than that: you will be driving the bare iron. Or you can try writing that particular piece of code using Masm32. Try http:/www.masm32.com or http://www.movsd.com. Or, if you want a legit document on Microsoft's ml.exe and ml64.exe, you can try http://msdn.microsoft.com/en-us/library/afzk3475(VS.80).aspx. Hope this helps! Alberto. On Sep 2, 6:12 pm, L337 <vern.engineer...(a)gmail.com> wrote: > I just used DebugView to look at the IOCTL calls the timings between > each PCI IO transaction are consistent with what I'm seeing on the > scope. > > PORTTALK: IOCTL_WRITE_PORT_UCHAR(0x300,0xFF) // at 0.00000000 > sec > STATUS_SUCCESS RETURNED // at > 0.00000299 sec (2.99 uS) , this is when ntStatus = STATUS_SUCCESS; > PORTTALK: IOCTL_WRITE_PORT_UCHAR(0x300,0xAA) // at 0.00001238 > sec (1.238 uS) , the next IO WRITE > STATUS_SUCCESS RETURNED // at > 0.00001454 sec (1.454 uS) , here is when it completes again > > So it looks like, it takes about 2-3 microseconds from the kernel > making the call to when the PCI actually delivers the command. > Actually, I can't be specific, since I don't know precisely where to > trigger. But looking at this timing, I would say that too much time > is spent between calling the consecutive writes. As we can see, from > 2.99uS to 1.238 uS time later, is when the second requests actually > starts. Wow this is taking too long on the software side. Perhaps, I > can write a faster code ? There isn't much difference in the way the > generic Genport winDDK driver vs. porttalk IOCTL calls. They both look > identical in function to me in the way they process the and pass the > IOCTL to the kernel mode driver. > > The way I see it is that I want to do fast back-to-back burst IO > writes and IO reads.
From: Maxim S. Shatskih on 3 Sep 2009 14:32 >__asm >{ > mov dx,yourportaddress > in al,dx; > } Same as READ_PORT_UCHAR -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Alberto on 8 Sep 2009 11:06
Doing the machine code directly eliminates one level of uncertainty. :-) Alberto. On Sep 3, 2:32 pm, "Maxim S. Shatskih" <ma...(a)storagecraft.com.no.spam> wrote: > >__asm > >{ > > mov dx,yourportaddress > > in al,dx; > > } > > Same as READ_PORT_UCHAR > > -- > Maxim S. Shatskih > Windows DDK MVP > ma...(a)storagecraft.comhttp://www.storagecraft.com |