First question: why do you want to measure the time between the serial and your RTC? To correct some offset in time between the message being sent and the 8052 acting on it?

Assuming the PC sends the time string as one string ("12:04:03.33") at 9600 baud which equates to about 1mS per character would give a message of about 12 chars(include a carriage return char) therefore 12mS to send the message. The 8052 should receive the last character 12mS and a little bit later. The 8052 should be able to process this data in less than a millisecond so we have a time offset of around 13mS. What time resolution do you want? How accurate do you want your RTC in the 8052?

Your previous asnwers to minimum and maximum were 0 and infinite! Sorry, this is the REAL world! So lets try to quantify what you're wanting:

When talking about your RTC (real time clock), what is it's smallest chunk of time (resolution)? 1 second, 1/10 second,1/100 second, 1 millisecond,1 microsecond,1 nanosecond, 1 femptosecond?

Then we have it's accuracy. How many seconds per day drift is acceptable? Zero, is impossible! Anything more than a couple of seconds per day is starting to get difficult to achieve (even your PC would be lucky to achieve this). Even the world's best atomic clocks have an error (very small though it is).

So, if all you're trying to build is an alarm clock, your resolution would be 1 second and your accuracy as good as you can get. Search this forum on RTC and you'll find heaps of info on how accurate you can get your clock easily. In this instance - measuring the time it takes for the PC to send the message and the 8052 to process it is somewhat smaller than your resolution (1/77 = 1second/13ms).

Your cpu cannot do two things at once! It can only process one instruction at a time - it is up to you to arrange your program to manage the tasks that need to be done. So try to think of your overall problem as a series of tasks. Divide and conquer! So for your little RTC problem we could divide up like this:

timer_interrupt: (1000 times/second)
add 1 to millisecond count.
if 1000 milliseconds, add 1 to second count
if 60 seconds, add 1 to minute count
if 60 minutes ,add 1 to hour count
if 24 hours, add 1 to day count
and so on.....
this code in assembler may only take 100microseconds or less to execute! So we've only chewed up 100/1000 = 1/10th of the cpu time.

serial_interrupt:
store character in memory
increment memory store address
check to see if too many characters have been received (we only have a certain amount of memory available!)
check to see if the character is a carriage return (used to signal the end of line). If CR received, set flag to tell main code to process the received data.


main code:

initialise timers,uart and interrupts
initialise memory variables
allow interrupts
loop:
Test for flag value set by the serial interrupt code.
if flag is true, then
{
process the string as received from the PC.
Check the values sent from the PC to see they are within range (ie if the hours > 23 then that is an error!), if all is ok,update the memory variables for the RTC (hours,minutes,seconds).
}
compare the RTC time with an alarm?
display the time on the lcd??
etc
goto loop.

As you can see we have divided the tasks. The interrupt code (serial and timer) work in the 'background' doing their stuff.As mentioned in my other post, the interrupts cause the main program to stop and the interrupt program to start. The interrupt program does what it needs to do, then it returns to the main code. The interrupt is really just a means of some external event to cause a subroutine call (LCALL) rather than your program explicitly doing it.