Measuring duration with an oscilloscope

I am trying to generate a digital signal pattern with a certain frequency and don't understand what is going on.

I have a segment of code that looks like this:
digitalWrite(pin, HIGH);
delayMicroseconds(pulseDuration);
digitalWrite(pin, LOW)

(assume the pin was LOW when we started).
I am measuring the duration of the HIGH pulse and obviously I expect it to be close to pulseDuration - with some loss of time due to using delayMicroseconds. pulseDuration is a few microseconds, like 5 microseconds.
But when I measure the duration on an oscilloscope I see the time is close to thousands of times higher so that if I actually want to get the width I want I have to use closer to delayMicroseconds(pulseDuration/1000)

(Note - the above is not the exact code I wrote, I took an extract to illustrate the problem I am having)

What am I not understanding correctly? I don't know if I am misinterpreting the commands or the oscilloscope output or something else altogether.

Show your real code.

Blackfin:
Show your real code.

And grab the 'scope trace and post it too.

4mel:
I don't know if I am misinterpreting ... the oscilloscope output.

Right now you're the only one with sight thereof....

There is a sequence of instructions and a clock to step through the program. Each line of code takes a certain amount of time to execute, and the processor is running machine code (not directly running C/C++).

Depending on what your program is doing and how those steps compile into machine code, one C/C++ instruction may take several machine instructions and some machine code instructions take more than one clock cycle.

I will get you more detail, but at first look does it appear that the code I provided above ought to do what I expected?
I want to be sure I don't have some completely obvious mistake since I am relatively new to Arduino

DVDdoug:
Each line of code takes a certain amount of time to execute, and the processor is running machine code (not directly running C/C++).

Depending on what your program is doing and how those steps compile into machine code, one C/C++ instruction may take several machine instructions and some machine code instructions take more than one clock cycle.

I do realize that but given the clock cycle of the Arduino and the small amount of code in between each pulse I cannot imagine it slowing down my timings to a thousandth. It would be a pretty small number of machine instructions.

Try adding a second delayMicroseconds() statement at the end to force a 50% duty cycle so you can see what is going on.
Pin is declared as an output pin?
Maybe try with the blink example sketch, then increase the frequency until it fails.

Without the delay you can measure how long a digitalWrite() call takes. If you want faster pulses then use direct port manipulation (PORTx).

I have to use closer to delayMicroseconds(pulseDuration/1000)

That is equivalent to delayMicroseconds(0). The minimum delay it can produce is 1us, it cannot delay for a fraction of a microsecond.

How you defined pulseDuration in your code affects how the calculation "pulseDuration/1000" is performed. If pulseDuration is an integer like 5, then pulseDuration/1000 = 0 because the C language performs integer maths when it can. If pulseDuration is a float like 5.0, then pulseDuration/1000 = 0.0005. Because delayMicroseconds() requires an integer, this will be truncated to zero.

Nearly all types of Arduino have no ability to perform floating point maths in hardware, so if your code is performing floating point maths, this will be done in software, and will be quite slow. This could be affecting the timing.

It is also possible that, if pulseDuration never changes in your code, the C compiler will detect this and perform the calculation "pulseDuration/1000" at compile time, in which case it will never be calculated when the code runs on the Arduino.

4mel:
I will get you more detail, but at first look does it appear that the code I provided above ought to do what I expected?

Can't say as 1) you don't clearly state what you expect and 2) what output pattern on the pin appears depends also on the rest of the code which you didn't post.