Saving flash space

[Pacjunk]

Hi, After upgrading to 5.7.0, my project no longer fits in flash (101% and was running at ~96% with 5.5.0). I am using radiolib for hellschreiber and LORA with SX1278 and SX1262 modules only. I am using an ATmega328p (32K flash).

I have found that defining RADIOLIB_EXCLUDE_DIRECT_RECEIVE, I can get flash usage down to 85%. I figured that since my project is transmit only, I will not be using these features. I tried the other "EXCLUDE" options, but these did not have any impact on size.

Are there any other ways of reducing flash storage of the library?

Thanks,

[jgromes]

Unfortunately, small footprint was not one of the design goals of this library. I don't know if you already have size optimization enabled (-Os), if not that might be able to save a bit more space.

Other than that, I could add more exclude options to e.g. disable CAD or even packet transmission/reception, but it's hard to guess whether the impact will be worth this. I'll try just out of curiousity.

The other exclude macros didn't do anything beacause you're not using them, so the other module classes get optimized away (don't get linked) during compilation.

[Pacjunk]

That's fine. The current 85% gives me some breathing room and ability to turn on debugging, so OK at the moment. Did the latest version have some large changes or datastructures that increased it by 5%?

[Pacjunk]

Another thing... With the RADIOLIB_EXCLUDE_DIRECT_RECEIVE setting enabled, the compiler generates the following:

c:\users\pacma\documents\arduino\libraries\radiolib\src\protocols\physicallayer\physicallayer.h:14:7: note: type 'struct PhysicalLayer' itself violates the C++ One Definition Rule
 class PhysicalLayer {
       ^
c:\users\pacma\documents\arduino\libraries\radiolib\src\protocols\physicallayer\physicallayer.h:14:7: note: type 'struct PhysicalLayer' itself violates the C++ One Definition Rule

It still compiles successfully though...

[jgromes]

Did the latest version have some large changes or datastructures that increased it by 5%?

There were some changes and fixes, it's quite common that future versions are more complex, and therefore larger.

With the RADIOLIB_EXCLUDE_DIRECT_RECEIVE setting enabled, the compiler generates the following:

I was not able to replicate this. I found a bug with the POCSAG protocol when only RADIOLIB_EXCLUDE_DIRECT_RECEIVE is defined, but not what you are describing. Can you copy the whole thing? And what other settings do you have?

[Pacjunk]

That is the whole thing! I don't have any special settings that I know of. Maybe my version of the IDE is too old?

[Pacjunk]

Same error with 2.0.4

[Pacjunk]

This sketch generates the error:

#define RADIOLIB_EXCLUDE_DIRECT_RECEIVE  // Save flash space
#include <RadioLib.h>
SX1278 radio = new Module(10, 2, 9, 3);
HellClient hell(&radio);

void setup() {
  int state = radio.beginFSK();
  state = hell.begin(434, 123);
}

void loop() {
  hell.print("TEST");
  delay(2000);
}

If I remove the hell stuff, and just leave the beginFSK, then the message disappears. Likewise if I remove the hellschreiber stuff from my large sketch (just leaving LORA and transmitdirect calls), then the message also disappears. If I change the above sketch to use the morse client, then I get the error again.

[jgromes]

Defining the macro this way will lead to inconsistencies across compilation units. The macro RADIOLIB_EXCLUDE_DIRECT_RECEIVE defined in your .ino is not visible from the .cpp files, only from .h files. So now the definition of PhysicalLayer, SX127x and HellClient doesn't match the implementation.

Instead of defining the macro in the .ino file, you should either define it globally using -DRADIOLIB_EXCLUDE_DIRECT_RECEIVE during compilation, or by editing the BuildOpt.h file.

[Pacjunk]

Thanks for that, but I don't really know what I'm doing! I tried adding it to the BuildOpt.h file, but it just generated heaps of errors. I don't know how to add it to the compiler flags. I tried searching the internet, but there are lots of contradictory answers talking about modifying non existent files (well don't exist in my installation anyway). I assume that after making this hack, I will have to remove it if I want to build another sketch that uses receive functions?

[jgromes]

The BuildOpt file got gradually out of hand. I added a smaller BuildOptUser.h file, where you can put the definitions. However, you are right that you will have to change the configuration for every sketch.

The only real solution is to provide build options for each sketch. Unfortunately Arduino IDE is very clumsy in thix regard. Arduino-CLI is better, since you can pass macro definitions to it. However, PlatformIO is best by far in this, as it has a proper configuration file.

[jgromes]

@Pacjunk FYI I also tried adding a few more exlude macros (e.g. for SX126x CAD and spectral scan), but unsurprisingly their impact is absolutely zero - the compiler is pretty good at optimizing away unused code.

[Pacjunk]

OK, used BuildOptUser.h and that got rid of the warning. Now I'm back to being critically short of flash. SX1278 uses 97% (104% with debug) and SX1268 uses 109%. I assume that when I got 85% used with the warning, certain functions were missing or effectively empty??

[jgromes]

It's possible, but I would advise against using it with known mismatch between the definitions and implementations. Is it an option for you to change the microcontroller for something with more memory?

[Pacjunk]

I tried it with the 85% setting, but it did not work. Using BuildOptUser.h comes in at 97% and the code is functional. I have three pieces of hardware already built, and it would be difficult to redesign it. There don't seem to be 3.3V 1284 or 2560 dev boards available and ESP32s have issues with deep sleep. I've been through my code and I can save a little bit here and there, but nothing that makes a significant impact. Most of the information online concerns methods for saving RAM (of which I have plenty), rather than flash. Thanks for your help.

[jgromes]

I'll take a look using nm/objdump to see if there are any obviously large smybols in the binary for ATmega328P.

[Pacjunk]

With 6.0, it looks like the code size has grown another 5% pushing me over the limit again! I didn't think that there was that many major changes in 6?

[jgromes]

:( unfortunately there were significant changes to the way RadioLib abstracts hardware + loads of bugfixes which probably contributed. I'm currently trying to resolve some copy-pasted code sections which might shrink the size a little bit.

You're using SX1278, SX1262 and Hellschreiber, right?

[Pacjunk]

Yep, SX1278, SX1268 Hellschreiber & LORA. I'll have to try and roll back to 5.7 (but after you introduced the BuildOptUser.h file)

[Pacjunk]

Oh dear, new version (6.2) and my latest project no longer fits in flash memory (ATMega328p) due to size increase. This project just does some simple message passing between a SX1280 and an SX1278 and uses 96% flash storage. With 6.2 it is 105%. Any more excludes I can use, or am I stuck with 6.1 (the project works, so probably no need to upgrade).

Thanks,

[jgromes]

@Pacjunk sorry, but I don't think there's much you will be able to do :/ In future version (7.x probably), I will likely drop official support for ATMega328 altogether.