Re: [avrdude-dev] Re: program error?

[Brian Dean]

On Wed, Apr 02, 2003 at 11:27:58AM +1200, Alex Shepherd wrote:

> > Could this perhaps be a marginal timing issue? The Windows code
> > doesn't go through the ioctl stuff and may execute slightly faster.
> > I'm not as knowledgeable about programming and any potential timing
> > issues.

Could be.  What part in specific are you trying to program, Alex?
Just for sanity's sake, lets first lets double check the various time
related parameters associated with the part (chip_erase_delay and
min/max_write_delay for the flash memory).

If those match the data sheet, one thing to try is to double the
existing values for that part and see if it makes a difference.  It
shouldn't, but its easy to try and if it makes a difference, then we
learn something.

> One other thing, my PC has dual 466 Celeron CPU 's. This may also introduces
> additional timing variation that may not exist on other systems. My
> experience with developing Java at work on these boxes is it usually shows
> up in threading concurrency issues but I could try and configure it only use
> one CPU.
> 
> Would this be variations in timing delays in the code or the few timing
> parameters in the config files?

I doubt that this would have any affect.

> So far I have found the instructions in the docs that say how to rebuild
> with Cygwin. Is this all I need or is there more to it than that?

I can't really speak to this - Eric's our Windows guys, all I'm able
to test with right now is FreeBSD.

> Alternatively it might be easier for one of you guys to add some extra
> command line options or environment variables and ship me a new binary, to
> allow me to specify different delay factors at runtime to try different time
> delays.

For now, please double check the values of the chip_erase_delay and
min/max_write_delay listed in the avrdude.conf config file for the
part you are using.  Or let me know what part it is and I'll check the
datasheet.  You can adjust those values without in the config file and
they will affect avrdude without having to recompile, which is the
easiest thing to do.

Eric mentioned the timing differences between using ioctl() on Unix vs
in/out instructions on Windows.  The in/out instructions are
undoubtedly faster.  It may be possible that these signals are
changing slightly too fast - not sure about that.  Eric - just
wondering if you might consider placing a short sleep or something
within a few of the parallel port manipulation functions for the
Windows port to slow them down a little at the right places, maybe
make this enabled with a #define so that they can be easily compiled
out?

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/