Q5Microprocessor

Step 1 — Machine cycle time: the 8051 executes one machine cycle every 12 oscillator clock periods. With a crystal frequency fosc = 11.0592 MHz:

(This particular crystal frequency, 11.0592 MHz, is a standard, deliberately chosen value in 8051 systems specifically because it divides evenly to produce standard serial communication baud rates such as 9600 bps with zero error, which is why it is so commonly used in practice despite not being a 'round' number.)

Step 2 — Instruction cycle counts (standard 8051 timing table values): MOV Rn, #data = 1 machine cycle; NOP = 1 machine cycle; DJNZ Rn, rel = 2 machine cycles; RET = 2 machine cycles.

Step 3 — Analyzing the given subroutine:

Delay: MOV R3, #250      ; 1 cycle (executed once)
Back:  NOP                ; 1 cycle  ┐
       NOP                ; 1 cycle  ├─ executed 250 times (the loop body)
       DJNZ R3, BACK      ; 2 cycles ┘
       RET                ; 2 cycles (executed once, after loop exits)

Each pass through the loop body (NOP + NOP + DJNZ) consumes 1+1+2 = 4 machine cycles, and this loop body executes exactly 250 times (since R3 is initialized to 250 and DJNZ decrements it and loops back until it reaches zero):

Adding the one-time MOV instruction (1 cycle) and the final RET instruction (2 cycles):

Step 4 — Total time delay:

Result: the subroutine produces a time delay of approximately 1.088 milliseconds. This systematic method — computing the machine cycle time from the crystal frequency, looking up (or deriving) each instruction's cycle count from the standard 8051 timing reference, multiplying by the number of times each instruction actually executes (accounting for loop repetition counts), summing all contributions, and finally multiplying the total cycle count by the machine cycle time — is the standard technique used to precisely calculate software-generated time delays in 8051 assembly programming, essential for applications requiring accurately-timed delays (bit-banged serial communication, precise pulse generation, simple debouncing delays) where a dedicated hardware timer is not used or is unavailable for the purpose. If a longer delay were needed, this same subroutine structure could be extended by nesting an additional outer loop (using another register to repeat the entire R3-based inner loop multiple times), multiplying the achievable delay range considerably beyond what a single 8-bit register's maximum count (255) can directly provide.

Why two NOPs rather than one: each NOP instruction consumes exactly 1 machine cycle while performing no useful operation other than consuming time, making it the simplest possible 'filler' instruction for padding out a delay loop's cycle count to a desired value; using two NOPs per iteration (instead of one) doubles the cycles contributed by this part of the loop body without changing the loop's logical behavior, giving the programmer fine-grained control over the total delay by adjusting either the number of NOPs inserted per iteration or the initial value loaded into R3 (the outer loop counter), or both in combination, to hit a specific target delay value as closely as possible using only whole-instruction increments.

Sensitivity to crystal frequency accuracy: since the computed delay is directly proportional to the machine cycle time, which is inversely proportional to the actual oscillator frequency, any deviation of the real crystal from its nominal 11.0592 MHz rating (due to component tolerance, temperature drift, or aging) will introduce a proportional error into the actual realized delay — for applications demanding very precise timing (such as generating an exact serial baud rate or synchronizing to an external precise time reference), this crystal-tolerance-driven timing error is an important practical limitation of purely software-loop-based delay generation, which is one reason many time-critical embedded applications instead rely on the 8051's dedicated hardware Timer/Counter peripherals (configured to count a precise number of machine cycles and signal completion via an overflow flag or interrupt) rather than software-counted NOP/DJNZ delay loops, since a hardware timer's count value is unaffected by the specific instruction mix or code path taken elsewhere in the program, and can also free the CPU to perform other useful work concurrently instead of being tied up executing a busy-wait software delay loop for the entire delay duration.

Extending to longer delays (nested loops): for a delay significantly longer than what a single 8-bit register's maximum count of 255 can directly provide (since DJNZ decrements an 8-bit register, limiting a single loop to at most 255 iterations before it must be reloaded), the standard technique is to nest an outer loop around the existing inner loop, using a second register (e.g., R4) as the outer loop counter — the entire R3-based inner delay loop (MOV R3,#250 through the DJNZ/RET sequence, minus the final RET) is repeated once for each count of the outer R4 loop, multiplying the total achievable delay by up to a further factor of 255 (or whatever value is loaded into R4), allowing millisecond-range single-loop delays to be extended into the range of seconds using only two nested 8-bit counting loops, at the cost of a small amount of additional overhead cycles for the outer loop's own DJNZ instruction on each outer iteration, which is typically negligible compared to the large delay contributed by each full pass through the inner loop.