High-precision microsecond delay functionality. More...

Classes
class	DelayObject
	High-resolution microsecond delay timer class. More...

Detailed Description

High-precision microsecond delay functionality.

#include< HiResDelay.h>

The High Resolution Delay Timer provides microsecond-precision timing by utilizing hardware system timers. This is ideal for applications requiring precise timing control such as:

Protocol timing requirements
Sensor polling with specific intervals
Hardware interface timing
Signal generation

Usage Overview

When a DelayObject is created, it automatically allocates an available hardware system timer from the processor's timer pool. The timer remains allocated for the lifetime of the object and is automatically freed when the object goes out of scope or is destroyed.

Timing Precision

Minimum delay: Platform-dependent, typically ~1-10 microseconds
Maximum delay: Limited by 32-bit counter (up to ~4,294 seconds)
Precision: Hardware timer precision (typically sub-microsecond)
Accuracy: Depends on system load and interrupt latency

Example Usage

#include <HiResDelay.h>
 
void performPreciseTiming() {
    // Create delay object - allocates hardware timer
    static DelayObject myHiResDelay;
    
    // Verify timer was successfully allocated
    if (!myHiResDelay.valid()) {
        iprintf("Error: No free timers available\n");
        return;
    }
    
    // Perform precise delays
    myHiResDelay.DelayUsec(100);   // Delay 100 microseconds
    myHiResDelay.DelayUsec(200);   // Delay 200 microseconds
    myHiResDelay.DelayUsec(1000);  // Delay 1 millisecond
}
 
// Timer is automatically freed when object goes out of scope

Important Notes

Hardware timers are a limited resource - check valid() after construction
Delays block the calling task (use RTOS tasks for concurrent operations)
Very short delays (<10us) may have reduced accuracy due to overhead
For non-blocking timing, consider using the Interval Timer classes
Static or global DelayObjects prevent timer reallocation overhead

DelayObject vs. OSTimeDly()

OSTimeDly() and DelayObject::DelayUsec() both block the calling task, but they are built for fundamentally different timing regimes. Choosing the wrong one either wastes a scarce hardware timer or silently misses the timing you thought you asked for.

Resolution and Quantization

OSTimeDly() counts in RTOS ticks. With the default TICKS_PER_SECOND = 20, one tick is 50 ms. OSTimeDly(1) does not mean "sleep 50 ms" — it means "wake on the next tick boundary," which can be anywhere from near-zero up to a full 50 ms away depending on where the current time falls in the tick window. Only OSTimeDly(N) for reasonably large N approaches N * tick_period.
DelayObject::DelayUsec() programs a hardware timer directly, so the delay is measured in microseconds against the timer's own clock — no dependency on the RTOS tick phase.

Hardware Cost

OSTimeDly() uses the single shared system tick. Every task in the system can use it concurrently at no additional hardware cost.
DelayObject consumes one channel of a hardware timer peripheral (a small pool — e.g., four DMA timers on MCF5441X). Every active DelayObject reserves a channel for its lifetime, even when not actively delaying. Create them sparingly and prefer static/long-lived instances to avoid exhausting the pool.

Overhead

OSTimeDly() is effectively free: it inserts the task on the scheduler's delay queue and yields. No peripheral setup, no ISR wiring.
DelayObject::DelayUsec() arms a hardware timer, takes an interrupt on expiry, runs an ISR, and posts a semaphore. For delays shorter than ~20 us this setup cost dominates, which is why the implementation falls back to a calibrated busy-wait in that range.

Power Behavior

Long OSTimeDly() waits allow the scheduler to idle the CPU between ticks.
DelayObject keeps a peripheral clocked and will generate interrupts regardless of system load.

Which to Use

If you need...	Use
Sub-tick precision (<50 ms, or any µs value)	DelayObject
Protocol or bit-bang timing (I2C, 1-Wire, pulses)	DelayObject
General task pacing (>= several ticks)	OSTimeDly()
Periodic loops that tolerate tick-granular phase	OSTimeDly()
Drift-free periodic schedule	OSTimeWaitUntil()

Rule of Thumb: If the delay is at least a few RTOS ticks and you do not care about sub-tick jitter, use OSTimeDly() and leave the hardware timers for code that actually needs microsecond precision.

Comparison with Other Timing Methods

Method	Resolution	Blocking	Use Case
OSTimeDly()	1 RTOS tick (50 ms default)	Yes	General delays
DelayObject	Microseconds	Yes	Precise hardware timing
IntervalTimer	Microseconds	No	Periodic callbacks
Stopwatch	Microseconds	No	Time measurement

See also: Interval Timer Interval Timer for non-blocking periodic operations; Stopwatch Timer Stopwatch for time measurement; OSTimeDly() Standard RTOS delay function

Classes