A µseconds delay C function

[Lucky]

I am currently trying to find a working (on a PC C-software surrounding) µseconds function.

Meaning that I need a function that can precisely give me a delay of milliseconds, with precision of microseconds.

C standard libraries give me:
function - precision :
sleep - seconds
delay - milliseconds

and
usleep - microseconds, but this does not work properly in the microseconds range under Windoze or DOS

So if anyone here knows a C function (not neccessarly from a standard library) please let me know.
Currently I'm investigating a clock function which times through the system clock, but that still is rather unprecise.

The alternative is to write an assembler program to directly program the timer chip 8253, which every PC has, and which every timer function uses in some ways. That will take much longer and time is an issue here, but that's how I'll do it if there is no other possibility.

 

[Cartouche Bee]

You will be hard pressed in a multithread environment to attain that level of precision. But I'm sure your determination will prove me wrong.

 

[Lucky]

Well, that´s why I don´t use Windoze, the program merely uses DOS. We need that real-time environment. Unfortunately usleep doesn´t work there either.

 

[Cartouche Bee]

Ahh, so it's not so much a specific length of delay but a delay to a 'future real time'.

 

[Cartouche Bee]

Found this don't know if it helps.



Information on 8253/8254 Programming
The IBM XT used an Intel 8253 to perform timing, sound generation, and memory refresh logic, the AT improved upon this by using the upwardly compatible 8254. The HCMOS version is called the 82C54. You can download a datasheet for the 82C54 from Intel.
The Intel 82C54 is a high-performance, CHMOS version of the industry standard 8254 counter/timer. It provides three independent 16-bit counters. All operating modes are software programmable. The 82C54 is pin compatible with the HMOS 8254, and is a superset of the 8253. Six programmable modes allow the 82C54 to be used as an event counter, elapsed time indicator, programmable one-shot, and in many other applications.

In the PC's architecture the 8254 is located at hardware I/O address 40H through 43H. The following C/Assembler code reads the 16 bit count maintained by channel 0 of the PC's 8254. Each count represent a time interval of 0.41905 uSec.

unsigned int read_8254_count (void)
{
asm {
pushf // save current inetrrupt status
cli // no ints while we read the 8254
mov al,0 // command to latch counter for counter 0
out 0x43,al // tell the 8254 to latch the count
db 0x24, 0xf0 // jmp $+2, this slow I/O on fast processors
in al,0x40 // read LSB of 8254's count
mov ah,al // temp save
db 0x24, 0xf0 // jmp $+2
in al,0x40 // read MSB of count
xchg al,ah // get right order of MSB/LSB
popf // return saved interrupt status
}
return _AX;
}

 

[Cartouche Bee]

And if you get real desperate you could always write some assembler noop loops and get some even finer resolutions.

 

[Lucky]

Thanks, I´ll try the assembler programming now, but also test a few other features. I hope at least one of them works as intended.

 

[Lucky]

Could you tell me where you got that C/ASM code from?
I need to find out which compiler they use, which include libraries, etc.
I currently use the standard GNU C compiler, so that the program is most platform independant, but that function does not work there. I rewrote the assembler code, but it still is kind of difficult to use.
Any info would be appreciated.

 

[gonzo_for_civ]

@Lucky, please post and tell us the results of your assembly efforts

 

[Cartouche Bee]

Good thing gonzo posted cause I didn't notice that you had made another post.

If you need better resolution than the timer permits you can stock a noop loop to take up the slack. Of course you have to be able to measure the performance of the machine that you run on to use that approach. I'm not too sure how "real time" you have to go to, you may have to even allow for checks to the clock in the noop loop if your getting real microscopic.



Anyway:

Did search on "8253/8254 Programming" got 97 hits

First link leads you to the program chunk I posted

http://www.techedge.com.au/tech/8253tec.htm

http://www.decisioncards.com/io/tutorials/8254_tut.html

http://www.decisioncards.com/io/tutorials/8254_tut2.html

 

[Lucky]

Well, the decision I had to make was between another C function I found and writing an assembler program. I actually did both, and the assembler part worked as intended, but it was kind of difficult to implement in the program itself.

The uclock C-function returns a simple clock setting of the 8253/8254. It is even simpler and therefore faster in processing the timer data than the assembler code I wrote and the ones you and I found somewhere else.
With the implementation in the C program, it runs with a precision of +-3..5 µs. We will now have to test whether that is enough. My personal belief is that it's ok, since the step motor itself is not capable of much more than that precision, but the experiments we will run next week (probably) will yield more results.

Until then I have to polish up the code a bit and hopefully gain a bit more speed. But since the comp we use is a PII 350, there is nothing really to worry about.
More on next week.

 

[Cartouche Bee]

Some 'C' compliers let you write inline code but I haven't done any of that for more than 10 years. The fact that the compiler wrote code to read the clock that was faster than the assembler kind of shows why it's not done much any more.

The time precision [Edit-opps: shouldn't] be a problem operating stepper motors, they probably have more operational lag than the resolution on the timer chip.

 

[Lucky]

Ok, the function seems to work as intended, the motor is running fine. The uclock() is precise enough.

But for final examination, we need to run several test series. That will still take a while more.