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

[mfalkvidd]

Minor tweaks can be done, but nothing that should make a big difference. Cramming software signing and debug and externals libraries is probably just too much for your mcu. Maybe look at using STM32 or an ESP? Or disable debugging, but I guess you need that for something?

[alexsh1]

@mfalkvidd Disabling debugging does not help - I still get Low memory available, stability problems may occur.

[mfalkvidd]

@alexsh1 strange. It works for me.
Before disabling debug:

Sketch uses 34,854 bytes (113%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,671 bytes (81%) of dynamic memory, leaving 377 bytes for local variables. Maximum is 2,048 bytes.

After disabling debug:

Sketch uses 25,638 bytes (83%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,298 bytes (63%) of dynamic memory, leaving 750 bytes for local variables. Maximum is 2,048 bytes

I am using these versions of the libraries:

Using library SPI at version 1.0
Using library MySensors at version 2.1.1
Using library Wire at version 1.0
Using library Adafruit_BME280_Library at version 1.0.5
Using library Adafruit_Unified_Sensor at version 1.0.2

[alexsh1]

@mfalkvidd Thanks. I have the same libraries. I understand what the problem is now.
#define MY_DEBUG
and
#define MY_DEBUG_VERBOSE_SIGNING

are enabled in MyConfig.h
I disabled MY_DEBUG_VERBOSE_SIGNING in MyConfig.h and
put an extra line #define MY_DISABLED_SERIAL in the sketch - this undefines MY_DEBUG in MyConfig.h though this is not required as MY_DEBUG_VERBOSE_SIGNING would do it.

Sketch uses 29708 bytes (92%) of program storage space. Maximum is 32256 bytes.
Global variables use 1360 bytes (66%) of dynamic memory, leaving 688 bytes for local variables. Maximum is 2048 bytes.```

[gohan]

A friend of mine told me that atmel studio is more efficient at compiling than the arduino ide, I haven't tested it yet but maybe somebody could confirm.

[alexsh1]

@gohan Well could be, but it is too late to teach an old dog a new trick in my case. I am comfortable with Arduino IDE - I can flash atmega, ESP, SAMD etc.

[gohan]

If that was the case, you could use the atmel studio just for sw upload. Myself I'm using visual studio preferably, it makes it faster to write code but for quick modification I still use the arduino ide

[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.