4c712c1f2c
This was introduced when STM32WL support was added. Using constexpr for
the END_OF_MODE_TABLE constant allows it to be initialized in the class
declaration, but this needs C++11. This moves the initialization out of
the class declaration to the .cpp file, which does not need constexpr.
It also lets STM32WLx::END_OF_MODE_TABLE define its value directly
(instead of aliasing Module::END_OF_MODE_TABLE) to prevent reduce
runtime overhead (see below).
The downside of this change is that the value of the END_OF_MODE_TABLE
is no longer visible in other compilation units and thus cannot be
inlined into the rfswitch_table (if used).
For example, on STM32, this means that instead of having a pre-cooked
rfswitch_table that lives in the .rodata section (so can be read
directly from flash), the table lives in RAM and is initialized at
runtime (the actual modes and pins are copied from flash to RAM by the
standard startup loop that copies all of the .data section, and the
END_OF_MODE_TABLE value is copied by a bit of new generated code). This
means a little more runtime overhead, but the cost is mostly in RAM size
(80 bytes for the SMT32WL sketches, 16 per mode plus 16 for the
END_OF_MODE_TABLE).
In a first attempt at this commit, STM32WLx::END_OF_MODE_TABLE was still
initialized using the Module::END_OF_MODE_TABLE value, but since the
latter is also not available at compiletime, this meant initialization
of the former also needed to happen at runtime, adding even more code
overhead (and possibly leading to ordering issues as well). To avoid
this, the STM32WLx::END_OF_MODE_TABLE initialization now just duplicates
that of Module::END_OF_MODE_TABLE.
On AVR, the impact is not so much: Since AVR cannot address flash
directly, the table was already copied from flash to RAM at startup, so
the extra RAM usage is just 4 bytes because END_OF_MODE_TABLE is now
also present in RAM, to be copied into rfswitch_table at startup.
Options for avoiding this overhead (not implemented in this commit)
could be (in no particular order):
1. Use a macro instead of a constant. Downside is that these cannot be
scoped inside the Module/STM32WLx classes like now, so this requires
changes to sketches that use a rfswitch_table (and reduced scoping
and using macros adds more opportunity for conflicts and weird
errors).
2. Apply the change in this commit only when C++11 is not available.
Downside is that the initialization value of these constants must be
duplicated in the .h and .cpp file for C++ and older versions
respectively.
3. Let sketches just use `{Module::MODE_END_OF_TABLE, {}}` explicitly
instead of `Module::END_OF_MODE_TABLE`. Downside of this is that this
requires sketches to be modified and that it lets the sketch encode
more of the table structure, potentially making future API changes
harder (but it probably does not really matter in practice).
4. Turn END_OF_MODE_TABLE into a static method, which *can* then be
defined in the class declaration and inlined. The method can then be
conditionally marked as constexpr, which allows C++11 compilers to
completely resolve the rfswitch_table value at compiletime, producing
a binary identical to before this commit. When constexpr is omitted
(e.g. on older compilers), some runtime overhead is added (pretty
much the same as the result from this commit). Downside is that
sketches must be modified, and the `END_OF_MODE_TABLE` "constant"
must now be called, e.g. `END_OF_MODE_TABLE()` which might be a bit
unexpected syntax.
|
||
|---|---|---|
| .github | ||
| examples | ||
| extras | ||
| src | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| keywords.txt | ||
| library.properties | ||
| license.txt | ||
| README.md | ||
| SECURITY.md | ||
| uncrustify.cfg | ||
RadioLib 
One radio library to rule them all!
Universal wireless communication library for embedded devices
See the Wiki for further information. See the GitHub Pages for detailed and up-to-date API reference.
RadioLib allows its users to integrate all sorts of different wireless communication modules, protocols and even digital modes into a single consistent system. Want to add a Bluetooth interface to your LoRa network? Sure thing! Do you just want to go really old-school and play around with radio teletype, slow-scan TV, or even Hellschreiber using nothing but a cheap radio module? Why not!
RadioLib was originally created as a driver for RadioShield, but it can be used to control as many different wireless modules as you like - or at least as many as your microcontroller can handle!
Supported modules:
- CC1101 FSK radio module
- LLCC68 LoRa module
- nRF24L01 2.4 GHz module
- RF69 FSK/OOK radio module
- RFM2x series FSK modules (RFM22, RM23)
- RFM9x series LoRa modules (RFM95, RM96, RFM97, RFM98)
- Si443x series FSK modules (Si4430, Si4431, Si4432)
- STM32WL integrated microcontroller/LoRa module
- SX126x series LoRa modules (SX1261, SX1262, SX1268)
- SX127x series LoRa modules (SX1272, SX1273, SX1276, SX1277, SX1278, SX1279)
- SX128x series LoRa/GFSK/BLE/FLRC modules (SX1280, SX1281, SX1282)
- SX1231 FSK/OOK radio module
Supported protocols and digital modes:
- AX.25 using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x and Si443x - RTTY using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - Morse Code using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - SSTV using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x and Si443x - Hellschreiber using 2-FSK or AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - APRS using AFSK for modules:
SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x - POCSAG using 2-FSK for modules:
SX127x, RFM9x, RF69, SX1231, CC1101, nRF24L01, RFM2x and Si443x
Supported Arduino platforms:
-
Arduino
-
Adafruit
-
Espressif
-
Intel
- Curie - Arduino 101
-
SparkFun
- Apollo3 - Sparkfun Artemis Redboard
-
ST Microelectronics
- STM32 (official core) - STM32 Nucleo, Discovery, Maple, BluePill, BlackPill etc.
- STM32 (unofficial core) - STM32F1 and STM32F4-based boards
-
MCUdude
-
Raspberry Pi
- RP2040 (official core) - Raspberry Pi Pico and Arduino Nano RP2040 Connect
- RP2040 (unofficial core) - Raspberry Pi Pico/RP2040-based boards
- Raspberry Pi - Arduino framework for RaspberryPI
-
Heltec
- CubeCell - ASR650X series (CubeCell-Board, CubeCell-Capsule, CubeCell-Module etc.)
-
PJRC
- Teensy - Teensy 2.x, 3.x and 4.x boards
The list above is by no means exhaustive - RadioLib code is independent of the used platform! Compilation of all examples is tested for all platforms officially supported prior to releasing new version.
In development:
- AX5243 FSK module
- LoRaWAN protocol for SX127x, RFM9x and SX126x modules
- and more!
Frequently Asked Questions
Where should I start?
First of all, take a look at the examples and the Wiki - especially the Basics page. There's a lot of useful information over there. If something isn't working as expected, try searching the issues.
Help, my module isn't working!
The fastest way to get help is by creating an issue using the appropriate template. It is also highly recommended to try running the examples first - their functionality is tested from time to time and they should work. Finally, RadioLib is still under development, which means that sometimes, backwards-incompatible changes might be introduced. Though these are kept at minimum, sometimes it is unavoidable. You can check the release changelog to find out if there's been such a major change recently.
RadioLib doesn't support my module! What should I do?
Start by creating new issue (if it doesn't exist yet). If you have some experience with microcontrollers and C/C++ in general, you can try to add the support yourself! Use the template files in /extras/ folder to get started. This is by far the fastest way to implement new modules into RadioLib, since I can't be working on everything all the time. If you don't trust your programming skills enough to have a go at it yourself, don't worry. I will try to implement all requested modules, but it will take me a while.