Timing (doing something x times per second)

Sorry for the broad thread title.

Something I've always wondered is how programs like sound drivers do something exactly ____ times a second. In the sound driver's case, probably 44100 times a second. I know there are platform specific sleep functions, but whatever operation is done is going to take time as well, so it's not all as simple as that.

How is this accomplished? One thread for timing and one thread to do the task?

In my case, I'm going to be using an FTDI chip to interface with an older chip and will need to update the registers with microsecond accuracy (1 MHz).

Thanks in advance.

The answer to that it *totally* platform dependent...

On windows you have Timers... SetTimer Function (Windows) ... provided by the OS...

Other systems may have events or counters for the purpose.

Many uC (Micro-Controller) setups have built in timer interrups.

So that's all there is to it? Somehow I thought it'd be more elaborate. Thanks for the help.

There probably will be a lot more to it to meet your requirement of microsecond accuracy, depending on what you mean by that phrase. The most common OS options - Windows, Mac, Linux - won't be able to guarantee this. Even if they can set a timer to go off every microsecond it won't be exactly a microsecond, and there's no guarantee if it will be shorter or longer.

But then again if you're using this chip under an OS there's probably driver support to abstract away the need to write specific values into certain registers on a given clock pulse.

Even if they can set a timer to go off every microsecond it won't be exactly a microsecond, and there's no guarantee if it will be shorter or longer.

Isn't setting a process to realtime supposed to do that?

I think it's just the highest priority level for NT-based systems. It doesn't turn a normal Windows box into an RTOS but it might make it more likely that you'll get a better response time. That could make your program work, or it could just make the occasional timing problem happen less frequently and therefore make it harder to debug.

Originally Posted by KCfromNC

I think it's just the highest priority level for NT-based systems. It doesn't turn a normal Windows box into an RTOS but it might make it more likely that you'll get a better response time. That could make your program work, or it could just make the occasional timing problem happen less frequently and therefore make it harder to debug.

What about Linux ?
I heard of some projects making real time OS `s based on the Linux kernel.

Originally Posted by KCfromNC

There probably will be a lot more to it to meet your requirement of microsecond accuracy, depending on what you mean by that phrase. The most common OS options - Windows, Mac, Linux - won't be able to guarantee this. Even if they can set a timer to go off every microsecond it won't be exactly a microsecond, and there's no guarantee if it will be shorter or longer.

This is more true of userspace than kernel space, and the OP did say s/he's working on a hardware interface, which on any OS should provide access to kernel timers with fairly dependable microsecond accuracy as they run directly off the frequency of the CPU.

Originally Posted by manasij7479

Isn't setting a process to realtime supposed to do that?

Naaa... that might bring you down to +-.5 ms but it will never get you to microseconds in a multitasking system.

Usually timing that precise is the stuff of crystal clocks and data latches... hardware driven, not software.

Well it turns out that I was misguided and probably only need millisecond resolution. Either way, your answer still helps.