CMake for Linux

[2bndy5]

The usage of CMake for this library follows suite with the same implementation in the RF24 repo (except the RF24_DRIVER option). Any user-adjustable defines in RF24Network_config.h can be changed from CMake CLI options.

New build-linux workflow that

• cross-compiles & packages the library targeting armhf & arm64 architectures
  • packages targeting armhf & arm64 architectures will be automatically uploaded to future releases' assets
• tests the python wrapper installation (not cross-compiled though)
• tests the library examples (not the python examples though)

A new badge in README now reports the latest status of the Linux build CI workflow

---

• Additional improvements to the CI workflow scripts that limit triggers to only when relevant files are modified.
• python wrapper now includes metadata recognized by pypi.org (specifically the license agreement)
• fixed docs about when RF24_LINUX is defined and forced (via DOXYGEN_FORCED - only defined when doxygen is run) Arduino-only members to be rendered as well ass linux-only members. Technically, the docs were already written for this, but the #ifdef statements confused doxygen (thus doxygen output incorrect CLI warnings).
• introduced 2 new macro definitions to replace a couple sentinel vales used repeatedly throughout the source code. Also replaced some calls to write() that used an existing macro defined value instead of passing the value using the macro defined name.
• renamed write()'s directTo parameter to sendType for clarity.
• found & fixed a malformed relative hyperlink in addressing.md
• unified the debug output functionality to depend on macros defined in RF24_config.h. This means that printf_P, PSTR, and PRIPSTR are used inside the IF_SERIAL_DEBUG*() calls. This change should also fix printing the return c-string from RF24NetworkHeader::toString() (by using PRIPSTR) for some debugging outputs on various platforms.
• The maxlen parameter to read() and peek(header) are now optional by using the MAX_PAYLOAD_SIZE as a default value. The mentioned functions will only handle the maximum message length if not specified or a value greater than the message's length is passed. This change is also reflected in the python wrapper.
• The level parameter to the multicast() function is now optional. Additionally, if a value greater than 4 is passed to the level parameter, then the node's currently configured multicast_level (private member) is used as a default. This change is also reflected in the python wrapper.
• improved outgoing fragmentation by avoiding unnecessary SPI transactions amidst transmitting fragments.
• reduced computation in logicalToPhysicalAddress() (private member) where a function was unnecessarily called twice, but no longer.
• added missing public members to the python wrapper:
  • the newer/preferred begin(node_address); the old/deprecated begin(channel, node_address) is still present.
  • multicast_level
  • multicast()
  • multicastRelay
  • routeTimeout
  • parent
  • networkFlags
  • is_address_valid()
• removed unused FLAG_BYPASS_HOLDS & FLAG_HOLD_INCOMING as they are not used in any RF24* lib (actually relics from early development).
• all examples no longer use the deprecated begin(channel, address) function. Instead they use RF24::setChannel() & RF24Network::begin(addr)

[TMRh20]

Is this ready to go? The only thing I see missing is instructions on how to build using cmake in the RF24 docs.

[2bndy5]

These links will lead users to the build system they prefer. RF24/md_docs_linux_install.html has an advisory at the top of the page now. Its not explicit in this lib's docs, but then again, it never really was.

[2bndy5]

yeah its ready to go unless you have some requests

[TMRh20]

From your notes

The level parameter to the multicast() function is now optional. Additionally, if a value greater than 3 is passed to the level parameter, then the node's currently configured multicast_level (private member) is used as a default. This change is also reflected in the python wrapper.

I believe the max should be 4 since there are 5 multicast levels

[2bndy5]

You seem to be on a cleaning-streak. If you want to continue with the other Cmake-Linux PRs, then they have to merged to master in the OSI layer's order. Meaning, merge this and I'll mark RF24Mesh PR "ready for review".

[2bndy5]

After looking at the docs_build workflow artifacts, it seems that only sphinx is having trouble rendering the topology image.

Meanwhile this page renders fine in doxygen (inspected via workflow artifacts) and github. This may be a bug with the sphinx extension breathe... I'll look into it.