[solved] Sensor freezes - Low memory available, stability problems may occur.

[scalz]

Another possible optimization, is to dig into the sensor libs you're using, and disable/remove/comment etc.. things you don't need. i'm pretty sure in BME280 there are stuff you don't need in some functions (just quick looked).
When using multiple libs and sensors, you can save a lot like this. Libs are there for providing us lot of features, but not necessarily needed in your final fw.

[gohan]

Shouldn't the compiler exclude all functions that aren't used in the code?

[alexsh1]

@gohan no, the compiler compiles whatever you ask to compile. It's your duty to "improve" your code by excluding stuff you are not using

[gohan]

Back in the days when I was studying, compilers used to have code optimizers built in... Oh well... Never mind 😅

[alexsh1]

@scalz I'm with you, but just like you I just do not have time for it. There is Teensy 3.2 with excellent footprint and 10 times speed and memory. So I just feel like if I'm going to spend time, it has to be not yesterday's technology.

[gohan]

Just for info, that's what I found on arduino forum

Eighteen Hints to Reduce Code Size

1. Compile with full size optimization.
2. Use local variables whenever possible.
3. Use the smallest applicable data type. Use unsigned if applicable.
4. If a non-local variable is only referenced within one function, it should be declared static.
5. Collect non-local data in structures whenever natural. This increases the possibility of indirect addressing without pointer reload.
6. Use pointers with offset or declare structures to access memory mapped I/O.
7. Use for(;;) { } for eternal loops.
8. Use do { } while(expression) if applicable.
9. Use descending loop counters and pre-decrement if applicable.
10. Access I/O memory directly (i.e., do not use pointers).
11. Declare main as C_task if not called from anywhere in the program.
12. Use macros instead of functions for tasks that generates less than 2-3 lines assembly code.
13. Reduce the size of the Interrupt Vector segment (INTVEC) to what is actually needed by the application. Alternatively, concatenate all the CODE segments into one declaration and it will be done automatically.
14. Code reuse is intra-modular. Collect several functions in one module (i.e., in one file) to increase code reuse factor.
15. In some cases, full speed optimization results in lower code size than full size optimization. Compile on a module by module basis to investigate what gives the best result.
16. Optimize C_startup to not initialize unused segments (i.e., IDATA0 or IDATA1 if all variables are tiny or small).
17. If possible, avoid calling functions from inside the interrupt routine.
18. Use the smallest possible memory model.

[ftw64]

A lot of debug code in this sketch has not been enclosed between #ifdef MYDEBUG/#endif blocks. Even if you disable MYDEBUG, most of the Serial.print() lines remain 'active'.

Try to comment most of the Serial.print() code or add the #ifdef statements to have the compiler ignore these Serial.print() lines.
Most memory in this sketch is eaten up by the strings ("xxx").

[alexsh1]

@ftw64 thanks - very helpful

[mfalkvidd]

@ftw64 since the strings are wrapped in F() they actually do not use (global) ram. When using F(), the strings are only stored in flash.

So while adding #ifdef around the print statements will save flash, it will not save ram.

[ftw64]

@mfalkvidd Oh, cool. I missed that (and I didn't know that, and I learned something today :-)). Yep, in that case it wouldn't help much.