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.

[HeadBoffin]

I'd love to use RL for everything, we put it on a diet and got LW down to a point where it will fit, with user code, in to 48KB of flash. So you should have vanishingly close to zero expectations that it can be made to fit in to older MCUs.

I sort of get what you are saying about power use & size of code, but I suspect that's a very minor power use differential.

No reason why you can't use any of the other very good LoRa P2P libraries at either end - not knowing what you have at the control end it's hard to comment.

[RobertDeHate]

Thanks,
Was looking for a more modern implementation. Been using RadioHead.
I have a collection of processors I use,
RP2040/RFM95(8MFlash) ,LoRa32u4ii/SX1276(32kFlash), FeatherM0/RFM95(256kFlash),ASR6502/SX1262(128kFlash),ESP32-S3/SX1262(16MFlash), NRF52840/SX1262(2MFlash)
So having a library that is flexible is needed.
And home automation works great with LoRa radios, I even have a LoRa network running in my RV.
And expendable boards are sometimes needed. Use them once and they get destroyed. So lower cost models have their roll.
But I digress.
I can not get a RH transmitter to talk with a RL receiver.
I am sure it has something to do with the headers not matching.
So I dig deeper into the library to find out.
I see:
\brief Sets LoRa sync word. \param syncWord LoRa sync word to be set. \param controlBits Undocumented control bits, required for compatibility purposes.
Have to see how this compares to RH library.
And I ran across something about a header CRC as apposed to the normal CRC.

And this was baffling
When more bytes than received are requested, only the number of bytes requested will be returned
SX126x.h line 753 ;-)

Thanks for the good librarys.
At least if I have to hack them they are worth hacking.
Robert

[jgromes]

@RobertDeHate

I am sure it has something to do with the headers not matching.

If you are referring to the LoRa packet header, then that is fully handled by the LoRa radio. The only thing any control library can do is to completely disable the header (a.k.a. implicit header mode). RadioLib has LoRa header enabled by default, I don't know what RadioHead does but I would be surprised if it was disabled.

The actual things to check are:

• the usual LoRa parameters, SF/BW/CR
• CRC type (polynomial, initial etc.)
• whitening

[HeadBoffin]

Are you using different libraries at either end?

If Sandeep's bare bones lib doesn't work for you, then StuartsProjects is by someone that predates pretty much every other LoRa offering and goes outside to test stuff.

[RobertDeHate]

I wanted to use the same library on each end, that was why I was talking about 32k flash.
Anyway, I backed off to V6 of RadioLib and it compiles in 32k ;-)
Had issues communicating SX1276 to SX1262.
Checked SyncWord and found, "You couldn't make this up if you tried."
But no changes to SW helped.
It turns out to be the spreading factor, which was defaulted to 6.
I found in the SX1262 data sheet:
However, these modifications have made the new spreading factor incompatible with previous device generations. Especially, SF6 on the SX1261/2 will not be backward compatible with the SF6 used on the SX1276.
Changed it to 8, and communication is good now.
Thanks for all.
Robert