One possibility: the windows kernel thread scheduler works with a
"clock" of 10ms. If your thread is pre-empted (ie, switched out of
context), you will not get another time slice for at least 10ms.

Consequently, all of the windows Wait* fuctions, which typically take a
millisecond timespan as an argument, will not time to a resolution lower
than 10ms. In fact, your wait call will happen on a multiple of 10ms.
Over longer waits, and a lot of repeated waits, the effect tends to
average out.

You can test this easily with simple C++ code that fires a timer
callback every 1 ms. If you use the QueryPerformanceCounter (and also
QueryPerformanceFrequency), and write out the timespan since the last
call, you'll see that despite the fact that you asked for 1ms, you get
10 or 0, seemingly at random. A function like this will demonstrate:-

void CALLBACK TimerProc( HWND hwnd,UINT uMsg,UINT_PTR idEvent,DWORD
dwTime)
{
	static LARGE_INTEGER time,last_time,elapsed_time;
	static LARGE_INTEGER pf;

	QueryPerformanceFrequency(&pf);
	QueryPerformanceCounter(&time);

	elapsed_time.QuadPart = time.QuadPart - last_time.QuadPart;
	last_time.QuadPart = time.QuadPart;

	TRACE("%d\n",elapsed_time.LowPart);
	return;
}

Call ::SetTimer with required parameters to use that.


Anyway, back to programming software. If the thread that does the serial
port sending uses windows' intrinsic wait function to time itself, then
performance could drop through the floor by at least an order of
magnitude; due to windows kernel design. The worst thing about this is
that it's not very well documented.

Jon


> -----Original Message-----
> From: piclist-bounces@mit.edu 
> [mailto:piclist-bounces@mit.edu] On Behalf Of Olin Lathrop
> Sent: 28 February 2005 13:30
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC:] prog time
> 
> Chen Xiao Fan wrote:
> > I think the overhead of the PC host software should not be 
> > underestimated. How long will it takes to program a 
> PIC18452 normally? 
> > I think 52s is way too wrong.
> 
> Maybe the bottleneck is the communications protocol, but I 
> would expect any modern PC processor to easily be able to 
> emit bytes fast enough to keep up with 115.2Kbaud without any 
> gaps.  87uS/byte leaves a *lot* of CPU cycles.
> It's hard to imagine what any programming software could 
> possibly be doing to take that long.
> 
> 
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com
> --
> http://www.piclist.com PIC/SX FAQ & list archive View/change 
> your membership options at 
> http://mailman.mit.edu/mailman/listinfo/piclist
> 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist