Repository navigation
nRF54l15 Support #1059
Description
Describe the behavior you would like
There is a new Arduino core for nRF52L15 devices! https://github.com/lolren/NRF54L15-Clean-Arduino-core
I've gotten it working with the nrf_to_nrf library, without modifications, but once we get into RF24Network etc, it poses some problems.
So far, I've found:
- A naming conflict in nRF24L01.h, with FEATURE, this could be renamed RF24_FEATURE
- A need to rename FEATURE per step 1 in RF24.cpp
- A need to
#define sprintf_P sprintfin RF24_config.h
Of course there are issues with the other libs as well that need to be resolved, but figured I would start here.
Right now support is just working, I'm getting duplicate payloads with the gettingStarted example between two nRF54s so there is some work to be done here. Figured I would start at the RF24 layer and work my way up.
Propose an implementation or solution
Layers RF24, RF24Network, RF24Mesh & RF24Ethernet all require changes.
Describe alternatives you have considered
No response
Additional context
No response
Activity
TMRh20 commentedon Mar 15, 2026
Looks like the nrf_to_nrf lib has been included in the core with some modifications, so that library was taking precedence over my code! Turns out I'll have to dig a bit deeper to get nrf_to_nrf working out-of-the-box with this core.
2bndy5 commentedon Mar 15, 2026
Wow! That dev really doesn't like the zephyr RTOS.
Seems like a direct violation of nrf_to_nrf GPLv3 license. I don't even see a License for that new core.
TBH, I'm seeing some signs1 that make me think the project was generated with AI. I'm not sure how much of it was actually vibe coded though.
Footnotes
The wordiness (in both API names and docs) and having a .planning/ folder and TODO.md doc. ↩
TMRh20 commentedon Mar 15, 2026
Yeah, the code is being produced very fast. Its the best we've got for now.
2bndy5 commentedon Apr 4, 2026
FYI, for historical references, the name collisions (past, present and future) was resolved with a namespace in #1066