shields: fem: no more explicit pin forwarder shield #19042
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
doc-required
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 57eec5498554320e6b14b2465580d998b3acaa8c more detailssdk-nrf:
Github labels
List of changed files detected by CI (47)Outputs:ToolchainVersion: b77d8c1312 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
ankuns
force-pushed
the
fem_shields_no_explicit_fwd
branch
from
4495e40
to
968879a
Compare
The nrf2220ek_fwd is no more necessary and deprecated. Build system picks appropriate overlay (being either a pin-forwarder or the main fem overlay) based on content of `boards` directory. User does not need to pass different values for `-DSHIELD` for every core on the SoC. It is handled on the shield level and passing just `-DSHIELD=nrf2220ek` for all cores is enough. Signed-off-by: Andrzej Kuros <[email protected]>
|
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publish GitHub Action. |
ankuns
force-pushed
the
fem_shields_no_explicit_fwd
branch
from
968879a
to
3418a5f
Compare
The nrf2240ek_fwd is no more necessary and deprecated. Build system picks appropriate overlay (being either a pin-forwarder or the main fem overlay) based on content of `boards` directory. User does not need to pass different values for `-DSHIELD` for every core on the SoC. It is handled on the shield level and passing just `-DSHIELD=nrf2220ek` for all cores is enough. Signed-off-by: Andrzej Kuros <[email protected]>
The nrf21540ek_fwd is no more necessary and deprecated. Build system picks appropriate overlay (being either a pin-forwarder or the main fem overlay) based on content of `boards` directory. User does not need to pass different values for `-DSHIELD` for every core on the SoC. It is handled on the shield level and passing just `-DSHIELD=nrf21540ek` for all cores is enough. Signed-off-by: Andrzej Kuros <[email protected]>
Direct handling of pin forwarding for nrf21540ek on the nrf5340 in radio_test sample is not necessary and is removed. The pin forwarding on the nrf5340 is handled by the shield code. Signed-off-by: Andrzej Kuros <[email protected]>
Direct handling of pin forwarding for nrf21540ek on the nrf5340 in dtm sample is not necessary and is removed. The pin forwarding related to the pins used by the shield on the nrf5340 is handled by the shield code. Signed-off-by: Andrzej Kuros <[email protected]>
ankuns
force-pushed
the
fem_shields_no_explicit_fwd
branch
from
3418a5f
to
57eec54
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem
The FEM shields for multi-core devices like nRF5340 SoCs until now required a special handling.
Suppose we had FEM shield called
fem_shield(just symbolic name here, wherefem_shieldcould be one ofnrf21540ek,nrf2220ek,nrf2240ek). Thefem_shielditself, as passed to-DSHIELD=fem_shieldis applicable only to that core of a SoC which has the RADIO peripheral (cpunet for nRF5340, different combinations for other SoC families). For multi-core SoC's like nrf5340 a special shield had to be passed to application core. Name of the shield had_fwdsuffix, like-DSHIELD=fem_shield_fwd. The role of this special shield was to tell the application core to pass the pins required by the FEM to the network core. This becomes even more complicated when there are multiple different image names for every application.Some applications like
radio_testanddtmsamples attempted to make the build more user-friendly requiring to pass just one -DSHIELD=nrf21540ek but it had following limitations:Proposal in this PR
The proposal is to simplify user experience by allowing to build an application by selecting just -DSHIELD=fem_shield, regardless of the architecture of a SoC (single core, multi core, forwarding needed or not...). The user experience on build would be limited to simple invocation of:
The SHIELD variable is passed by sysbuild to all images the build consists of.
If passing SHIELD to every image in the sysbuild is unwanted (because of bootloader or other images involved), an user can still build the application selecting explicit
-D<image_name>_SHIELD=fem_shield. However regardless of the core the image is built for, the user now has to pass just one namefem_shield. Again no need to know if "pin-forwarding shield" must be passed or the "real shield" and to which image.This simplicity in user experience is achieved by handling each supported board on the shield level.
The drawback of this approach is that shields now have explicit list of boards they support and their implementation contains similar code in multiple files in
board/directory (this has been limited somehow in this PR by having "common" directory).Clear benefit is consistent and simple (from user experience) way building with fem shields regardless of SoC type and no need to provide any "simplification code" on application level (see removed code for radio_test and dtm, while having the same user experience and functionality).
Justification
This PR is a side effect of upcoming support for nrf2220ek and nrf2240ek on the nRF54L15DK will be added. The nRF54L15DK is not arduino-compatible. Adding support for the nRF54L15DK will require switch to a per-board approach on shield level for nrf2220ek and nrf2240ek shields. To have the same user experience among all FEM shields regardless of SoC, the migration to per-board approach is proposed also for
nrf21540ekshield.To simplify review I decided to extract the change in approach to board handling on the shield level to this separate PR.
The chosen per-board approach is also consistient with existing
boards/shields/pca63565
boards/shields/pca63566