How use timer to delay in a function?

Yes, you can use the timer to count time in the background:

start_long_operation();
start_timer();
while (!timer_end) {
    do_something();
}

Programs that does not make use of an RTOS normally has a super-loop that constantly scans inputs, timer flags, ...

They may perform too much concurrent operations to be able to use a timer for each of them, so instead they may have a single timer that ticks time. Let's say in 10ms steps:

extern unsigned current_ticks;
unsigned flash_start_time;
unsigned char flash_op;
for (;;) {
    if (flash_op != FLASH_IDLE) {
        switch (flash_op) {
            case FLASH_ERASE:
                start_flash_erase();
                flash_start_time = current_ticks;
                flash_op = FLASH_ERASE_WAIT;
                break;
            case FLASH_ERASE_WAIT:
                if ((current_ticks - flash_start_time) > FLASH_ERASE_TIME) {
                    do_flash_job();
                    flash_op = FLASH_NEXT_STATE;
                }
                break;
            case FLASH_NEXT_STATE:
                ...
        }
    }
    if (other_job_needed) {
        do_other_job();
    }
    if (yet_another_job_needed) {
        do_yet_another_job();
    }
    if ((other_timer - current_ticks) > OTHER_INTERVAL) {
        do_other_timed_job();
        other_timer = current_ticks;
    }
}

Of course you can. all you need to do is the following:
* start/reset your hardware timer.
* poll its value in your main loop.
* don't take any action until the required delay has elapsed.
* do whatever you need to do once the delay has elapsed.
* repeat this procedure whenever required.

for increased accuracy you might want to have your timer generate an interrupt, but that might not be required at all.

A delay function is defined normally as:

Actually, no. Delay functions are "normally" not defined or used at all, and for precisely the reason you just described: they hog the CPU and keep it from doing useful things in the meantime. The only exception are delays that are so short that a) it doesn't hurt to hog the CPU for their duration, and b) they can't be implemented other than by busy-waiting anyway.

Proper delays are implemented as timers. Either by polling a free-running timer to see when the requisite time has passed, or by setting a timer interrupt (think "alarm clock") that signals completion of the waiting time.

"Proper delays are implemented as timers."

Oh dear, please don't say that something as mundane as a delay must now be classified as proper or otherwise!

May have to put an "only academics permitted" warning on the forum if it continues.

"Oh dear, please don't say that something as mundane as a delay must now be classified as proper or otherwise!"

You can argue about whether "proper" is an appropriate term for it, but it is certainly a Really Bad Idea - for precisely the reasons given (and subject to the exceptions explained) by Hans-Bernhard Broeker.

In addition to the reasons to avoid delay loops already given by Hans-Bernhard Broeker, writing them in a high-level language (HLL) such as 'C' is also a Really Bad Idea - see:
" href= "http://www.8052.com/forum/read.phtml?id=152076">www.8052.com/.../read.phtml

... and "Real Programmers Eat Quiche"