New Feature: Expanded flash-saving options for all parts

[gpshead]

We can pass -D DISABLEMILLIS to the compiler to turn off TIMER0 use and millis/micros support. But INITIALIZE_SECONDARY_TIMERS is a blind #define in header files like variants/tinyX5/pins_arduino.h so it cannot be disabled at compile time without modifying the framework.

Guard it with an #ifndef INITIALIZE_SECONDARY_TIMERS perhaps?

[SpenceKonde]

Reasonable; will need to mirror that change on all parts (note that for parts currently handled by the disastrous "tinymodern" core, which is getting axed in the near future, they will get this no sooner than when they're handled by the main core through a variants file, like they always should have been). Will consider adding a menu option for it as well - I will note that we have a general prohibition against adding features that are not accessible from the Arduino IDE.

[SpenceKonde]

The correct solution for this is a menu option. Per #481 disabling the ADC was also suggested. This makes sense as well. What would be very useful, IMO is to:

1. Make a list of which initialization procedures are amenable to this treatment. I am quite certain that there are others, though I'm not sure how many.
2. Determine what functionality is lost when these things are disabled; should such functionality also be made unavailable through the API functions? The same sort of compiletime known tests that I've been using over on megaTinyCore and DxCore to turn code which we know is wrong at compiletime into errors could be used here (ie, analogRead() when the ADC isn't been initialized? Surely that should be an error "analogRead() cannot be used if the ADC initialization is disabled" right?)
3. For timer initialization, I guess we should also set digitalPinToTimer to not act like it's a PWM pin if we disabled initialization of that timer, right?
4. Depending on the number of initialization options we would be skipping, it might make sense to present as one menu, or multiple - people don't like submenus, so if it's less than, say 3 (2^3 = 8 options max), I'd be inclined to make one menu.

[nerdralph]

I think the best solution is to structure the core so that the millis code only gets linked in when millis is called somewhere in the user code. That's what I did for MicroCore and PicoCore.

[nerdralph]

The way to implement is to have the millis() function, the interrupt handler, and the initialization all in the same .o. If the linker never sees a call to millis(), it won't pull in the .o in order to resolve the symbol. https://github.com/nerdralph/picoCore/blob/master/avr/cores/picocore/millis.S

picocore uses the WDT to avoid tying up a timer. It would be a bit more work, but the concept is the same when one of the timer/counters is used.

[SpenceKonde]

That would work except that it would also break PWM, or else someone uising both analogWrite() and milis() would get hit with the initialization twice.

[SpenceKonde]

Note that this work is ready for 2.0.0 except for the menu option (which is part of boards.txt which currently doesn't exist in working form for 2.0.0 - A script is being written to generate the boards.txt as it was made apparent that the boards.txt for ATTinyCore (unlike the newer parts) is not viable to maintain by hand.

[SpenceKonde]

This will be scaled back for 2.0.0