So close to finished

EVERY time I write code.... I run out of flash memory. Drives me mad >:(
I am so close to being finished.

I have trimmed this code as best as I know how. Changed my digitalread/write statements to Port commands etc.

Question....

Which is the better way with regards to flash memory....

Directly saying the command: PORTD &= ~_BV(PD7); say 6 times within my code, or putting that port statement once in its own routine and jumping to it each time it's needed?

Probably not much in it.

Been using display.print(F("blah blah")); for my Oled screen text.
Pretty much out of ideas now

(deleted)

I will have to take out anything that I cannot show in here (its work related) and post the code.

The printing to the Oled is taking up a hefty amount I would think.

However, all the library's for the Oled screen, EEprom, Gyro, Fastled etc took up 85% before I had started!
Not much I can do about that.

I am wondering if throwing this over to a Teensy would work? I have one lying around somewhere untried.
I believe (but could be wrong) that they have more Flash?

(deleted)

Wow! Tough crowd!

Use the Teensy. As soon as you start trying to run a graphics screen, its nothing but a fight with resources to run your typical Arduino. I use Teensys for everything but the most basic stuff now.

-jim lee

Changed my digitalread/write statements to Port commands etc.

that is not really a flash memory save either, digitalRead() is a call to a function if it's in your program once it will be compiled, if it's in your code 100x it still gets compiled only once + the calls to the function, a function call will typically be a few bytes (OP-code for Call, the address, and any variables passed and returned)

Directly saying the command: PORTD &= ~_BV(PD7); say 6 times within my code, or putting that port statement once in its own routine and jumping to it each time it's needed?

Yes the latter.. In fact anything that you need to execute more than once for anything that takes up more than a 'Call' would. Any function you use will need to be compiled, so the more multipurpose you can make your function the better. If you have similar tasks that differ depending on certain conditions, pass those conditions to a function and test for them inside of it, and execute parts conditionally. It does not improve readability of the code and it can also go at the expense of speed (condition testing takes time and so do calls to functions)
Don't worry about how you write the lines of code. x=x+1; is exactly the same as x++; it both will get optimized to Inc(x). The same testing for conditions. If you can manage to completely remove the String Class from your code that will not be compiled (assuming that you haven't)
Finally, many functions that are part of libraries are fairly multi-purpose, though you may not use parts of them, those parts you could remove, and the opposite if you can modify your library so you can use the same function for more than 1 thing and not use some other part... etc etc.

Been using display.print(F("blah blah")); for my Oled screen text.

If you print the same thing or something similar more then once you could consider referring to it as a bunch of constant variables (this actually starts to save memory for any longish word already.

/*const char * a="abracadabra ";
const char * b="bubeli ";

void setup() {
  Serial.begin(9600);
  Serial.println(a);
  Serial.print(a);
  Serial.println(b);
  Serial.print(b);
  Serial.println(a);
  Serial.println(b);
}
*/
void setup() {
  Serial.begin(9600);
  Serial.println(F("abracadabra "));
  Serial.print(F("abracadabra "));
  Serial.println(F("bubeli "));
  Serial.print(F("bubeli "));
  Serial.println(F("abracadabra "));
  Serial.println(F("bubeli "));
}

void loop() {}

check the different versions of setup()

Deva_Rishi:
...that is not really a flash memory save either, digitalRead()...

Test your theory before you post that advice again.

The obvious solution is of course to use a different processor - one that has more flash on board.

For someone that's employed to do this for a commercial project I'm quite surprised that you're immediately thinking of the Teensy (very different architecture, costs much more), instead of one of the many other AVR processors (same architecture, costs little more), many of which have more flash than the ATmega328p.