avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] config file change


From: Brian Dean
Subject: Re: [avrdude-dev] config file change
Date: Sun, 16 Mar 2003 19:47:02 -0500
User-agent: Mutt/1.4i

On Sun, Mar 16, 2003 at 04:32:31PM -0800, Theodore A. Roth wrote:

> I like the <programmer>_devcode better myself. Less confusing in the config 
> file.

Ok.  You way also allows a future programmer to use some other data
type than numeric.

> The pgm->cmd mechanism is going to need some serious work though. The avr910 
> doesn't have direct access to the SPI commands. I'll keep plugging on it...

Hmmm ... not long ago, when I thought that the STK500 'program page'
did not work for non-paged parts (real error was that I wasn't waiting
a sufficiently long enough time for a response before declaring the
STK500 dead), I worked on making the memory writing routines work with
the STK500 'program flash' and 'program data' commands.

Essentially what I did was define a couple of new (optional) functions
that a programmer could have and withing 'avr_write()', did a check to
see if that function was defined.  If so, that code was called to do
the write instead of the 'avr_write_byte()' routines which assume that
the programmer can pass through the serial programming commands.

For example, in 'avr_write()', a check was made to see if we were
programming the "flash" memory, and if so, a check was made to see if
(pgm->program_flash != NULL).  If that was the case, the code did:

        pgm->program_flash(pgm, part, addr, low_byte, high_byte);

Or something like that.  I had a 'program_eeprom()' function as well
that just took one byte (no low/high).  That was allowing the STK500
to use its native 'program flash' and 'program data' commands for
chips that did not support paged memory.  The parallel port programmer
just left these function pointers set to NULL and so fell through to
the existing code that called pgm->cmd() for whatever operation was
being requested.

Once I realized that the real error was timing, I zapped all that
local work and went back to the original which only required modifying
the timeval timeout.

In hindsight, I wish I would have kept that code.

I don't see anything glaring in your patch - looks fine.

-Brian




reply via email to

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