On Wednesday 13 January 2010, Øyvind Harboe wrote:
> Seing that avr is not at the level of an "official feature" I don't have
> a problem with merging this work in progress as it does not affect
> any other code. It can probably be refactored easily enough.
>
> Meanwhile we can "measure" how much interest there is openocd
> + avr w/some crude support...
A minor goal of mine was to throw OpenOCD at some AVR chips (AVR8
and AVR32) before 0.4 ships to see how it all behaves... assuming
I get around to that, it'll be with this patch included.
> Perhaps there will be some feedback on minor things to change,
> perhaps use size_t i for iteration variable instead of uint32_t i...
At some point it would be nice to sort out the various JTAG ops
on AVR8. As I recall, they document only the ones used to write
flash and EEPROM, and perform boundary scan. Whereas:
The On-chip Debug support is considered being private
JTAG instructions, and distributed within ATMEL and to
selected third party vendors only.
Clearly, someone needs to throw a JTAG/SPI sniffer at some of the
transactions issued by AVR studio, and so some "reverse engineering
for interoperability". :)
(I forget the story for AVR32, but at least the Nexus parts are
publicly documented.)
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
