LabVIEW
Parrallel port XP performance
Well for all of you people who will make software for the parralel port under XP please take in mind that
Quote from
http://www.geekhideout.com/iodll.shtml
"If you were to take it upon yourself to wade through the documentation of the Windows NT/2000/XP ddk and piece together a driver that was callable by your application to do the I/O instructions on behalf of your application, you'd probably notice something not too pleasant--this sort of access is painfully slow. The call from application level to system level typically takes about one millisecond. Compare this to the one microsecond that a normal I/O access takes. To further the insult, you are at the whim of the operating system. If it has tasks which it believes are of higher priority than your lowly call to your driver, it will perform them, making precise timing nearly impossible."
;/ too bad I had no Idea about this when I started my software ... I have not time to rewrite the libraries now and my soft will work slow on XP.
At the above link it is possible to find a dll that is supposed to work directly with the parralel port ... have not checked it out yet... hope it works as the page says.
Regards,
Maciej
Quote from
http://www.geekhideout.com/iodll.shtml
"If you were to take it upon yourself to wade through the documentation of the Windows NT/2000/XP ddk and piece together a driver that was callable by your application to do the I/O instructions on behalf of your application, you'd probably notice something not too pleasant--this sort of access is painfully slow. The call from application level to system level typically takes about one millisecond. Compare this to the one microsecond that a normal I/O access takes. To further the insult, you are at the whim of the operating system. If it has tasks which it believes are of higher priority than your lowly call to your driver, it will perform them, making precise timing nearly impossible."
;/ too bad I had no Idea about this when I started my software ... I have not time to rewrite the libraries now and my soft will work slow on XP.
At the above link it is possible to find a dll that is supposed to work directly with the parralel port ... have not checked it out yet... hope it works as the page says.
Regards,
Maciej
Oh 1 more thing ;]
changing the settings in BIOS had no efect ... the reason is stated in my other post on this matter.
Thnx
changing the settings in BIOS had no efect ... the reason is stated in my other post on this matter.
Thnx
Ok,
This is the last post.
And I write it as a warning to all you developers who wan to make code that needs good performancc , or precise timing with the I/O ports under Windows.And I hope to finalize this thread.
Windows 98/95 does allow access to the ports of the PC from the application level, but unfortunately each call to the outport taken from the application level has to wait in line in the operating system driver until it is finnaly transfered to the port itself.
This means that applications written under DOS that use parallel port will work a lot faster than the ones written in the windows environment, no mulit thread = no problem.
In Windows XP/2000/NT the situation really sux, fistly the call takes more time than 98 even if you have a faster machine !!! Secondly access to the port is blocked on the application level ( security reasons, bla bla bla ).
There are libraries such as io.dll (http://www.geekhideout.com/iodll.shtml) or AccessHW ( developed by NI team ), but the operating system is still in control of your hardware. All these libraries can do is allow you access to the port on application level, it still means every signle one of your calls, is going to have to wait it's turn ( depending on what the OS is doing ), and will take A LOT!!! more time than direct access (In widnows you are talking to the hardware though a driver software , less crashes ... ;/ screwed up performance ).
In my case the issue was to download the latched data from the device to the PC using the STATUS register of the parralel port, while comminting operaons on the DATA and CONTROL port to send signals to the device ( such as for example incrementation of the memory adress before I read the data ). I have used the inport and outport VI's delivered by NI. Hence I had to be on the mercy of the operating system and the download took a real slow time.
The only solution that would be acceptable here, is to write a kernel driver that has in itself built in my the whole data acquisition module from my application. So I do not call the use of the port many times, rather I call the driver once, and force it to make the needed inport and outport operations on the parralel and than just transfer back the result back to the application layer.
But there is no way to use the port from application level that has any decet performance, or guarantees good timig!
Well as this is all nice and dandy writing, but a kernel driver means that if you slip up you can unreversably damage your system, and now that I finnaly came to understand the problem it is too late to rewrite my software:(
If you do not have the time to read this whole post this is the summary -> this sux ;/, but at least the kernel driver is a soultion.
Regards,
Maciej
This is the last post.
And I write it as a warning to all you developers who wan to make code that needs good performancc , or precise timing with the I/O ports under Windows.And I hope to finalize this thread.
Windows 98/95 does allow access to the ports of the PC from the application level, but unfortunately each call to the outport taken from the application level has to wait in line in the operating system driver until it is finnaly transfered to the port itself.
This means that applications written under DOS that use parallel port will work a lot faster than the ones written in the windows environment, no mulit thread = no problem.
In Windows XP/2000/NT the situation really sux, fistly the call takes more time than 98 even if you have a faster machine !!! Secondly access to the port is blocked on the application level ( security reasons, bla bla bla ).
There are libraries such as io.dll (http://www.geekhideout.com/iodll.shtml) or AccessHW ( developed by NI team ), but the operating system is still in control of your hardware. All these libraries can do is allow you access to the port on application level, it still means every signle one of your calls, is going to have to wait it's turn ( depending on what the OS is doing ), and will take A LOT!!! more time than direct access (In widnows you are talking to the hardware though a driver software , less crashes ... ;/ screwed up performance ).
In my case the issue was to download the latched data from the device to the PC using the STATUS register of the parralel port, while comminting operaons on the DATA and CONTROL port to send signals to the device ( such as for example incrementation of the memory adress before I read the data ). I have used the inport and outport VI's delivered by NI. Hence I had to be on the mercy of the operating system and the download took a real slow time.
The only solution that would be acceptable here, is to write a kernel driver that has in itself built in my the whole data acquisition module from my application. So I do not call the use of the port many times, rather I call the driver once, and force it to make the needed inport and outport operations on the parralel and than just transfer back the result back to the application layer.
But there is no way to use the port from application level that has any decet performance, or guarantees good timig!
Well as this is all nice and dandy writing, but a kernel driver means that if you slip up you can unreversably damage your system, and now that I finnaly came to understand the problem it is too late to rewrite my software:(
If you do not have the time to read this whole post this is the summary -> this sux ;/, but at least the kernel driver is a soultion.
Regards,
Maciej
