Re: [avr-chat] STK500 w/ EEPROM chips

[Michael Hennebry]

On Sat, 8 Aug 2015, Kyle Evans wrote:

> On 08/07/2015 03:42 PM, Michael Hennebry wrote:
> > On Fri, 7 Aug 2015, Kyle Evans wrote:
> >
> > > Can avrdude and the STK500 write to a stand-alone EEPROM chip, for
> > > something like flashing coreboot onto a motherboard EEPROM chip.
> >
> > Probably not.
> > avrdude and STK500 are for AVRs and use their protocols.
> > A stand-alone EEPROM will probably not use the same protocol.
> > That said, if the EEPROM is made  by Atmel, it might use the same protocol.
> > One can always check the specs.
>
> By protocol do you mean command set? They both support SPI and ISP. The data 
> sheet for the chip has all of the commands, but I have not yet found any 
> related material in any of the documentation that I have for the STK500. 
> Which, is kind of why I'm fishing to see if anyone has tried this. My next 
> step is to compile avrdude and see what I find.

More or less.

SPI is just a hardware specification for moving bits around.
It says nothing about how those bits are interpreted.
AVR ISP is SPI with a particular interpretation of the bits.
IIRC it is pretty much uniform for all AVR that accept it.

Quite probably one can do ISP with things that are not Atmel.
Different bit sequences would likely be required.

In the case of a chip mounted on an STK500,
there can be two protocols involved:
PC to STK500 and STK500 to chip (ISP).
AVR Studio understands PC to STK500.
STK500 understands ISP.
Also, the STK500 con be configured so that
ISP can be done directly by external hardware,
some of which can be controlled by avrdude.
IIRC avrdude understands PC to STK500.
avrdude also understands several other programmers.

I think that there are programmers that could be configured to do
what you want and that avrdude could be configured to control them.
Finding them and doing so is left as an exercise for the reader.
Deciding whether that is too much exercise
is also left as an exercise for the reader.

AFAIK the STK500 has no understanding of anything
other than AVR microcontrollers.

--
Michael   address@hidden
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then."   --   John Woods