Examples no longer compile on AVR 32u4, AVR 328

[ki4mcw]

Somewhere between version 4 and version 7 of RadioLib, the use of Program Memory expanded to such an extent that the examples no longer compile for AVR 32u4 or 328 (or at least, the examples for RTTY, APRS, and Hellschrieber). Are there any options besides replacing hardware or using old versions of the lib?

Sketch uses 33536 bytes (116%) of program storage space. Maximum is 28672 bytes. Global variables use 2503 bytes of dynamic memory. Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it. text section exceeds available space in board

Compilation error: text section exceeds available space in board


Thanks,
Rob KI4MCW

[jgromes]

Unfortunately the only two options are exactly what you wrote: use older versions of the library, or change the hardware. I would strongly suggest not using ATmega328/32u4 anymore, both of these designs are 16 years old at this point (at least that's how far back the datasheet revisions go).

With the next major release, I will most likely drop official support for these and remove them from the CI and readme.

Also, this is not really an issue (and there's not much we can do about it), I will convert this thread to a discussion.

[jrhbcn]

Hello, I am running into the same problem as this discussion. In my case, I am trying to use RadioLib in an ATTINY3226 (with 32 KB Flash, 3 KB SRAM and 256B of EEPROM). ATtinys are a very nice hardware (2-series is also quite recent) and I think they are excellent companions to some LoRa modules. It is quite a pity that RadioLib cannot be compiled in them.

I have tried to define several RADIOLIB_EXCLUDE_* modules and protocols as I only want to use the sx1262 with the LoRa protocol, however, some of them seem to break the compilation (for instance RADIOLIB_EXCLUDE_Si443x) and, in any case, they do not seem to affect at all the final compiled size. :(

Is there anything I can do manually to solve this? Such as removing manually some files and #includes or some functionality I would not use?

Many thanks for making public this excellent piece of code.

[StevenCellist]

Probably a bit easier to remove their base class inatantiations, such as:

SX126x::SX126x(Module* mod) : PhysicalLayer

Removing the PhysicalLayer there will automatically remove all its functions but probably also throw warnings about unused overrides so remove the override keywords indeed. Not sure if that change does enough, but it's likely the path you need to go down. It's been a while since I tried it, and not at the desk, so it's all from the top of my head.

[jrhbcn]

Success @StevenCellist, thank you for your help!

I have made SX126X not dependent from PhysicalLayer. I had to remove the overrides and copy some functions/variables over from PhysicalLayer to the SX126X class. Examples now compile, and the size has been reduced to "just" 18786 bytes.

I don't know if there is any interest in trying to generalize this for other users and add it to the library. Maybe moving the not-overriden functions to a new file (so they can be used in different modules) and then using some defines to use PhysicalLayer as a base or not.

In any case, thanks for your help, I will check if my changes do indeed work and not just compile though... :)

[jgromes]

@jrhbcn this is an interesting excercise. If we could get at least the basic drivers (SX126x, SX127x) running on smaller platforms, that might be worth looking into. The downside is that this will make it impossible to use any protocols, which depend on the PHY abstraction. So definitely no LoRaWAN on smaller MCUs.

[StevenCellist]

Unless there is a way to forcefully make the compiler behave with pruning of unused overridden functions? No clue.

[jrhbcn]

@jrhbcn this is an interesting excercise. If we could get at least the basic drivers (SX126x, SX127x) running on smaller platforms, that might be worth looking into. The downside is that this will make it impossible to use any protocols, which depend on the PHY abstraction. So definitely no LoRaWAN on smaller MCUs.

That is exactly what I thought, at least having base LoRa functionality in smaller MCUs is great imho. Take a look at my fork. It is very rough but I use a define variable RADIOLIB_EXCLUDE_SX126X_PHYSICAL_LAYER to separate sx126x from the PhysicalLayer class. It is still rough as I just copied the non-override functions from the PhysicalLayer to the SX126X class and I defined RADIOLIB_EXCLUDE_DIRECT_RECEIVE also just to take care of less functions. But it could be a start for doing it in a "semi-proper" way.

In any case, thanks again for this excellent library!