I started to implement ATmega256x support. The major challenge here is that the current 16-bit addressing no longer suffices, and the ATmega256x deploys an "Load extended address" instruction to supply the high bit(s) of the address. Thus, the config syntax and the individual programming algorithms had to be touched.
Implemented so far: . new keyword "load_ext_addr" in config file . config file entries . jtag2 works out of the box as it doesn't use ISP commands . jtag1 doesn't support it anyway . the generic implementation used by the bit-bang backends has been done; it's quite slow in particular when reading, perhaps the high address bit(s) should be cached, and the load extended address command only issued when needed Not implemented yet: . stk500v2 adaptations . stk500[v1] and stk500 probably don't support the chip anyway . avr910/butterfly? As I'm going to leave for vacation by end of the week, I'm not sure whether I can do anything on the open items before that. If at all, it'll very likely be stk500v2 then. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
