Re: [avrdude-dev] Bad programming speed on AT90S8535 using AVRdude

[Jan-Hinnerk Reichert]

On Monday 17 November 2003 20:20, Brian Dean wrote:
> On Mon, Nov 17, 2003 at 11:46:04AM +1100, idefixx wrote:

> I think your delays are caused by the data polling flash code.  I
> can no longer find a datasheet for the AT90S8535, however, I'm
> assuming it is similar to an ATmega8535, and it's datasheet says
> that when you poll the flash after writing a value, it reads back
> as 0xff until the value is written at which time the chip is ready
> to accept another value.  Some chips have two data polling values
> to contend with, depending on the memory type being written, thus
> the config file supports up to two read-back values.  It is a
> difficiency in the AVRDUDE logic that both are checked.  However,
> if only 1 polled readback value is supported for that part/memory
> type, both readback values should be set to the same thing.

There is still some bad behaviour left then.

If polling is used, there is a min_write_delay before every readback. 
In extreme cases this could even slow down programming compared to 
polling.

If polling is not used, there is an unneccessary read and a delay of 
min_write_delay+max_write_delay.

Attached is a patch that should work around these. It applies and 
compiles, but I have no means of testing it ;-(

BTW: Is it safe to have write delays as "int" on all architectures?
BTW: What is the granularity of usleep implementations?

/Jan-Hinnerk

faster-polling.diff
Description: Text Data