83ff964b66
This defines operation modes (IDLE, RX and TX) and allows defining up to to three pins to be controlled. For each mode a value can be specified for each pin a table. Compared to the previous handling, this: - Allows up to three pins instead of only two. - Gives more control over output pin values (e.g. to simply change polarity or support more complex control logic). In addition, the modes are treated as opaque by the Module code, allowing radio classes to define their own modes if needed. Some notes regarding the implementation: - The number of pins is limited at three, since most boards seem to need only two pins and only the Nucleo STM32WL55 board needs three. If more pins are needed in the future, the setRfSwitchTable() can be overloaded to accept either a 3-element or e.g. 4-element pins array, to allow new and old code to work as-is. Note that there is a RFSWITCH_MAX_PINS constant defined, but it is not recommended for sketches to use this constant when defining a rfswitch pins array, to prevent issues when this value is ever increased and such an array gets extra zero elements (that will be interpreted as pin 0). Note that this is not a problem for the RfSwitchMode_t values array, since any extra values in there will only be used if a valid pin was set in the pins array. - The pins array is passed by reference, so the compiler complains if the array passed is not the expected size. Since a reference to an array without a length is not supported (at least not by the gcc 7 used by the AVR core - gcc 10 for STM32 seems to accept it), the table array is passed as a pointer instead (but because arrays and pointers are reasonably interchangeable, the caller does not see the difference). - The existing setRfSwitchPins() method is still supported as before. Internally it creates a table with the right values and pins and passes those to setRfSwitchTable. - For easier review, this commit does not modify all calls to setRfSwitchState() in all radio modules yet, but has a compatibility wrapper to delay this change until the next commit. Similarly, the setRfSwitchTable() method is now defined on Module only, a wrapper for it will be defined in all radios that already have the setRfSwitchPins() wrapper in another commit. - To allow future radios to define any number of modes, the modes table does not have a fixed length, but instead is terminated by a special value. This is a bit fragile (if the terminator is omitted, the code will read past the end of the array), but rather flexible. One alternative to this approach would be to make setRfSwitchTable a template that deduces the array size from a template argument and then stores the size explicitly, but using templates probably reduces code clarity. |
||
|---|---|---|
| .github | ||
| examples | ||
| extras | ||
| src | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| keywords.txt | ||
| library.properties | ||
| license.txt | ||
| README.md | ||
| SECURITY.md | ||
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)
- 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.