Menu
▾
▴
[opengtoolkit-cvs] portIO/c_source Description.htm,1.1,1.2
|
From: <lab...@us...> - 2004-03-11 10:05:23
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9548/c_source Modified Files: Description.htm Log Message: Corrected spelling errors Index: Description.htm =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/Description.htm,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** Description.htm 10 Mar 2004 20:27:01 -0000 1.1 --- Description.htm 11 Mar 2004 09:46:45 -0000 1.2 *************** *** 10,20 **** <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> Open ! G Port IO Driver<br> </big><br> Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware ! resources from user space (eg. any application) is restricted to improve system security. If an application tries to access such resources directly, the CPU indicates a Protection Fault which then is --- 10,19 ---- <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> OpenG Port IO Driver<br> </big><br> Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware ! resources from user space (e.g.. any application) is restricted to improve system security. If an application tries to access such resources directly, the CPU indicates a Protection Fault which then is *************** *** 25,38 **** If you want to program prototype hardware, this restriction is rather strong and it would be nice to loosen that protection partly for such ! situtions. There ! are basically two options to acess the port IO address range. The first ! is letting a device driver perform the actual port IO access, as device ! drivers run in the privileged kernel space and do not have the same ! limitations as applications in the user space. This is the method used ! by most device drivers for specific hardware. For such drivers the ! performance loss caused by a device driver call is not really important, as the device driver provides a high level API which can for instance return an entire buffer of data per single call. The access to ! the individual addresses (sometimes a driver needs to program dozensor much more of registers for a single operation) are all done inside the single device driver call, so that the performance loss caused by --- 24,36 ---- If you want to program prototype hardware, this restriction is rather strong and it would be nice to loosen that protection partly for such ! situations. There are basically two options to access the port IO address ! range. The first is letting a device driver perform the actual port IO ! access, as device drivers run in the privileged kernel space and do not ! have the same limitations as applications in the user space. This is the ! method used by most device drivers for specific hardware. For such ! drivers the performance loss caused by a device driver call is not really important, as the device driver provides a high level API which can for instance return an entire buffer of data per single call. The access to ! the individual addresses (sometimes a driver needs to program dozens or much more of registers for a single operation) are all done inside the single device driver call, so that the performance loss caused by *************** *** 45,49 **** the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a ! possibility to enable port address access dirctly from the user application.<br> <br> --- 43,47 ---- the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a ! possibility to enable port address access directly from the user application.<br> <br> *************** *** 90,96 **** <br> Ke386SetIoAccessMap will copy the IOPM to the TSS, and ! Ke386QueryIoAccessMap ! witll read it from the TSS. The first parameter of these functions is ! not documented and should be set to 1 to work as expected.<br> <br> NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS pProc, int install);<br> --- 88,94 ---- <br> Ke386SetIoAccessMap will copy the IOPM to the TSS, and ! Ke386QueryIoAccessMap will read it from the TSS. The first parameter of ! these functions is not documented and should be set to 1 to work as ! expected.<br> <br> NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS pProc, int install);<br> *************** *** 109,113 **** from kernel space you do need a device driver which can run in the kernel space and access the necessary routines and resources, ! independant if you want to let the device driver do the IO port access or provide functions to manipulate the IOPM to allow direct user space access to certain IO port addresses.<br> --- 107,111 ---- from kernel space you do need a device driver which can run in the kernel space and access the necessary routines and resources, ! independent if you want to let the device driver do the IO port access or provide functions to manipulate the IOPM to allow direct user space access to certain IO port addresses.<br> *************** *** 120,133 **** the device driver (which is the classical way as implemented by the Port IO functionality distributed with LabVIEW 7.0) or directly using ! the according x86 opcodes . However to be able to use the direct access functions you will first have to enable the according addresses. Be aware that if you want to access port 0x220 as 16 bit value, you will for instance have to enable port address 0x220 with a length of 2.<br> Failing to enable a port before accessing it with the direct access ! function will generate a General Protection Fault error under LabVIEW ! 6.0 where as LabVIEW 6.1 and higher will catch the according exceptions itself and display a dialog box to that fact and suggesting to restart LabVIEW. If you are sure that this dialog was caused by such an ! unprivileged IO port access you can safely ignore the dialog as no modifications to any LabVIEW application data has been caused by the DLL.<br> --- 118,131 ---- the device driver (which is the classical way as implemented by the Port IO functionality distributed with LabVIEW 7.0) or directly using ! the according x86 opcodes. However to be able to use the direct access functions you will first have to enable the according addresses. Be aware that if you want to access port 0x220 as 16 bit value, you will for instance have to enable port address 0x220 with a length of 2.<br> Failing to enable a port before accessing it with the direct access ! function, will generate a General Protection Fault error under LabVIEW ! 6.0 whereas LabVIEW 6.1 and higher will catch the according exceptions itself and display a dialog box to that fact and suggesting to restart LabVIEW. If you are sure that this dialog was caused by such an ! unprivileged IO port access you can safely ignore the dialog, as no modifications to any LabVIEW application data has been caused by the DLL.<br> *************** *** 136,142 **** need any device drivers and will always directly access the IO port addresses. The functions to enable and disable certain port addresses ! are just empty operations on those systems. This allows ! applications to always use the same function calls (LabVIEW VIs) and ! still run correctly on Win9x/ME systems.<br> On Windows NT systems the DLL checks before each call if the device driver is already installed and running, and attempts to start and --- 134,140 ---- need any device drivers and will always directly access the IO port addresses. The functions to enable and disable certain port addresses ! are just empty operations on those systems. This allows applications ! to always use the same function calls (LabVIEW VIs) and still run ! correctly on Win9x/ME systems.<br> On Windows NT systems the DLL checks before each call if the device driver is already installed and running, and attempts to start and |
