Am 16.04.2011 13:37 schrieb Stefan Tauner:
On Sat, 16 Apr 2011 00:13:50 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
We don't care about the memcpy (would be a micro-optimization and those are almost always a bad idea). However, we care about good debug and error messages.
what does the first loop get us in respect to what you said?
You refactored that loop since then, so it's not a code readability issue anymore.
i would change the check_block_eraser method to return different values for "not suitable" and "not defined/no more methods" (there cant be holes in the eraser array, right?).
That would fix the bug and simplify the code at the cost of additional lines in the log for the following case: erase method 0 is suitable, but fails (no change) ... suitable but fails (no change) erase method n is not suitable (my version: not printed, your version: printed) ...not suitable (see above) erase method m is not defined (no change) ...not defined (no change) END OF ARRAY
A few LPC/FWH chips have a chip-erase function which is only available in parallel programmer mode (i.e. not in a mainboard), and those would get those additional lines.
i would then remove the first loop and just do checking and printing in the main loop. would you accept a patch for that or is there something i have missed?
I'm not opposed to it per se, but I'd like to know how you plan to address the additional lines printed in that approach.
Regards, Carl-Daniel