arduinoavravrdudemicronucleus-bootloaderwindowswindows-10winusb

Brian S. Dean 4446ed3a7d Optimize flash memory handling a little bit by ignoring 0xff data that ... resides above the last non-0xff data value in the address space. Only do this for flash memory since writing a 0xff to flash is a no-op. This has the affect of creating smaller output files when dumping memory contents from flash if the program in flash does not consume the whole memory space. It also results in shorter programming times when avrdude is asked to load a file into flash that has lots of 0xff filled data past the last non-0xff data value. I think this is basically where Alexey was going with his s-record routine, but this should have a similar affect for all the I/O routines. The main difference is that Alexey's also optimized 0xff from the beginning of the address space and was not limited to flash. I think that these optimizations should be limited to the flash since it is currently the only memory that treats 0xff as special. git-svn-id: svn://svn.savannah.nongnu.org/avrdude/trunk@331 81a1dc3b-b13d-400b-aceb-764788c761c2		2003-05-22 02:33:17 +00:00
avrdude	Optimize flash memory handling a little bit by ignoring 0xff data that	2003-05-22 02:33:17 +00:00