simplifying MN

[nerdralph]

Is there any interest in simplifying the MN code to make it more maintainable?
main.c has 36 preprocessor #if blocks, which I find painful to work with. Doing proper testing is practically impossible given the number of build options that could impact the functioning of the code.

As a start, I'd like to get rid of OSSCAL_SAVE_CALIB and OSCCAL_SLOW_PROGRAMMING.
I think the boot options could be greatly simplified.
I understand why bootloaders that use a watchdog for a timeout (i.e. Optiboot) need to manage/backup MCUSR, but not MN.

My size optimization work has so far been focused mainly on the usbdrv code, reducing the size by >200 bytes. There's not much more I can squeeze out of the usbdrv code. The main.c code compiles to about 400 bytes, and I think I can reduce that by at least 25% while maintaining almost all of the MN optional functionality. Before I start on that I'd like to know what core functionality has to be part of MN.

A couple obvious requirements I see are:

1. support for operation with external xtal and internal RC oscillator
2. the bootloader must timeout if there is no communication from the MN CLI utility

Is there any other "must have" functionality?

[ArminJo]

I have only one must have to add:

• Early timeout, if no host communicating.

[nerdralph]

I think OSSCAL_SAVE_CALIB should be completely removed, as it is more harm than good. Since the tuned OSCCAL value doesn't always pick the best value, a bad OSCCAL can be saved in the flash if the first tuning is off by 1 or 2 steps. Without OSSCAL_SAVE_CALIB, if the first tuing gets a bad value, unplugging and reconnecting the AVR usually gives a good OSCCAL value on the 2nd try.

[cpldcpu]

Yes, this is exactly the issue in usuability I mentioned in the other thread.

It's much more intuitive to plug the device in again when it fails than following some complex procedure to fix an incorrectly saved osscal value.

[ArminJo]

I totally agree 😀