Hello, there!

I want to create an accurate timer, with a resolution of 100 microseconds. I want to use it to generate some 100 usec pulses on the parallel port.

Here are my questions:

1. The PerformanceCounter does not work on my P4 machine running Windows XP. Any suggestions?

2. On the old machine (a 586 running Windows 95), the performance counter works just fine. However, if I want to toggle a parallel port pin and keep it HIGH for 100 usec, the pulses are not always 100 us, sometimes they are much longer than that.
I tried modifying the process priority, but still some pulses are longer than 100 usec. I think the Scheduler takes over sometimes. Any suggestions here? Is there any way I can find out when my process time slice begins? Or something similar?
(The pauses between the pulses can be of variable duration, no problem with that).

Any ideas would be appreciated.
Thanks,
Posted on 2003-06-01 20:59:46 by VVV
Windows is NOT a realtime Operating System,
"sometimes" is the word that describes it very good ...


Use SOLAR OS instead ... :P .... or any other real realtime OS

Or you could try and use a KMD and inside it use CLI to disable interupts and i guess and taskswitching ...

but i doubt it you can keep OS without interupts for a longer period of time without consequences.
Posted on 2003-06-01 21:15:40 by BogdanOntanu
Thanks, Bogdan,

I am stuck with Windows.
The interrupts would not be disabled for more than say 100msec at a time.
Posted on 2003-06-02 11:57:09 by VVV

1. The PerformanceCounter does not work on my P4 machine running Windows XP. Any suggestions?


It seems I'm not the only one... I never succeded in running this HPcounter on any machine I laid my hands on...It's like if QueryPerformanceCounter and QueryPerformenceFrequency were plain legends...:confused:
Posted on 2003-08-14 17:28:49 by Magus Perde
The seconds are not the same length of time either. The ISR applies an adjustment after so many seconds or calculated TICs. IF you were to attempt this you would have to keep a sepererate rolling count in a memory location and jam load the TIC with a preset count after so many tics.
Posted on 2003-08-14 21:26:48 by mrgone
I?m pretty sure it?s impossible to do this in Windows
Posted on 2003-08-15 10:28:07 by WinCC
VVV,

Share with us, what goal you are trying to reach. And maybe, we can help there, but not this way.

Regards, P1 :cool:
Posted on 2003-08-15 12:39:29 by Pone
What do you mean PerformanceCounter not working in XP? Not working at all or timings are wrong? Nothing mentioned about it in platform SDK help, at least.

well if only 100us pulses are reqired then you can use an external microcontroller like AVR or PIC.
Posted on 2003-08-15 13:17:18 by iwabee
Windows was never designed to do things like this so it's probably impossible to have such an accuracy.. A seperate microcontroller would be easier, as iwabee already suggested.

Thomas
Posted on 2003-08-15 14:10:52 by Thomas
supposedly a Multimedia timer has a resolution of 1 millisecond
Posted on 2003-08-15 15:35:57 by Brad
There's timeGetTime() but it's not quite as precise as they say it is. Happens a lot that it just "hops over" 10 msecs.
Then there's GetTickCount(). Never tested it actually.

But one way to get an almost perfect timer is using directsound.. Create a secundary buffer and play it. Then use IDirectSoundBuffer::GetCurrentPosition to get the position and voila we have a 44 khz timer :alright:
Posted on 2003-08-15 15:38:43 by snq
Well, that depends on the soundcard. On cards that don't have hardware mixing, that will be very inaccurate.
Posted on 2003-08-15 18:56:33 by Sephiroth3
I think it can be done to some extent. Ie. For no more than a minute or two of pulse...

My piece-o-crap scanner runs on the parrallel port, and its drivers are written to basically hault the OS entirely while scanning.. (mouse doesnt even respond). In essence it suspends everything and puts total focus on the parallel port..

However, to do the same would require a WDM.. something I know a bit about, but not enough to be practical im affaid. The WDM is much more complex than a VxD and as such has a complicated learning curve. (No one that im aware of has actaully posted a WDM tutorial/example in MASM either).
Posted on 2003-08-15 22:27:05 by NaN
Gosh, don't you hate that word "Impossible"? It can be over come with work. Research my man. Anyway get data sheets on 8253 the TIC (Timer Interval Controller) "If I remember correctly" by Intel. It comprizes 3 internal programmable counters. After you have your documentation you'll need to write to the ports. Do a name search on this site for Four-F. He wrote a brilliant tutorial on KMD's. It's written for us assembler/tinkerers and he gives examples of programming the timer as well as writing to CMOS (where time and date are kept) by modifying the I/O permission bit map. He shows you how to generate sound to the PC speaker which could also be used for your timer since these are nothing but pulses coming from the 8253.
Posted on 2003-08-16 12:09:52 by mrgone
Ya here is his KMD tutorial... (forgot i had it in my archives.. doesn do much good for my needs as i run win98se... KMD only works on NT/2000/XP as far as im aware of).

Does anyone know if this is the decided direction of microsoft, or is it still the WDM (as of last i heard)??

:NaN:
Posted on 2003-08-16 14:43:15 by NaN
Microsoft doesn't sell 98 anymore. About 20% users on 98 the rest XP and 2K with some on Linex. WDM's only good for across the board all platforms with extra layering. I'm still waiting for mad scientist's TUT. Somebody give him a nudge ;)
Posted on 2003-08-16 22:06:16 by mrgone
Hi everybody,

Maybe a little OT, but it's on the timing subject anyway...
I'm currently writing an emulator for an old machine far beyond its time produced in the country I live (Belgium) in the late '70 and fell now into oblivion, namely the DAI from Indata. Appeared in 1979, Intel 8080, with 16 colours, stereo sound, etc...Great machine for its time, lots of tech features...but faaaar toooo expansive... I code it completely in Win32 ASM... Why in ASM ? Because I love it, that's all... :grin:
The emulator is working pretty well... Of course lots of features are missing, but it starts the ROM and you can type BASIC programs...
I'm currently fighting against the timing... After hours of testing, and having discovered that you can count on QueryPerformanceCounter on many machines the way you'd do on Goddess Vishnu's hands doing the washing up, I finally decided to use RDTSC... Of course RDTSC isn't available on CPU under Pentium... But if my target CPU was let say 486, I would have done it in pure DOS... ;) Then hafter many other hours of testing, I discovered that you can't count on Windows to get accurate timing under 10-15 milliseconds. For instance, in my timer initialization, I used GetTickCount as a standard measure :




RDTSC_Loop:

invoke GetTickCount
sub eax, SystemTime
cmp eax, 50
jb RDTSC_Loop



Then I replaced JB by JNE... Guess what, 50 is never reached, wether it's under or above... of course within 49.7 days I'd have a second chance :rolleyes: So I had no other choice than to save the real time elapsed and use it in the division to get the average cycle count, this way I'd have a more exact cycle count per ms... partly wrong, because in my emulation, if I use a millisecond as a time basis, I don't reach the 2Mhz target (the machine I emulate runs at more or less 2Mhz). In fact, my first idea was to execute one machine loop then wait for the host CPU to reach Host-CPU cycle per second / 2Mhz before executing the next one... Wrong !!! I was far under the speed of the real DAI, around 50-75%, depending of my init timer algorythm, though my calculation was correct...Then I tried the millisecond basis... bad idea also... so after several testing, I discovered that I was reaching a more or less accurate timing if I executed the loop for around 10 emulated milliseconds then wait for 10 real milliseconds being elapsed... Now I'm using slices of 20 milliseconds as a time basis, and everything works fine... That is I run the emulation at maximum speed during the equivalent of 20ms for the emulated CPU, then wait for the host CPU to reach those 20ms and start again...
Posted on 2003-08-17 20:23:16 by Magus Perde
Hi, Magus Perde!
I'm offtopic, too

here's anoter old box (Z80) emulator with C source
Unreal Speccy V0.22b

mey be it helps you...
Posted on 2003-08-17 21:09:38 by S.T.A.S.
It's not accurate. In fact it can change from PCB to PCB. Stray capacitance and all strip line effects. The algorythm's have an over all correction factor as well because the seconds are not the same length of time for the system clock. If you want accuracy you need a well calibrated scope and program the chip yourself. You may even have to keep a seperate count to let you know when you need to jam load the counter with a certain pre-set. Sorry don't want to sound like an "I told you so" guy but I do alot of hardware design and this is more my expertice. I hate high level syntax but very difficult to get around these days thanks to C blackout.
Posted on 2003-08-17 21:49:20 by mrgone

Hi, Magus Perde!
I'm offtopic, too

here's anoter old box (Z80) emulator with C source
Unreal Speccy V0.22b

mey be it helps you...


Spasibo bolshoe S.T.A.S. ;) I'm not good at all at C but I can decipher some code with help of a C book here and there...I will try to understand this code, it could be helpful indeed...
I worked hard last night and achieved some interresting results. I let the emulation running for the whole night beside the real thing, executing the same lines of BASIC code (i.e a counter), and I stopped this morning. The real DAI was showing 20045 when I pressed the break key, and pressing the esc key on my PC at the same time, the emulation showed 20100... Pretty close... now I have to test on several machines to see if the calibration routine is generic enough, not only on my PC...

Vassili
Posted on 2003-08-18 03:53:39 by Magus Perde