Post
by phil » Tue Jun 05, 2018 11:13 am
If you are calling it from user mode (as you will be), then its as accurate as you can be in user mode - but can you be accurate to 1ms? You can only be as accurate as the windows task scheduler will let you be, and you will have to use high precision multimedia timers or the likes as the standard windows timer is not even accurate to 50ms generally.
Then there is the overhead of transitioning from your code (user land) to the driver (kernel land), which will vary depending on the CPU (esp since Spectre/Meltdown as I believe transitions to/from the kernel had to be changed to work around some/one of those issues (making it slower).
As for thread safe... I'm not sure to be honest. I didn't write this, I only ported it to x64 (and havn't looked at the driver code for about 10 years!). The code for the driver is all available (open source) so you could always have a look yourself! But reading only once and remembering will be quicker than reading 3 times (as you will reduce the transitions between userland and kernel by 2) and if things are changing quickly, you may get different values each time you read (which may or may not be what you want).
As for the port getting stuck, I'm afraid I cant help, the last time I used the parallel port directly was back in the DOS days about 22 years ago. Things have moved on a bit since then, but make sure the port is in the correct mode (EPP/ECP/Std) if that still applies. Maybe there are some control codes you can write to the ports control register to reset/unstick it I just don't know. Same goes for hardware recommendations.
Maybe someone else can help there, but don't get your hopes up, this is a *very* quite place these days.
More recently, when I have had any IO to do, it has been using a cheap raspberry pi £13-£35 which has much finer GPIO input/output control down to microsecond accuracy with hardware interrupts... And then I communicate with that from my windows boxes that need to do anything (usually over a web or tcpip interface) - that way there is no issue with Windows and direct hardware access (yay).
And I wouldn't worry about a donation!!! The people that wrote InpOut32 have seemingly disappeared and I am unable to do any further work on it (I don't have the ability to sign drivers as you need an expensive certificate and individuals cant get them, only registered companies) so I've kind'a left this here out of respect for the community. If it stops working there is nothing I can do and if someone does something silly and causes the certificate to be revoked, there will be nothing I can do... So realistically, be ware of using it (of course, if you are a company you could get a driver signing cert and build/sign it yourself going forward so it wouldn't be irreversible, its just not something I can do).
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9, Logitech MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, Intel i5-9600k, Asus Z390-ROG, 16GB DDR4,
nVidia GeForce GTX 970, Evo 970 500Gb NVME, 2x2TB WD Black (RAID1)