avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Win 32 port


From: Jan-Hinnerk Reichert
Subject: Re: [avrdude-dev] Win 32 port
Date: Mon, 16 Feb 2004 17:56:53 +0100
User-agent: KMail/1.5.4

On Monday 16 February 2004 14:03, Daniel Williamson wrote:
> Martin,
>
> I've had a go of the version 4 software and it works.
> I compared the times between the Cygwin dependant and the new win32
> version and got the following
>
> Mega 128 45356 Bytes
>
>               Win 32          CYGWIN
> Write         19.62 Seconds   18.63 Seconds
> Verify        17.62 Seconds   17.76 Seconds

Okay, I have a theory now and an idea how we can easily disprove 
it ;-)

I believe that windows reads some (coarse) timer on sleep-entry and 
than compares against it at each timer tick.
Let's say we have a Sleep(4) and a timer tick of 10ms. Than sleep 
would return at the first tick appearing after the Sleep, which could 
be almost immediately.

BTW: 10ms is a wild guess. However, the problem should also appear 
with a timer tick as low as 5ms (with the dubbled delay);

If this is true, the following will (really) cure the problem (The 
3*delay might fail again for uC with shorter write delay).
However, it adds up to 2*times the timer resolution to the delay ;-(

void usleep (unsigned long usec)
{
  Sleep(1); /* Delay till next tick */
  Sleep((usec+999)/1000); /* The real delay */
}

Of course, you can also define this as a macro if you like macros 
better.

@Martin: Please try this approach. However, we should use the 
High-Resolution-Timer if available, IMHO. I know that it burns all 
processor time, but it should be faster, since it has much better 
granularity. Maybe inserting a Sleep(0) in the loop to improve 
responsiveness of the system.

Thanks a lot to both of you :-)

Cheers
  Jan-Hinnerk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]