[Top][All Lists]

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

RE: [avrdude-dev] Verify errors,

From: E. Weddington
Subject: RE: [avrdude-dev] Verify errors,
Date: Wed, 16 Jul 2003 22:52:21 GMT

> > Right, I've looked through the archived for the thread 
> > program error?
> >
> > It seems to end with alex saying he had Win2K SP2 on a 
> > Celeron 466,
> > I'm running a 1.1 GHz Athlon but the same OS.
> Hmmm... that would tend to suggest my dual processor 
being the problem. That
> just leaves the timers in cygwin or some other subtle 
> > What was the conclusion, apart from doubling the timing 
> > the processor
> > defenition?
> We have not reached a conclusion yet. Not many people 
seem to have this
> problem and it probably works fine on the code 
maintainers PCs - there in
> lies the problem. :(

I'm not sure that it's "not many people have this problem" 
as perhaps there aren't many Windows users of avrdude. :-/ 
And I have to admit, I rarely use avrdude, and when I do, 
it's using the serial port code with an STK500. Plus I 
haven't had much time recently to devote to development.

> I have had a play around with the 4.0.0 source code 
bundle and can
> ..configure and recompile it under the cygwin install I 
have but my system is
> not up to the mark to do a CVS checkout and build. It has 
problems building
> the configure scripts.

Can you do a CVS checkout with your system? I have a build 
script you can have that does a build from CVS checkout.
> I have made several changes already and will continue to 
play with it. I
> wondered if there was an issue with timing and so someone 
came up with an
> alternative timing mechanism using the select() function, 
but so far I have
> not been able to apply this patch locally. I guess I will 
have to do it
> manually. :(
> I did read somewhere that the cygwin people had done some 
changes to the
> implementation of usleep and family to now call nanosleep
() which must have
> been recently (earlier this year) added to cygwin. I was 
not able to find
> any comments about why they changed to this so I wonder 
if there was an
> issue that someone has fixed with the new nanosleep() 
> My observations are that the verify error is always at 
the beginning of a 64
> byte block so I now suspect that the code is not waiting 
long enough between
> blocks. Can you note the verify error locations and 
preferably have a look
> at the location in the AVR FLASH with PonyProg and see 
what the value is in
> FLASH? I am pretty sure mine were all still at FF which 
is a bit suspicious.
> The overall programming time under Win2K seems to be 
faster compared to
> running under Linux on the exact same hardware. Under 
Win2K it takes about 8
> seconds to program my bit of test code (6.8k long) but on 
Linux it take
> about 11-12 seconds. So this tells me that either delays 
are shorter on
> Win2K or somehow the code path on Linux is much longer - 
maybe doing the LPT
> port IOCTLs.

That is correct, the code path on Linux is longer due to 
the parallel port IOCTLs. 


reply via email to

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