Add files to SIZE_OPTIMIZED

[jflyper]

PR Status: For a reminder for discussion

Mostly initialization and/or used when tethered. Yields around 4.4Kbytes.

Configurable software serial port pin assignment #1849 would fit after this.

[jflyper]

Several more files added.

Additional yield of 12.7Kbytes.

[martinbudden]

This should be in speed optimised. PWM output is part of the GYROPID loop. When running at 32kHz every machine cycle counts - there is less than 31 microseconds to complete the loop.

[borisbstyle]

Yes correct it is part of speedloop.

Separation of init elements should be done

[jflyper]

Yeap.

1. Identify "Pure GYROPID loop" functions
2. Put them in different file and give it speed optimized (or the other way around), or
3. Use function attribute for optimization.

Everybody seems to have their own preference...

[martinbudden]

well, I don't really like pragmas in .c files unless absolutely necessary. So I'd move the init functions into a pwm_init.c module. Keeping the output functions in pwm_output.c seems sensible, since they are output functions.

[jflyper]

The separation would induce exposure of static objects; make pwm_impl.h (pwm_hidden.h?) to hide them from rest of the world?

[martinbudden]

I don't think it is worth going to that trouble for this smallish file. That would also make the code more convoluted. So in this case, I'd say, despite my earlier comments, it's probably best just to use a pragma.

[mikeller]

@martinbudden, @ledvinap: Do you have any insights on why gcc states that optimisation by attribute / pragma should not be used for production code?

[martinbudden]

Presumably because it is not portable, ie if you change the compiler it won't work. Doing it on a per file basis controlled by the makefile is much more portable.

[ledvinap]

@mikeller : Can you link the statement?

One reason may be that mixing different optimization levels may be quite stressing on the compiler, it may uncover unexpected bugs (with LTO, optimization on file and function levels are almost identical)

@martinbudden : In case of CF/BF, the portability should not me that big problem. Other parts of (low level) code are GCC specific anyway (some of them are my fault [ or "design decision"]).
IMO it will be sufficient to use one global optimization level when building for targets other than microprocessor - other targets have no memory/speed constraints. So other compiler just needs to ignore function level optimizations

[mikeller]

@ledvinap: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html, the section for optimize (coupled with the remark on what the GCC optimize pragma does on https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html

[martinbudden]

pwm_output.c must be speed optimised.

The intialisation functions in that module don't need to be speed optimised, but the motor output functions do.

[mikeller]

flight/servos.c and flight/mixer.c also contain functions that are part of the PID loop, so they probably shouldn't be size optimised in their entirety.

[martinbudden]

Note that flight/mixers.c, flight/servos.c and drivers/pwm_output.c are part of the highly speed critical PIDLOOP and so should definitely be in SPEED_OPTIMISED_SRC. My general view is we should not change the optimisation settings for those files at all until we have exhausted all other means of ROM saving.

I would also say that, generally speaking, all device drivers should be speed optimised.

I think the telemetry modules are candidates for size optimisation.

[jflyper]

Superseded by #2205