RadioLib: Non arduino build not working
Describe the bug
I’am trying to port radiolib to raspberrypi 4.
Firstly, to make radiolib compile successfuly, i made these changes: https://github.com/Mesteery/RadioLib/commit/b48d9ae4c4e939e39e05c950005e22a3151ba3d3. (I wanted to test my changes before opening a PR)
Plus these few lines in noarduino.h:
enum class byte : uint8_t {};
#define RISING 0
#define FALLING 0 // just trying to compile, the value is not important in this issue
#define DEC 10
#define RADIOLIB_NONVOLATILE
#define RADIOLIB_NONVOLATILE_READ_BYTE(addr) (*(const uint8_t *)(addr))
And enabled GODMODE. On compilation i have the error:
src/main.cpp: In function ‘int main(int, char**)’:
src/main.cpp:7:9: error: ‘class SX1278’ has no member named ‘setCb_digitalWrite’
7 | radio.setCb_digitalWrite(::digitalWrite);
| ^~~~~~~~~~~~~~~~~~
It’s maybe because of the toolchain I use or a misconfiguration because if I remove this line, I have another error:
main.cpp:(.text.startup+0x28): undefined reference to `Module::Module(unsigned char, unsigned char, unsigned char, unsigned char)'
/usr/bin/ld: main.cpp:(.text.startup+0x34): undefined reference to `SX1278::SX1278(Module*)'
I am using xmake with the following config:
add_rules("mode.debug", "mode.release")
package("RadioLib")
set_homepage("https://github.com/jgromes/RadioLib/")
set_description("Universal wireless communication library for embedded devices ")
set_license("MIT")
add_urls("https://github.com/Mesteery/RadioLib/archive/refs/tags/$(version).tar.gz",
"https://github.com/Mesteery/RadioLib.git")
add_versions("5.7.0", "ead59223faaf225087b1db8da852b49d5e5947d9")
on_install(function (package)
os.cp(path.join("src", "*"), package:installdir("include"))
end)
package_end()
add_requires("RadioLib fix-generic-build")
target("radio")
set_kind("binary")
add_defines("RADIOLIB_GODMODE")
add_includedirs("include") -- include/noarduino.h
add_packages("RadioLib")
set_languages("c++17")
add_files("src/*.cpp")
To Reproduce
//main.cpp
#include <cstddef>
#include "RadioLib.h"
int main(int argc, char** argv) {
SX1278 radio = new Module(1, 2, 3, 4);
radio.setCb_digitalWrite(::digitalWrite);
return 0;
}
//noarduino.cpp
#include <iostream>
void digitalWrite(uint32_t pin, uint8_t value) {
std::cout << "call" << std::endl;
}
and finally noarduino.h with the modification above (+ template in the wiki) and
void digitalWrite(uint8_t pin, uint8_t value);
#define RADIOLIB_CB_ARGS_DIGITAL_WRITE \
(void, digitalWrite, uint32_t pin, uint8_t value)
Expected behavior Compile successfuly
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 31 (31 by maintainers)
Commits related to this issue
- [MOD] Fixed SPI callbacks on non-Arduino platforms (#725) — committed to jgromes/RadioLib by jgromes a year ago
- [CC1101] Removed references to Arduino SPI callbacks (#725) — committed to jgromes/RadioLib by jgromes a year ago
- [nRF24] Removed references to Arduino SPI callbacks (#725) — committed to jgromes/RadioLib by jgromes a year ago
- [MOD] Removed references to Arduino SPI callbacks (#725) — committed to jgromes/RadioLib by jgromes a year ago
- [MOD] Fixed default Arduino callbacks for SPI (#725) — committed to jgromes/RadioLib by jgromes a year ago
I am very sorry, it compile correctly. My bad, xmake didnt re-cloned the repo, so it was out of date when I compiled. I force it to reinstall and it works!
Maybe, on some platforms. But everything else is going to have much larger impact than this.
Pretty close. I don’t see the need for making the member static if we allow changes in other parts of RadioLib, such as the RF switch mode table. I would also be careful about types (in theory uint8_t may be insufficent to fit HIGH or LOW, though I haven’t seen it in practice).
I think this should be achievable using just virtual methods, I’m not familiar with concepts.
Like I said previously, I’m not opposed to the idea of redesigning the abstraction layer. The problem I ran into is the surprising inconsistency across different Arduino platforms. Some of them stick to the API (e.g. digitalWrite/Read etc. are functions defined at the global scope), but others break it by e.g. defining the functions as macros. So if your approach works with tehm all, then I’ll be more than happy to use it.
Creating a HAL for SPI is just impossible or very complex with the current abstraction, because can’t store data like handle in a beautiful way. So I’m going to rewrite SPI defines/cb so they can work like the Arduino SPI, with a class.
Debug/verbose log:
(SPIxx are currently only logging functions). Everything seems to work, debug log works, I will create the PR. I will finish the HAL and I will try with the CC1101, I will keep you informed but there should be no problem. Thanks!
I think this is again a mistake/bad documentation in the Wiki: the Arduino function name should be left in the CB_ARGS macros so that Arduino-like callbacks are generated. Following the example from the Wiki for STM32 HAL:
I’m not opposed to it, but I don’t know how else to handle this. At the end of the day, the only thing the callbacks and macros do is hide a huge amount of boiler-plate code, and give you some flexibility as to the the signature of your HAL functions.